@AJStubbsy @smarthomelawyer
Someone proposed to me to add the “not_to” for states “unavailable” and “unknown” to triggers.
It seems right to me so that those 2 states do not synchronize.
So I have gone ahead and added those lines to the 2 blueprints that I use.
So far I have not come up again with the error but I will leave it there as a testing phase and wait if it comes up again.
Maybe you could try that also. 
I completely changed the trigger so it should have only triggered if the state changed from/to on/off but I continued to have the error, even though the automation trace suggested the automation had not triggered. Very strange but thank you for confirming you were able to resolve the issue.
Thanks! I’ll test it out now and see how it goes
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
- service: 'homeassistant.turn_{{ trigger.to_state.state }}'
The blueprint doesn’t have the quotes and while prior to the update it worked anyway, the update isn’t excepting the mistake.
I added the quotes and was back up in seconds (after restart).
Have you restarted HA?
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. 
I’ve released a new version of my original blueprint that now allows the selection of any number of entities from any domain.
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.
OK, I think I get what’s going on here.
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.
Im getting this “error” also but my devices are Tasmota Wi-Fi connected.
With this Blueprint now everything works has expected 
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 
— update —
this seems to be stable:
condition:
- condition: template
value_template: '{{ trigger.to_state.state != trigger.from_state.state }}'
- condition: template
value_template: '{{ trigger.to_state.state != "unknown" }}'
- condition: template
value_template: '{{ trigger.to_state.state != "unavailable" }}'
- 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) }}'
@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?
M
Yes,
a small check to see that the trigger.to_state.state in ('on','off')
would fix this
I’ve seen this too but I don’t know how to fix it yet. The problem is basically:
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:
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'
any luck with this?