New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wrong period starts for 45m candles in PAPERTRADE mode #410
Comments
I have updated the issue with some extra information (in case you come here from email notifications) |
Just double checked all my instances, and the problem is confirmed to be only with 45m candles. |
I appreciate the detailed explanation that you provided. If the timestamp of the candles is as you see in the pictures, then yes there is a bug with 45m candles.
I'd like to clarify that in Jesse my assumption is that we calculate candles the same way it is on trading view. Which is at the closing time yes that is how you expected. But if you try to make a trade or some calculation during the candle's timestamp, then |
The current/closing price won't be different of course, but in case I need to see the last candle's color for example, or whether it was a pump/dump candle, my strategy will have a wrong impression if I checked the code, and I believe the 45m bug is inside the binary live trading plugin, so I cannot reach it, but this 0-second candles stuff I should be able to patch client-side. Strange thing is that I trim |
So, I managed to get rid of all 0-second candles inside my indicator using candles = candles[time - candles[:, 0] > 60 * 1000] Apparently, at times there're more than one 0-sec candle in the array, as in logs I can see sometimes 2 or even 3 candles are dropped. Not sure whether it's related to the main issue, but worth documenting or creating a helper function I think. |
This is useful. Thank you for explaining the use cases. Can you please submit a PR to add this as a utility function? By the way, in case you are curious the code for handling candles is inside the main framework: The plug in merrily handles receiving the candles and not how we saw them. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hey, |
Hey man. No problem. You've already contributed so much. No it wasn't addressed |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Saleh, first of all, I hope you're well during these trying times.
I found some weird behaviour, upon investigation it looks like a bug in Jesse's candle generation.
Describe the bug
The assumption with any trading system is that
candles[-1]
is either closed previous or the current candle. With Jesse however, this is not guaranteed, as during papertrade mode quite often the most recent 45m candle(s) contain erratic open time and OCHL values which leads to wrong orders. This is never a problem in backtesting mode ascandles[-1]
is always previous candle there. All this leads to wrong assumptions how backtested strategy will work in papertrade/live mode and to wrong trades being issued.I log previous candle, as my indicator depends on its values. Sometime ago I noticed that the most recent candle can contain open timestamp equal to current time, i.e. 0 second candle basically. This may happen when Jesse executes the strategy after a new candle start, i.e. 1 second later for example. As a quick crutch, I added a check for such candles in my indicator to chomp them:
Recently I noticed that some trades still open at wrong times (which usually leads to a loss) and these trades are not present in forward-test for the same time period.
I added
current_time - candle_open_time
difference calculation to my candle logs and discovered that quite a few candles still have 0 second length or length less than 45m even after chomping:(note
open-time diff
values above)Another example with prev candle open time = 7 minute delta from current:
Upon further investigation it turned out that in Postgres 45m candles are sometimes formed at random periods:
Output:
Please note how around 00:53 candles began to start their period at wrong times. For the record, this Jesse instance was restarted at 00:35, however previous restart was at 23:53, not sure whether it bears any significance or just a coincidence.
So, I'm at loss here. Looks like there is a bug with the 45m period start calculation, and nothing can be done on client side to fix it. I will look into Jesse's code later today, but maybe you have an idea where to look for this error?
Enviroment (please complete the following information):
The text was updated successfully, but these errors were encountered: