[Improvement] [QOL] Spam Alerts

[brianleect]

What I understand is that the new alert will continue to be sent as long as the change is greater than or equal to what was previously notified. Am I correct? For example: intervals = [''5m', '15m'] outlier_param = {'5m':0.02,'15m':0.04,'} First notification: "PUMP: TCTUSDT / Change: 2.5% / Price: 0.023277 / Interval: 5m" Muted notification: "PUMP: TCTUSDT / Change: 2.3% / Price: 0.023277 / Interval: 5m" Second notification: "PUMP: TCTUSDT / Change: 2.6% / Price: 0.023277 / Interval: 5m"

In this case the 2nd & 3rd notification will both not be triggered as the second condition trigger condition is not satisfied which is price must have a movement of larger than that of previous triggered price alert

Outlier_param * 0.023277

The intention was that there is little value in price alerts triggered which have little to no deviation in price.

I understand, that is to say that the percentages are accumulated.

I think that the most optimal for the second trigger condition would be that the next value is simply greater than the previous one.

As in the previous example:

intervals = [''5m'] outlier_param = {'5m':0.02}

First notification: "PUMP: TCTUSDT / Change: 2.5% / Price: 0.023277 / Interval: 5m"

Second (Muted) notification: "PUMP: TCTUSDT / Change: 2.3% / Price: 0.023277 / Interval: 5m"

Third notification: "PUMP: TCTUSDT / Change: 2.6% / Price: 0.023277 / Interval: 5m"

The way you propose it is optimal for small percentages, but when handling slightly larger percentages, say greater than 4 or 5%, many alerts would be lost.

Originally posted by @Juanjacinto123 in https://github.com/brianleect/binance-pump-alerts/issues/31#issuecomment-895407247

[brianleect]

I think I get your point on possibly filtering of changes with larger % being filtered off. I do suppose it is a trade-off atm of spam vs potential info.

I'll look into it and see if we can find a solution to this problem. We could possibly overwrite the cooldown and force a trigger if we see a % change relative to previous trigger being met.

This should solve the problem without introducing unnecessary noise.

[velajos]

I think I get your point on possibly filtering of changes with larger % being filtered off. I do suppose it is a trade-off atm of spam vs potential info. I'll look into it and see if we can find a solution to this problem. We could possibly overwrite the cooldown and force a trigger if we see a % change relative to previous trigger being met. This should solve the problem without introducing unnecessary noise.

I agree, let it trigger only if the percentage is higher than the previous one and keeping the MIN_ALERT_INTERVAL parameter for the user to decide the silence time. I really think that would be an optimal solution to the problem.

Please let me know when it is implemented to test it. Thank you very much @brianleect

[brianleect]

I think I get your point on possibly filtering of changes with larger % being filtered off. I do suppose it is a trade-off atm of spam vs potential info. I'll look into it and see if we can find a solution to this problem. We could possibly overwrite the cooldown and force a trigger if we see a % change relative to previous trigger being met. This should solve the problem without introducing unnecessary noise.

I agree, let it trigger only if the percentage is higher than the previous one and keeping the MIN_ALERT_INTERVAL parameter for the user to decide the silence time. I really think that would be an optimal solution to the problem.

Please let me know when it is implemented to test it. Thank you very much @brianleect

@Juanjacinto123 could take a look at the newest version. The way spam is filtered has been changed to consider variation in % using the alertSkipThreshold set at a default of 0.75 % . It should fit your needs in avoiding the blocking of important information.

Note: there is a minor bug for first initialization of TDP atm where it is all 0% for this version. Should be fixed within the coming week.

Nvm. Wait till further updates, there's some other issue with spam atm that's does not seem to be fully resolved.

[brianleect]

alertSkipThreshold appears to have its own limitations as well, does not seem to filter spam v well on slightly larger intervals. (15s for this case)

Possible solutions

1. Use larger value for alertSkipThreshold (Lower intervals will be impacted)
2. Have addition conditional for % price variation from last alert (Similar to old spam reducing implementation)

[patbaumgartner]

Yepp i think the alertSkipThreshold should be between 0.75 < x < 1% so you filter out lots of the small changes. but be aware that m most of the alerts are IHMO valid. Since a lot of messages show actually that things pump & dump.