Edit: This was not the answer. It worked intermittently that’s only because the “unavailable” status of the zwave device cleared. This message comes form the state of the sync device being “unavailable” which appears, in my case, to happen excessively since the recent update. Its not the automation or blueprints failing, its the devices lack of availability at the time of triggering.
Line 29 of “/config/blueprints/automation/adchevrier/synchronize-the-on-off-state-of-2-entities.yaml” should read
I added the quotes but I still get a Repair notification/error pop up, even though the automation hasn’t triggered.
I thought I was maybe getting a historical error but this time I deleted the old automation, changed the code, as you suggested, created a new automation and changed the name but I’m still getting the error.
With this blueprint you can now select any combination of lights, switches, or other devices which support the homeassistant.turn_on/homeassistant.turn_off service calls. This also addresses the repair errors on startup.
For whatever it’s worth, here’s how I’m handling the problems you’re seeing above:
- condition: template
value_template: '{{ trigger.to_state.state != trigger.from_state.state }}'
- condition: template
value_template: '{{ (trigger.to_state.state == "on") or (trigger.to_state.state == "off") }}'
- condition: template
value_template: '{{trigger.to_state.context.parent_id is none or (trigger.to_state.context.id != this.context.id and trigger.to_state.context.parent_id != this.context.id) }}'
The first condition is in the existing blueprint, no surprises there.
The second condition makes sure that the only states we’re dealing with are “on” or “off”. Because I’m allowing entities from any domain, those entities might have any variety of state, or they might be “unknown” etc. Instead of trying to figure out every possible “bad” state using not_to, instead let’s just throw out anything that isn’t on or off. Nice and easy.
The third condition is ripped straight off from @hebus from this post. This condition prevents “self-triggering”. We’re making sure that the action which turned a given entity on or off wasn’t this automation itself. Say I select 5 devices, and then turn one off. The automation will pick up that trigger then turn the other 4 entities off. Doing so will then trigger this same automation 4 more times, as 4 of the entities have now all changed state. This condition will catch that happening and discard the duplicate triggers.
So, we are getting the fixit that says " The automation “SB_Swt Set: GlryW_LRWscene Sync/Mirror” (automation.new_automation_3 ) has an action that calls an unknown service: homeassistant.turn_unavailable ."
“Unavailable” is actually what being returned to the template. Which means the issue isn’t that there’s a problem with the code, or with the blueprint, its that “unavailable”, AS A STATE is being returned at the time it throws the error. When I looked at my logs for my zwave devices it became obvious that they were “dead” ALOT more since the update. I think the issue isn’t with the automations or the blueprints, I think its something about the connectivity, and when the automation is trying to do its thing to the device, the device is “unavailable.” It explains why a restart might help or not. It explains why its intermittent.
My zwave network is just spastic literally since I updated. I soft reset, hard reset, reinterviewed… works for a while, then starts throwing unavailable or dead logs.
Anyway, I am intermediate at best with this thing, but I thought I should through it out there… you may be hunting for a fix that isn’t actually part of the problem.
@Samedarkclouds you are spot-on to what’s happening here, but I’ll add that all devices are “unknown” on startup. As a result you’ll have this firing during startup while devices are being loaded, some of them are “unknown”, and you’ll see the results you’ve been getting. This will be true even on a healthy Z-Wave environment and for not-Z-Wave stuff too.
In my post above, the 2nd condition is the solution which handles this. tl;dr - ignore any state that isn’t on or off.
Great one, love it, I would also make it possible to expand it to more than just 2, and sync luminosity level and color this would be a game changer. And not only for lights. This is great
Luma,
this should not be needed and in my case generates faults I swith one of the triggers but the others do not sync.
In reality when the automation is run again for “auto trigger” it will find the triggers already in the new state so condition 1 will exit with no damage.
Am I wrong?
@luma I have an issue.
If I add the third condition… 30% of the time the devices do not sync
if I remove it on BIG groups like 8 switches I got flip flops… continues to swith of and on
@luma I’ve put back all the conditions as above BUT sometimes it happens to me an infinite sequence of on/off.
Is a set of 8 sonoff switches connected via the automation.
Sometimes it happens to me that they start on/off very quickly and cannot stop it. I have to open home assistant, enter in the edit page of the automation, DISABLE the automation.
At that point after few secs everything is stable and I can put it on again.
I cannot see the traces as there are too many in too little time.
Is there any way I can undestand why this happens?
I’ve seen this too but I don’t know how to fix it yet. The problem is basically:
devices A and B are linked
turn A on and off quickly → sends B and on and an off command
B gets turned on - tells A to turn on
A is already turned off, so when it gets told to turn on it does - it also tells B to turn on
meanwhile, B is processing the command to turn off
hilarity ensues
The way we used to deal with this in the old days is that an event would come in with a timestamp that says when it was initiated. This is a little different from time_fired (which we do have), since an event that is triggered by another event would inherit the initiated time from the previous event. If a device already processed a later event it would ignore older ones. This means that the state object needs to store the initiated time, which is different from the last_updated and last_changed that we already have. To apply that to our example:
devices A and B are linked
turn A on and off quickly → sends B an On@t0 and Off@t1
B gets the On@t0 and turns itself on - sends A an On@t0
A is already turned off by this point with time of t1 (which > t0), so when it gets told to turn on with t0, it ignores it
meanwhile, B is processing the Off@t1, turns itself off - sends A and Off@t1
A sees t1 = t1 and either ignores it or checks if the states match to be safe, sees that they do, and then ignores it
Without that initiating timestamp in the states though, it’s much harder.
Extra credit: turn A on and B off at the same time.
I’m not sure this will handle all cases, but changing the mode from queued to restart seems to have fixed the problem for me. It helps that the event handling is centralized here, I suppose.
Rather than add a condition that is checked after being triggered, change the trigger itself to only occur for on and off? That way it is never called for unknown and unavailable states.
trigger:
- platform: state
entity_id: !input 'linked_entities'
to:
- 'on'
- 'off'
The automation "Synchronize states"
(`automation.synchronize_states` ) has an action that calls an unknown
service: `homeassistant.turn_unavailable` .
In my case, I was using the automation to syncronise the detached switch of a shelly 2.5 to control the always powered on smart bulbs in a particular room.
After reading @AJStubbsy efforts across multiple threads and the github. I too solved it by changing the triggers in the local blueprint yaml (synchronize-the-on-off-state-of-2-entities.yaml)
FROM
trigger:
- platform: state
entity_id: !input 'entity_1'
- platform: state
entity_id: !input 'entity_2'
TO
trigger:
- platform: state
entity_id: !input 'entity_1'
from:
- "on"
- "off"
to:
- "off"
- "on"
- platform: state
entity_id: !input 'entity_2'
from:
- "on"
- "off"
to:
- "off"
- "on"
The double quotations are important it seems. This fix works for me at the moment, although I haven’t had time to extensively stress test the remainder of the house and its automations.
Suggest @adchevrier investigate this change to the original YAML moving forward.
Seems like a great fix, the repair nags were annoying me too because of a Sonoff Mini with bad wifi reception that went unavailable sometimes for some seconds that I was syncing with another light.
Tnx!
This is great