The actors have to be dict keys, so even if you don’t configure additional per-actor settings, you need to add a colon after the actor name.
1 Like
Yeah that one got me a few times while I was trying to get Schedy setup. All working now that I figured out I needed a colon after each actor name 
1 Like
Yes, it’s denoted in the sample config, but I may add an additional note to make it even clearer.
2 Likes
Next hurdle! 
I got an error stating that my thermostats dont have opperation modes, fine I thought. Ill try disabling them.
But when I try this
schedy:
module: hass_apps_loader
class: SchedyApp
actor_type: thermostat
actor_templates:
my_template:
off_temp: "OFF"
supports_opmodes: false
I get
2019-02-08 16:47:48.489514 ERROR schedy: !!! [R:slaapkamer_links] [A:climate.slaapkamer_links] Unknown operation mode, ignoring thermostat.
2019-02-08 16:50:59.973579 ERROR schedy: !!! [R:gang] [A:climate.gang] Unknown operation mode, ignoring thermostat.
And when I try to do without turning opmodes off I get:
2019-02-08 16:53:35.192106 WARNING schedy: !!! [R:gang] [A:climate.gang] Attributes for thermostat contain no 'operation_list', Consider disabling operation mode support.
Which doesnt seem harmful but Im trying to get this right
2019-02-08 16:47:48.489514 ERROR schedy: !!! [R:slaapkamer_links] [A:climate.slaapkamer_links] Unknown operation mode, ignoring thermostat.
This can’t be logged when you set supports_opmodes: false. Have you applied the my_template as template for your actors?
EDIT: If these settings should be applied to all actors, you could simply configure them for the default template.
@roshi
Thats what I tried to do with, I indeed want the settings applied to all actors
actor_templates:
my_template:
off_temp: "OFF"
supports_opmodes: false
Where in the config would I implement it for the default template?
Just name it default, not my_template.
1 Like
And, BTW, off_temp: "off" is redundant.
1 Like
Working like a charm now!
Thanks a million!
You’re welcome.
1 Like
Hi. Is it normal that Schedy is updating very often? I have four of this thermostats and it seems to put some load on the Raspberry.
2019-02-19 08:56:01.710424 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'operation_mode' is 'heat'.
2019-02-19 08:56:01.741310 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'temperature' is 25.0.
2019-02-19 08:56:01.748875 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'current_temperature' is 22.6.
2019-02-19 08:56:01.756398 INFO schedy_heating: --- [R:Stue] Unchanged HA state: state='25.0', attributes={'actor_wanted_values': {'climate.thermofloor_as_heatit_thermostat_tf_033_heating_5': '25.0'}, 'scheduled_value': '25.0', 'rescheduling_time': None, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None, 'friendly_name': 'Stue'}
2019-02-19 08:56:16.489738 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'operation_mode' is 'heat'.
2019-02-19 08:56:16.524822 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'temperature' is 25.0.
2019-02-19 08:56:16.531820 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'current_temperature' is 22.6.
2019-02-19 08:56:16.538182 INFO schedy_heating: --- [R:Stue] Unchanged HA state: state='25.0', attributes={'actor_wanted_values': {'climate.thermofloor_as_heatit_thermostat_tf_033_heating_5': '25.0'}, 'scheduled_value': '25.0', 'rescheduling_time': None, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None, 'friendly_name': 'Stue'}
2019-02-19 08:56:37.294937 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'operation_mode' is 'heat'.
2019-02-19 08:56:37.300901 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'temperature' is 25.0.
2019-02-19 08:56:37.311524 INFO schedy_heating: --> [R:Stue] [A:climate.thermofloor_as_heatit_thermostat_tf_033_heating_5] Attribute 'current_temperature' is 22.6.
2019-02-19 08:56:37.317205 INFO schedy_heating: --- [R:Stue] Unchanged HA state: state='25.0', attributes={'actor_wanted_values': {'climate.thermofloor_as_heatit_thermostat_tf_033_heating_5': '25.0'}, 'scheduled_value': '25.0', 'rescheduling_time': None, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None, 'friendly_name': 'Stue'}@Arne-Olaf That are your thermostats which report a state change, Schedy is just logging these and checking whether it has to react to the changes.
In these logs you posted, no action is performed by Schedy at all. You have the debug option enabled, that’s why the logs are so full of these messages.
EDIT: Could you quantify “some load” please? A state change every 15 seconds shouldn’t result in notable load at all, even with 100 thermostats.
EDIT 2: And, what RPI is it running on? We know that Python hasn’t the best performance due to its interpreted nature and the GIL, which makes parallel multithreading impossible, but nevertheless, 20 msecs for evaluating one state change shouldn’t be notable.
@roschi Thanks for your reply.
I run this on a Model 3B+
Changing to Hass.io in the meny sometimes get HA to freeze.
Mem: 935624K used, 12728K free, 516K shrd, 20168K buff, 366072K cached
CPU: 25% usr 10% sys 0% nic 46% idle 17% io 0% irq 0% sirq
Load average: 4.40 3.88 3.17 3/362 37
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
20 7 root S 2964 0% 1 0% sshd: root@pts/0
7 1 root S 2948 0% 2 0% /usr/sbin/sshd -D -e
22 20 root S 2596 0% 0 0% -bash
37 22 root R 1608 0% 2 0% top -n 1
1 0 root S 704 0% 0 0% /dev/init -- /run.sh
core-ssh:~# uptime
10:04:17 up 9:28, load average: 2.10, 2.67, 2.91
I haven’t got much experience with hassio, so I can’t help you there. But these stats don’t seem wrong, apart from a somewhat high memory usage (>60%).
And I also never ran HA or Schedy on an RPI, only on a more beefy x86 machine where such state changes are processed in <5 msec.
if you only have schedy in appdaemon, then i am pretty sure that it is not schedy that is causing trouble.
untill now i have hardly seen any evidence that AD gives a real load on the device.
but…
that said, i know that RPIs run on SD cards and they dont like it when there is a lot written to it.
history in home assistant (without taking precaution) is something that can be 1 of the things that breaks the SD card sooner, but running things like schedy in debug mode for a long time does that also.
keep an eye on your problem, because when it goes worse then its possible that your SD card is breaking down. avoid any kind of logging actions to the SD card if its not really necesary.
@Arne-Olaf I run Schedy on a Raspberry PI zero and it runs fine. Appdaemon somtimes complains about spending Excessive time in a utility loop but this does not influence the functionality.
Hello @roschi and all,
After several weeks of heating without issues, I’m facing a new one since holidays are starting tomorrow and I’d like to adapt schedy for that.
I have a schedule_snippets for my kids which is working fine. I need to adapt it to work differently during holidays if they are home. I’m then using two input_booleans, one for holidays and one for kids being home. When these two switches are on, I’d like to set the thermostat at 20 during morning and evening, 19 in between during day, and 16 during night. For having the 19, I use a Add(-1) to the rule that sets it to 20 for the specific time frame. However, this delta is also applied when the two input_booleans are off.
Since the Add(-1) is inside the rule, I understand that it should not be applied if the condition of the two input_booleans is not met. What I’m doing wrong with my rules?
Thanks.
schedule_snippets:
enfants:
- v: 20
rules:
- x: None if is_on('input_boolean.vacances') and is_on('input_boolean.semaine_avec_enfants') else Skip()
rules:
- { start: "7:00", end: "9:00"} #vacation morning
- { start: "18:00", end: "22:00"} #vacation evening
- x: Add(-1)
rules:
- { start: "9:00", end: "17:00"} #vacation day
- { start: "06:00", end: "07:30", weekdays: "2-3"} #tuesday and wednesday morning
- { start: "17:00", end: "20:30", weekdays: "1-2"} #monday and tuesday evening
- x: None if is_on('input_boolean.semaine_avec_enfants') else Skip()
rules:
- { start: "06:00", end: "07:30", weekdays: 1} #every each monday morning
- { start: "17:00", end: "21:00", weekdays: 5} #every each friday evening
- weekdays: 6-7
rules:
- { start: "07:00", end: "09:30" } #every each week-end morning
- { start: "18:00", end: "21:00" } #every each week-end evening
- v: 19
rules:
- { start: "07:30", end: "18:00", weekdays: 3} #wednesday day
- x: None if is_on('input_boolean.semaine_avec_enfants') else Skip()
rules:
- { start: "09:30", end: "18:00", weekdays: "6-7"} #every each week-end day
- { v: 16 } #other
@radar There are quite some misconceptions in here. I don’t have the time to walk through it with you one by one. However, That None/Skip() is nothing you want here.
I recommend you have a look at the examples for using Break() with sub-schedules.
Just one quick sketch.
- rules:
- x: "Skip() if is_on('input_boolean.vacances') and is_on('input_boolean.semaine_avec_enfants') else Break()"
# ...
# These are only executed when both switches are on.
# Restrict the "Add(-1)" to 9:00-18:00 and add a rule that
# inherits the 20 degrees from 7:00-22:00 afterwards.