Heaty will die, Schedy be born!

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?

Thanks
Peter

Hi Pete,

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.

Marc

Hi,

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.

Best regards
Robert

Is there a link for shedy as all links here seem broken … I’m running heaty but wanna switch to shedY

This is the link to the stable part of the documentation.
https://hass-apps.readthedocs.io/en/stable/apps/schedy/index.html

Most links in this topic to to the development version. The stable version works very well. I use it in 2 production systems.

Hi Pete
Came across this post about timezones

Especially the tip on using the template editor to review your settings might be helpful.

there are several levels to set the time.

  1. the device time it self. that time will be picked up by programs as default
  2. the os time, if that is set it normally overrides the device time
  3. 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.

Thanks all for the help here

@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

{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}

2019-06-05 22:26:10.149312+01:00
2019-06-05 21:26:10.149579+00:00
2019-06-05 21:26:10.153213+00:00
2019-06-05 21:26:10.153948
2019-06-05 21:26:10.154405
2019-06-05 21:26:10.154840
2019-06-05 21:26:10.154923+00:00
Europe/London
UTC
UTC

@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 *

Look into the Upgrading or Getting Started guides in the docs. You basically just have to change the URL you put into python_packages.

I have this

“python_packages”: [
“hass-apps” ]

Whay do i change ot for?

https://github.com/efficiosoft/hass-apps/archive/master.zip

See here.

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

   - { v: 72 , start: "22:00", end: "18:00" , weekdays: "4" }
   - {v: "OFF" }

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

but its gets to the “OFF” rule

Thanks Rene

I am indeed using HassOS on a RaspberryPi. It’s using the relatively default setup.

I came across the issue below, so it looks like AppDaemon is going to be more tz aware in the next verison.
https://github.com/home-assistant/appdaemon/issues/250#issuecomment-440097071
I’m tempted to wait for that , though there is no indication of when that would be.

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.

# docker exec -it ec30dc6e8ef6 /bin/bash
root@a0d7b954-appdaemon3:/$ env
LANG=C.UTF-8
TZ=UTC
HOSTNAME=a0d7b954-appdaemon3
...

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.

Thanks again
Peter

@yabuts Right, can you try the latest version again, please?

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.

take a look at the configuration part from the docs on how to set your values in appdaemon.yaml
https://appdaemon.readthedocs.io/en/latest/CONFIGURE.html

its possible that you need to make sure that your addon doesnt overwrite your settings. (i think thats some addon setting now)

if adding those settings doesnt do the trick (which i dont think because you inherit from HA correctly) then you are back to what i told before.