Divergences indicator bug

Am I right to think that this is a bug? Shouldn’t I get a signal exactly on the same indicator’s marks on the chart?

Bug details:

  • Bot URL → Gainium app
  • [Optional] Steps to reproduce →
  • Expected result → we should get a signal in the same place where indicator marks are displayed - if we have 2 divergences, then we should get a signa,l BUT if we have only 1 or 3, for example, the bot should bypass the signal

We have received your bug report regarding the divergences indicator and will update you shortly. Thank you for providing the bot URL, this will assist us in investigating the issue.

We have identified a discrepancy between the signals computed in the backend and what it’s shown in the front end, but debugging this will take a while and we are in the middle of of some important updates so we will look at it after.

1 Like

just so you know, we noticed the same issue in other indicators (real and paper) like QFL, MA, etc.

This is not something in common with other indicators. Each case needs to be investigated. Could be related to specific exchange and symbol.

yep - I can’t report bugs for other users but I can give you an example

this deal on BITGET ASTER/USDT should have opened in a uptrend but it just opened a random deal

I will check. And bot id will be helpfull.

68f9bad6a9bd6801e4ee23ac (this is a different bot WLDUSD but has the same issue of the example posted above)

This is not one of my bots - but the user said that all his bots using the same condition are not working as they should

thank you for checking

Hello friends, yes, the bots have been opening operations incorrectly, the logic indicates that it opens longs when the 50 EMA is above the 9-period EMA, I was reviewing the trades when it started and it was working correctly, now in the new cycles it seems that it is taking the EMAs in the opposite direction, when the 9 is above the 50 it operates in Long and when it is below it operates in short, it seems that the conditions crossed

I can see real time data now. Its not the condition, its input data. We already had problem with indicators at bitget previously. Problem seems to be fixed, but appears once again.

1 Like

I understand, I hope you let us know when the problem is solved

Hello again, the bug is back, it’s opening random operations on several bots again

These are two examples of the operations that are being executed when the EMAS condition is not being met. I don’t know if it could be due to a false EMAS break or if it is the bug reported earlier

@maksym.shamko Any updates on this?

Unfortunately this is related to bitget integration. And I haven’t found a way to properly handle it.

so is the indicator affected by bitget data somehow?

Yes, the one mentioned by Byron is affected.
Divergence is not related to bitget.

we found more indicators not working properly like QFL for example - got no time to post it now but it may be because of bitget then not the indicator itself

Yes, probably bitget related.
If its working in backtest than shouldn’t be an indicator.

It doesn’t happen with all bots, it happens with certain bots that already have open trades (which are execute correctly). Then, it continues opening trades with the over/under condition, but it doesn’t seem to take the EMA condition into account. This is possibly a misinterpretation of the bot’s signals and not a synchronization issue with the indicators in BitGet, because most bots are working correctly. The problem arises when it opens the first trade and continues executing over 2%/under 2% trades (in my case, with Rossano’s Mini Planktom strategy). Some bots ignore the EMA condition, which is why I think it might be due to a misinterpretation of the conditions. Again, it’s not all bots; it’s a minimal percentage, but in the long run, it affects the strategy because the goal is to consume as few funds as possible, and when it opens trades without a condition, the capital is consumed quickly

I’m leaving you the bot IDs so you can check them out

68fbfeacafca277821f950db

68f1be622306d92d3b487191

68f31ad4c09d5d95813c79e6