Yea, I’m also facing this issue with this blueprint… I did come across: Unexpected service call check for automation that has not triggered
but I think @adchevrier would have to fix it in his blueprint.
1 Like
It is possible to adjust the Blueprint, as it gets saved to your device. The automation calls the Blueprint from your local directory: -
I haven’t been able to discover why the service call is being checked, even if the automation doesn’t trigger but I can confirm that deleting the blueprint and generating the automation in the UI, stops the problem from happening.
This clearly defeats the purpose of blueprints but I wanted to see if that was the case.
I need to write up a bug when I get chance, hopefully tomorrow.
1 Like
oh lmao I completely missed the fact that you were OP of the post I linked…
good to know though and thanks for the info, and for submitting the bug!
1 Like
I am also facing issues after the latest updates of HA such as unavailable services.
I hope @adchevrier could check this . thanks 
1 Like
Also experiencing this issue after latest update
@Fotis_Kanellopoulos @smarthomelawyer Out of interest and if you have the time, I would be grateful if you could take a look at this topic: -
I have found that even if the automation does not trigger, I still get the Repair notification. I have raised this as an issue on github (linked at the bottom of the topic I copied in) but I can’t seem to explain myself very well because every response has been that this is expected behaviour when an entity is ‘unavailable’, which is understandable if the automation is triggered. However, I am receiving the notification even if the automation has not been triggered (there’s no trace and the logbook shows the last time the automation was triggered was well before the Repair notification). In this case, if the automation isn’t triggered, the state of the entity should not be passed through to the service call.
I’ve only posted the issue because it seems odd and is repeatable and others experienced the same issue. I rewrote the automation in the UI and haven’t had the same problem but this negates the point of using blueprints, so hopefully, if adchevrier adjusts the blueprint, it will fix things for you.
In the interim, if you look at the link I copied above, there are suggestions to adjust your blueprint (thanks Taras). It is possible that the adjustments to the trigger will work for you and prohibiting a trigger from ‘unavailable’ might be the solution. Personally, I tried this and it did not make any difference i.e. the original automation would trigger if the entity-state was unavailable (to be expected). However, sometimes the entity-state was not ‘unavailable’ and so the automation did not trigger but the notification still persists - after adjusting the trigger, the automation would never trigger when the entity was ‘unavailable’ and the Repair notification still pops up regardless (having cleared it every time).
Hopefully, just eliminating the state change from ‘unavailable’ will solve this problem for you. Whether you or adchevrier implement the change, it would be great if you could update the github issue, if you find a fix.
Thanks.
3 Likes
@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.
2 Likes
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).
2 Likes
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.
Link On/Off State of Multiple Devices v1.0.0
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.
2 Likes
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.
1 Like
@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.
1 Like
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) }}'
1 Like