-
-
Save Basanites/094e140c29ead05e92de31aaef5312a6 to your computer and use it in GitHub Desktop.
| blueprint: | |
| name: Sync TRV setpoints | |
| description: Sync the temperature setpoints of two TRVs. If one of them is changed, | |
| the other one gets updated automatically to the new value. Can also be used to | |
| sync the setpoint of a versatile thermostat valve opening entity to its physical | |
| counterpart. | |
| domain: automation | |
| input: | |
| trvs: | |
| name: TRVs + climate | |
| description: TRVs and climate objects to sync the setpoint temperature for | |
| selector: | |
| entity: | |
| filter: | |
| domain: climate | |
| multiple: true | |
| variables: | |
| trvs: !input trvs | |
| trigger: | |
| - platform: state | |
| entity_id: !input trvs | |
| attribute: temperature | |
| condition: | |
| - condition: template | |
| value_template: > | |
| {% set temps = states | selectattr('entity_id', 'in', trvs) | map(attribute='attributes.temperature') | map('float') | list %} | |
| {{ temps | max != temps | min }} | |
| action: | |
| - service: climate.set_temperature | |
| data: | |
| temperature: '{{ trigger.to_state.attributes.temperature | float }}' | |
| target: | |
| entity_id: > | |
| {{ trvs | reject('eq', trigger.entity_id) | list }} |
That definitely sounds plausible.
I would have expected the selectattr | map(attribute='attributes.temperature') to basically be equivalent to state_attr(entity, 'temperature') though, so it would still do the same now, not sure.
Maybe it was also some wonkiness that got introduced from VT and is now fixed 🤷 . Anyways, glad it works consistently now :)
I would have expected the selectattr | map(attribute='attributes.temperature') to basically be equivalent to state_attr(entity, 'temperature') though, so it would still do the same now, not sure.
It should. Now I'm confused, too. I tried quite a few different scripts yesterday. Looks like I shared not the one I wanted to share. My previous version contained a condition like this:
- condition: template
value_template: >
{% set current_temp = state_attr(trigger.entity_id, 'temperature') | float %}
{{ current_temp != trigger.to_state.attributes.temperature | float }}
So my reasoning was that trigger.to_state.attributes.temperature instead of using state_attr twice prevents the race condition.
As I didn't actually include that change in the version I sent to you, I don't have an explanation why it may have fixed the problem... I'll double check which variant I'm actually using again.
Maybe it was also some wonkiness that got introduced from VT and is now fixed 🤷
Maybe it's just that...
Ah interesting, didn't check your older revisions before.
I may be wrong, but to me it looks like your previous implementation was not using the temperature contained in the triggered automation, but instead requested the current temperature of the device again. I mean not for changing the temperature, but for comparing the two values. I can imagine that approach was open to race conditions because of that?