Heaty will die, Schedy be born!

Share your Projects!
603

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

604

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.

605

Hi Pete
Came across this post about timezones

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

606

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.

607

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.

608

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

609

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”}

610

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

611

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 *

612

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

613

I have this

“python_packages”: [
“hass-apps” ]

Whay do i change ot for?

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

See here.

615

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

616

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

617

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

618

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?

619

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.

620

Open door sensing works perfectly in Schedy. See tips and tricks section: https://hass-apps.readthedocs.io/en/stable/apps/schedy/tips-and-tricks/index.html

1 Like
621

@thundergreen The advantages of using Schedy instead of plain automations for these sorts of things are numerous. You have everything at one place: your schedule. You can scale to multiple rooms/thermostats/window/door sensors easily and don’t have to care about some corner cases and race conditions between the different automations. And - if done right - the whole config will be easier to read and maintain. Adding door sensors literally comes down to adding a single schedule rule and a room-sensor mapping for each sensor.

622

Sounds fair …I’ll give it a shot this week …thanks for your feedback