I have a blueprint (Heating X: Schedule Thermostats with Calendars) that I use for all my rooms to control the battery-powered radiator thermostats. In a recent change, to improve robustness, it refreshes the setting every minute. It works fine, but it occurs to me that I may be sending unnecessary Zigbee traffic and therefore running the thermostat batteries down faster than necessary in the long-term.
My questions
- Is there any in-built optimisation that prevents ZHA sending duplicate signals often? If so, how can I see it working?
- The simplest algorithm for not sending duplicate signals myself is to check whether the new temperature is the same as the current one – however, if I read the current set temperature as a climate attribute (in a template sensor) is that also sending a Zigbee signal?
I could, of course, keep a copy of the current set temperature in a helper but that opens new robustness pitfalls and requires yet another helper, so I would prefer a simpler solution if there is one.
I would like either
- detailed documentation on how Climate and ZHA interact, and/or
- a way of directly monitoring (tracing) actual Zigbee traffic
Code
The full code of the blueprint is on github: AndySymons/heating_x.yaml
The template sensor I use to read the current set temperature is (for one example radiator thermostat)İ
### Bathroom towel rail thermostat set temperature
- sensor:
- name: Bathroom towel rail thermostat set temperature
unique_id: "e1e7f1c5-680d-74e1-6225-35c152b75825"
unit_of_measurement: 'C'
icon: mdi:thermometer
state: "{{ state_attr('climate.bathroom_towel_rail_thermostat', 'temperature') }}"
A typical code fragment from the blueprint for setting the temperature is
- service: climate.set_temperature
data:
temperature: !input frost_setting
target:
entity_id: !input thermostat_controls
Where ‘frost_setting’ is a number (usually 5) and ‘thermostat_controls’ is a Climate entity such as ‘climate.bathroom_towel_rail_thermostat’, or a list of such entities (hence the pluralisation)