Plan around midnight

[Meatballs1]

The Plan seems to struggle around midnight and shows the wrong days/forecasted rates.

I think it fixes itself after 1am (BST). Timezone issue or some confusion about what day it is around midnight?

E.g. its currently just after midnight on Sunday, but the plan starts off saying it is showing Sunday 23:00 onwards and changing to Monday, when I would expect it to be Saturday 23:00 (and changing to Sunday at 00:00):

[Meatballs1]

Plan recalulated after 1am:

(P.s. I cant quite work out why its picking 16.46p charging slots over <13p slots a few hours later)

[Meatballs1]

Set a manual discharge for Mon 00:30 but it didn't trigger (shows on plan as Tues 00:30)

2024-05-06 00:42:29.541942 INFO pred_bat: Next discharge window will be: 2024-05-07 00:30:00+01:00 - 2024-05-07 01:01:00+01:00 at reserve 66
2024-05-06 00:47:29.479610 INFO pred_bat: Setting ECO mode as we are not yet within the discharge window - next time is 05-06 00:30:00 - 05-06 01:00:00

Predbat seems confused about the discharge window too (but could be a timezone issue also)....

[Meatballs1]

Setting the discharge to 23:30 on the manual settings did work.

[Meatballs1]

So despite appdaemon being set to Europe/London my host and the appdaemon docker were both running in UTC.

Have added -v /etc/localtime:/etc/localtime:ro to docker and set host to Europe/London. Will check if it affects the plan displaytomorrow night

[springfall2008]

I think you need to check that the correct timezone is set in:

appdeamon.yaml apps.yaml In Home Assistant on your host.

[Meatballs1]

I believe setting the TZ in docker should fix it, but will check.

Few things to note:

• Appdaemon recommends it's own time functions e.g. self.get_time(), self.get_now() not sure if less prone to skew?
• now in update_time is non TZ aware and so was just set to UTC
• utcnow in update_time is TZ aware and is local time +0100. Would expect it to be +0000
• I'd vote for removal of daylight savings 😅