-
Notifications
You must be signed in to change notification settings - Fork 51
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
Bug related to upcoming DST change? #248
Comments
If useful I see some indices change over time
|
|
|
I am from Belgium and this morning I also got an error message. Yesterday it workt perfectly. 2024-03-30 14:25:18,524 - web_server - INFO - Passed runtime parameters: {} |
Try 'prediction_horizon': 46 |
I'm also getting failures. Just updated to the latest version today. Different error though. DST starts tonight.
|
The original error message from @g1za seems related to the passed data. The error is a checkup done on input data. So not much to do here. You are not passing the correct length of those data lists |
I thought that could be a reason (maybe my source data had changes due to the time change), so I checked but according to the command I'm expected to pass 48 elements ( May the problem be related to data pull from HA past data? Edit:
` |
I definitely believe it is still a bug related to DST, @davidusb-geek
|
Thanks @g1za for looking at this. It is definitely not 100% DST change proof. The problem here is that I've not been able to reproduce this exact situation in testing. But we will need to try another round. |
That is 100% DST related, because out of all 365 days I picked yesterday to finally configure this beast and spent 6 hours digging through various numpy shapes and csv_load exceptions. Of course it immediately worked today from second try. |
Mine is still failing. My guess is that until it’s 48hrs after the DST change it’s going to keep getting 1 hour less from history, and complain that the values don’t match up. Max I can do at present is a horizon of 12 for some reason. |
Yes we still need to work this one out |
I'm getting a similar problem with the upcoming change in Sydney, but in this case an AmbiguousTimeError is being thrown. |
If I can make a suggestion, in my experience the best strategy for anything time related is to work in UTC as much as possible and convert to and from the local time zone at the API boundary (if necessary) or for display to the user. |
I'm on the latest version of the add-on and this morning I noticed that the latest processed data was from this night at 2AM.
In the log I found the error below (the most recent I have a available); before everything was running smoothly.
I have the feeling this may be related to the daylight savings time change happening tonight at 2AM; what do you think?
The text was updated successfully, but these errors were encountered: