Hi
I’m using Schedy to control some heating components through home assistant using hass.io and I’m based in the UK. Since the end of march we’ve been in British Summer Time but Schedy still seems to be running from times in UTC.
When I look at HA and AppDaemon it looks like they are both correctly picking up and applying the timezone settings. (time_zone in the config and I’ve tried to update both).
If I add a clock component on an AppDaemon Dashboard it’s got the correct local time.
The Log for appdaemon is in UTC but even logging at debug level I can’t see anything mentioning timezones.
2019-05-31 22:24:56.996920 DEBUG schedy: — [R:schedule] Assuming it to be 2019-05-31 22:24:56.
Does Schedy support scheduling in local time and summer time changes?
I am using Schedy since December last year and switching to the DST in the Netherlands was fine so I am afraid it is something with your installation. I am no Python expert so can not help you with further debugging.
AppDaemon takes over the timezone of the host when /etc/localtime is mapped into its Docker container. I don’t know how hassio handles this, but when AD’s log isn’t in local time that means it didn’t pick up the right timezone. Maybe @ReneTode can help you out there? He is more familiar with AppDaemon on hassio I think.
the device time it self. that time will be picked up by programs as default
the os time, if that is set it normally overrides the device time
program time. in HA you set a time, in AD thats also possible, but when the time isnt set in AD it will pickup the time from HA.
you say an appdaemon dashboard shows the right time, but thats because that a dashboard clock shows the time from the device that is showing the dashboard.
HA shows the right time, because the program time is set correct.
but your logs show UTC and python doesnt have a time to set. it picks up the device time.
so its the device or OS time that isnt set correct.
@taste
I’ve tried the template. I think this is what is expected from my timezone.
I assume this is HA thought and doesn’t take AppDaemon/Schedy into account
@ReneTode
So from what you are saying I assume the timezone should be set on the appdaemon docker image and it should be running in the local time. I’m now fighting with the ssh addon to try and get a terminal into the host but failing badly. Might just connect this Pi back to a TV and try from there.
what you see there is the set time in home assistant (programlevel time)
if you have appdaemon in docker then you could set the docker time (OS level) but if you use hassio i dont think that will work (you talk about ssh addon, so i assume hassio)
there have been a lot of people before you strugling with the same problem, so your best bet is to search the forum for setting device time on hassio
I have the following line as part of a schedule, according how i read the docs this should run from friday and Saturday 11 pm and end Saturday and Sunday at 11 am . However it seems to run now on friday morning till 11am,
- { v: 72, start: “22:00”, end: “11:00” , weekdays: “5-6”, }
I have also tried explicitly using the, end_plus_days: 1, but had the same results
I have changed it to 2 separate lines to get my desired results but cant this be done in 1 line?
This is how i got it working now
- { v: 72, start: “22:00” , weekdays: “5-6”}
- { v: 72, end: “11:00” , weekdays: “6-7”}
@yabuts You’re right, the single rule should have worked as expected. I wanted to rewrite and simplify the rule checking algorithm anyway. Would you mind trying the development version from the master branch and then report back again?
How to i use the development version, i use hassio on a pi, the only this i have in my appdeaman is schedy which got installed through hass_apps.loader import *
OK i have tried the the master version same results, here is what i got
at this time point of time
2019-06-07 17:31:12.207973 INFO schedy: — [R:bedroom] Assuming it to be 2019-06-07 17:31:12.
i had the flowing rule
i would expect the first one to be the valid rule as now if friday and this rule should be valid from Thursday 22 to Friday 18 ,assuming the end_plus_days will be 1
I got access to to my host OS (initially via the keyboard but then realised my issue was SSH was the wrong port and I was actually going into the HA container)
On the Docker side it looks like my TZ isn’t set on the appdaemon container. I’d be interested to find out if this is the norm or something has gone astray in my install.
I saw some links that mentioned installing tzdata but doesn’t seem to do the trick either. I suspect the right way to fix it is to update the docker container command. I could try and update the container settings but may end up doing more harm than good.
Either way at this stage I think I’ll just wait for v4 and adjust my scripts with some dumb offset logic.
I am actually running heaty as there is open door sensors. >That part is sompletely missing in shedy. But i guess i can just use both? the door sensors and master switch from heaty and the scheduing from shedy? Or does soomeone have a door / window sensor configuration present. my idea is having a master swith and a controller that controll if windows and doors are open. presence is also a very interesting thing but all of this could also be done with normal automations so i dunno where the advantage might be using shedy then?
you dont need to wait.
AD 3 already has the options to set timezone etc. in AD 3.
the change you are speaking about is that its going to change from optional to mandatory.