@pav It has to be the string “OFF” (case insensitive), not OFF, which would be translated to False by YAML.
Maybe the generic thermostat needs the operation mode to lower case? I really don’t know, but you can try to change it to lower-case “off” in Heaty’s thermostat config.
EDIT:
Ah, I see that you already found out that it has to be lower-case 
I’m not changing the default, since different thermostats require different operation modes. Mine want it to be capitalized, for instance.
@pav And regarding to your second question:
Re-scheduling not before ??:?? (0:00:06).
is logged when Heaty receives a heaty_reschedule event. The re-scheduling is delayed for 6 seconds in this case to avoid multiple heaty_reschedule events received in short time to trigger multiple re-schedulings. The background of this is that there are often multiple entities changing their state simultaneously, e.g. when multiple switches are turned on by a group or scene.
Something’s fishy about the OFF special value : when I use
- temp: "OFF"
it passes without complaining, but when I use things like
- temp: "OFF" if app.get_state("input_boolean.heating_" + room_name) == "off" else Ignore()
I get
2018-02-10 17:43:45.383361 INFO AppDaemon Version 3.0.0b2 starting
2018-02-10 17:43:45.384237 INFO Configuration read from: /home/homeassistant/appdaemon/appdaemon.yaml
2018-02-10 17:43:45.386700 INFO AppDaemon: Starting Apps
2018-02-10 17:43:45.485845 WARNING AppDaemon: Error loading configuration
2018-02-10 17:43:45.486538 WARNING AppDaemon: parser says
2018-02-10 17:43:45.487358 WARNING AppDaemon: in "<unicode string>", line 137, column 17:
- temp: "OFF" if app.get_state("input_boolean. ...
^
2018-02-10 17:43:45.487830 WARNING AppDaemon: expected <block end>, but found '<scalar>' while parsing a block mapping
Hi Robert,
I’ve got one more question : are state changes of entities used in inline temperature expressions (e.g. the input_boolean in above post) being monitored and acted upon automatically, or do we have to monitor them ourselves and use an automation to fire a heaty_reschedule event ?
That’s because you’re violating the YAML syntax and has nothing to do with Heaty. You only need to use quotes if you specify something like no, off, false and want YAML to interpret it as a string rather than as None.
A value like OFF I love cookies! needs to be either quoted entirely ("OFF I Love cookies!") or not at all, but "OFF" I love cookies! is no valid YAML, because the parser doesn’t know what to do with the I Love cookies. part, since it expected the string to have ended at the closing quote sign.
EDIT:
Just for the records, it should have been:
- temp: OFF if app.get_state("input_boolean.heating_" + room_name) == "off" else Ignore()Sorry for violating YAML 
(who hasn’t ?)
So if I understand well, for the ‘simple’ rule I can use either - temp: "OFF" or - temp: OFF, or not ?
I’ve read the README several times already, but it kept me wondering because in the ‘Example: Use of an external module’ section you explained the need for the external automation, whereas in the following section ‘Example: Inlining temperature expressions into schedules’ you say ‘The following schedule will have the same effect, but without the use of any external Python module’. I was just wondering whether this might be interpreted as ‘also not needing the external automation’.
I of course understand that this would be rather difficult to realise - but on the other hand it would no doubt make things even easier and less error-prone.
Anyway, thanks for enlightening me - have a nice weekend !
@pav Don’t worry YAML can be tricky sometimes.
There is actually no way for Heaty to know which entities and which of their state attributes you are interested in. Of course, I could trigger a re-schedule at any state change in Home Assistant, but this would then even re-schedule when the sun or weather state is updated, which is probably not what you want.
So you would need to tell Heaty the entity ids and attributes you want to track, which is actually not more effort then creating a single automation in Home Assistant which handles all entities at once.
EDIT:
And it saves me from implementing a mechanism to specify automation triggers in Heaty, which would be a lot of work and is really not needed since HA does a pretty good job in simple automations.
And of course, have a nice weekend as well!
Hi,
I’m strugling with Heaty on top of Hass.io (running hassioaddons/appdaemon3-armhf as appdaemon plus hass-apps v 0.20180209.0).
For unknown for me reason it cannot update climate devices (Danfoss Z-Wave plus one Fibaro Heat Controller) temperature
2018-02-13 23:37:03.055522 INFO heaty: <-- [salon] Setting climate.danfossszafa_heating_1: temperature=21.0, operation_mode=Heat, left retries=9
2018-02-13 23:37:03.057154 INFO heaty: <-- [salon] Setting climate.danfossklima_salonklima: temperature=21.0, operation_mode=Heat, left retries=9
2018-02-13 23:37:03.085684 INFO heaty: <-- [salon] Setting climate.fibaro_system_fgt001_heat_controller_heating: temperature=21.0, operation_mode=Heat, left retries=9
2018-02-13 23:37:03.677510 INFO heaty: --- [salon] Re-sending to climate.danfossszafa_heating_1 in 60 seconds.
2018-02-13 23:37:03.700660 INFO heaty: --- [salon] Re-sending to climate.danfossklima_salonklima in 60 seconds.
2018-02-13 23:37:03.706811 INFO heaty: --- [salon] Re-sending to climate.fibaro_system_fgt001_heat_controller_heating in 60 seconds.
I can see difference in log when temp change goes via heaty
2018-02-13 23:37:03 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=climate, service=set_temperature, service_data=entity_id=climate.danfossszafa_heating_1, temperature=21.0, service_call_id=1964646064-134>
2018-02-13 23:37:03 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=climate, service=set_temperature, service_data=entity_id=climate.fibaro_system_fgt001_heat_controller_heating, temperature=21.0, service_call_id=1964646064-136>
while calling via GUI:
2018-02-13 23:39:08 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=climate, service=set_temperature, service_data=temperature=23, entity_id=climate.fibaro_system_fgt001_heat_controller_heating, service_call_id=1964646064-149>
In working scenario in service_data it sends first entity_id than temperature.
Any idea what might be wrong?
Hi @kowalma
The order is completely irrelevant as there is no explicit ordering, neither when the service call is made via HA’s GUI nor by Heaty. Python’s dictionaries (the type of the data structure service data is passed in) have no predictable ordering by default.
Please check whether your thermostats require operation modes in lower-case or capitalized. Heaty sends capitalized operation mode names by default, but you can change that in the config as documented in the sample.
Best regards
Robert
Hi,
This are Danfoss Z-Wave radiator thermostats where only thing that can be set is target temp.
Are you sure they don’t support toggling between Off and Heat?
Can you please fetch the hass_apps/heaty/app.py file from GitHub and replace your local one with this? Then restart appdaemon and check the logs, right at the beginning when Heaty is initialized you should see Running plausibility checks. Are there any warnings?
Best regards
Robert
Hi,
There were two problems in fact - heaty did not use new_entity_id but it was found with logs of new version
2018-02-14 12:26:59.087774 INFO heaty: --- Running plausibility checks on the configuration.
2018-02-14 12:26:59.096451 WARNING heaty: !!! [salon] Thermostat climate.danfossklima_salonklima couldn't be found.
after I’ve changed entity it fails with missing attribute operation_mode as Danfoss Z-Wave ones does not have this mode at all.
2018-02-14 12:30:15.078253 WARNING heaty: !!! [salon] Thermostat climate.danfoss_z_thermostat_heating_1 has no attribute named 'operation_mode'. Available attributes are ['current_temperature', 'friendly_name', 'icon', 'max_temp', 'min_temp', 'new_entity_id', 'node_id', 'old_entity_id', 'supported_features', 'temperature', 'unit_of_measurement', 'value_id', 'value_index', 'value_instance']. Please check your config!
2018-02-14 12:30:15.092787 INFO heaty: --- [salon] Attributes for thermostat climate.danfoss_z_thermostat_heating_1 contain no operation_list, skipping plausibility check.
Regards
Ok, I didn’t know there are thermostats without operation modes
Currently, there is no special support for them in Heaty. But I guess it should be relatively simple to add, since the only difference to regular thermostats is that they can’t be turned off…
I’ll add a per-thermostat option to disable dealing with operation modes at all. It should be ready in an hour or two.
Thx. Let me know when I test it.
Regards
@kowalma Just a short status update: It turned out to be more work than I expected and it will take more time. I’ll get back to you when it’s implemented.
@kowalma Can you please try using the new version from GitHub? Please upgrade the complete hass_apps directory, since there have been changes in multiple modules.
Hi,
I’ve updated to commit 7d82fd0
2018-02-14 22:22:18.788956 INFO heaty: --- Heaty id is: 'default'
2018-02-14 22:22:18.764350 INFO heaty: --- heaty v0.10.2 initialization started
2018-02-14 22:22:18.808332 INFO heaty: --- Running plausibility checks on the configuration.
2018-02-14 22:22:18.825089 WARNING heaty: !!! [salon] Thermostat climate.danfoss_z_thermostat_heating_1 has no attribute named 'operation_mode'. Available attributes are ['current_temperature', 'friendly_name', 'icon', 'max_temp', 'min_temp', 'new_entity_id', 'node_id', 'old_entity_id', 'supported_features', 'temperature', 'unit_of_measurement', 'value_id', 'value_index', 'value_instance']. Please check your config!
2018-02-14 22:22:18.839518 WARNING heaty: !!! [salon] Attributes for thermostat climate.danfoss_z_thermostat_heating_1 contain no operation_list, Consider disabling operation mode support.
2018-02-14 22:22:18.854957 WARNING heaty: !!! [salon] Thermostat climate.danfoss_z_thermostat_heating_1_2 has no attribute named 'operation_mode'. Available attributes are ['current_temperature', 'friendly_name', 'icon', 'max_temp', 'min_temp', 'new_entity_id', 'node_id', 'old_entity_id', 'supported_features', 'temperature', 'unit_of_measurement', 'value_id', 'value_index', 'value_instance']. Please check your config!
2018-02-14 22:22:18.868905 WARNING heaty: !!! [salon] Attributes for thermostat climate.danfoss_z_thermostat_heating_1_2 contain no operation_list, Consider disabling operation mode support.
2018-02-14 22:22:18.883975 WARNING heaty: !!! [salon] Thermostat climate.danfoss_z_thermostat_heating_1_3 has no attribute named 'operation_mode'. Available attributes are ['current_temperature', 'friendly_name', 'icon', 'max_temp', 'min_temp', 'new_entity_id', 'node_id', 'old_entity_id', 'supported_features', 'temperature', 'unit_of_measurement', 'value_id', 'value_index', 'value_instance']. Please check your config!
2018-02-14 22:22:18.898002 WARNING heaty: !!! [salon] Attributes for thermostat climate.danfoss_z_thermostat_heating_1_3 contain no operation_list, Consider disabling operation mode support.
in apps.yaml I’ve setup thermostats as follows
rooms:
# Define such a block for each room you want to control.
salon:
thermostats:
climate.fibaro_system_fgt001_heat_controller_heating:
climate.danfoss_z_thermostat_heating_1:
supports_opmodes: false
climate.danfoss_z_thermostat_heating_1_2:
supports_opmodes: false
climate.danfoss_z_thermostat_heating_1_3:
supports_opmodes: false
replicate_changes: true
I’ve decied to move supports_opmodes: false to thermostat defaults and then no plausibility warnings
2018-02-14 22:27:11.163600 INFO heaty: --- heaty v0.10.2 initialization started
2018-02-14 22:27:11.186841 INFO heaty: --- Heaty id is: 'default'
2018-02-14 22:27:11.200921 INFO heaty: --- Running plausibility checks on the configuration.
2018-02-14 22:27:11.218308 INFO heaty: --- Importing modules for temperature expressions.
2018-02-14 22:27:11.231949 INFO heaty: --- Getting current temperatures from thermostats.
2018-02-14 22:27:11.248513 INFO heaty: --> [salon] climate.fibaro_system_fgt001_heat_controller_heating: attribute operation_mode is Heat
2018-02-14 22:27:11.263807 INFO heaty: --> [salon] climate.fibaro_system_fgt001_heat_controller_heating: attribute temperature is 21.0
2018-02-14 22:27:11.280083 INFO heaty: --> [salon] Received target temperature 21.0 from thermostat.
2018-02-14 22:27:11.295930 INFO heaty: <-- [salon] Propagating the change to all thermostats in the room.
2018-02-14 22:27:11.312930 INFO heaty: <-- [salon] Temperature set to 21.0. <manual>
2018-02-14 22:27:11.330061 INFO heaty: --- [salon] Not sending temperature to climate.fibaro_system_fgt001_heat_controller_heating redundantly.
2018-02-14 22:27:11.349231 INFO heaty: --- Called update_publish_state_timer.
2018-02-14 22:27:11.357286 INFO heaty: --- Called update_publish_state_timer.
2018-02-14 22:27:11.364062 INFO heaty: --- Registering event listener for heaty_reschedule.
2018-02-14 22:27:11.371199 INFO heaty: --- Registering event listener for heaty_set_temp.
but stil not able to control group
2018-02-14 22:27:12.077066 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1_3: temperature=21.0, operation_mode=Heat, left retries=10
2018-02-14 22:27:12.088157 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1: temperature=21.0, operation_mode=Heat, left retries=10
2018-02-14 22:27:12.110387 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1_2: temperature=21.0, operation_mode=Heat, left retries=10
2018-02-14 22:27:12.473460 INFO heaty: --- [salon] Re-sending to climate.danfoss_z_thermostat_heating_1_3 in 60 seconds.
2018-02-14 22:27:12.626371 INFO heaty: --- [salon] Re-sending to climate.danfoss_z_thermostat_heating_1_2 in 60 seconds.
2018-02-14 22:27:12.628236 INFO heaty: --- [salon] Re-sending to climate.danfoss_z_thermostat_heating_1 in 60 seconds.
2018-02-14 22:28:12.027444 INFO heaty: --- [salon] Cancelled resend timer for climate.danfoss_z_thermostat_heating_1.
2018-02-14 22:28:12.034953 INFO heaty: --- [salon] Cancelled resend timer for climate.danfoss_z_thermostat_heating_1_3.
2018-02-14 22:28:12.038759 INFO heaty: --- [salon] Cancelled resend timer for climate.danfoss_z_thermostat_heating_1_2.
2018-02-14 22:28:12.052012 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1_3: temperature=21.0, operation_mode=Heat, left retries=9
2018-02-14 22:28:12.074373 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1: temperature=21.0, operation_mode=Heat, left retries=9
2018-02-14 22:28:12.098873 INFO heaty: <-- [salon] Setting climate.danfoss_z_thermostat_heating_1_2: temperature=21.0, operation_mode=Heat, left retries=9Hi,
Odd thing - it does send warning and retries but Z-Wave stack does execute the change
2018-02-14 22:52:49.219 Detail, Node024, Refreshed Value: old value=22.00, new value=22.00, type=decimal
2018-02-14 22:52:49.219 Detail, Node024, Changes to this value are not verified
2018-02-14 22:52:49.219 Info, Node024, Received thermostat setpoint report: Setpoint Heating 1 = 22.00C
2018-02-14 22:52:49.220 Detail, Node024, Notification: ValueChanged