Thanks for looking into this @Johnson145!

I'm not sure whether I completely understood why you have introduced the delay. I can imagine that initially the two thermostats were triggering each other in an endless loop?

Yes, that is about it, they were flip-flopping back and forth until one of them "won" which wasn't necessarily the temperature you were trying to set to.

If that was the problem, what do you think of replacing the delay with a check that ensures that climate.set_temperature will only get called, if there is actually a difference?

I had that in the version before the delay update, but it was not working consistently for some reason. I suspected, that the zigbee state get, returned stale data and because of that triggered another update when there was none to be made. The delay was the quick and dirty fix, but since you encountered other issues, that does not seem like a stable solution either.

Anyways, the current implementation basically does that check anyways, so I will do some testing myself and see if I can reproduce my previous issues. If not, I will update the blueprint accordingly.

Thanks for showing me the logging service by the way! I used to look at the traces all the time, but this might be more convenient.

I had that in the version before the delay update,

Ah interesting, didn't check your older revisions before.

but it was not working consistently for some reason

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?

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...