-
-
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 }} |
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...
That definitely sounds plausible.
I would have expected the
selectattr | map(attribute='attributes.temperature')to basically be equivalent tostate_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 :)