Then don’t do that. shrug 
The automation is set in single mode, exactly to prevent that. I tested it quite extensively and never happened to me. There’s also a 200ms delay after the action, to throttle them.
mode: single
max_exceeded: silent
So I cannot reproduce the issue. Technically it shouldn’t happen, as per HA docs:
1 Like
sometimes people like to break things…to test, obviously. 
This is exactly why I was looking for this kind of blueprint.
1 Like
For me it seems to enter endless loop too. If it was able to just not run until last run is finished that would be nice. Maybe issue is slow zigbee devices. So it would need to validate that states have changed to consider the run finished.
Like I wrote in previous post, it has been configured in SINGLE mode. It works as described in HA documentation: it ignores new runs until the ongoing run is completed and it issues a warning (that I have silenced to not spam the log). So the loop can’t happen.
Why would anyone lie about getting the loop if I the did not get the loop?
It’s not a lie, just a wrong deduction.
BTW: I use it mainly on zigbee lights, some of them old and slow, and NEVER had a loop issue. And I also tried creating one…but failed to cause it.
Thanks for this blueprint. I do have a recommendation/request. Smart devices can be finicky sometimes. I was previously using AppDaemon with a follow the leader script to not only link the light, but ensure that if any of the follower lights had a connection issue for any reason (I experience this more with wifi bulbs more than anything else, especially since wifi devices are known to phone home via DNS calls and I do my best to redirect those calls using my router and/or adguard which can cause the device to briefly go unavailable when they are polling for the data), that they would follow the state of the leader switch when they came back online from being unavailable. This can easily done in yaml now using entity state triggers with choose and trigger ID conditions. I was looking at the code but didn’t notice any of those conditions included. Did I not look good enough and will this blueprint follow that logic? It would be nice to know that the linked entities have this feature should any of the lights decide to go unavailable for any reason.
Sorry Matt, I’m not sure I understood what you’re asking for: this is a very simple automation that I made because of a missing feature in HA Group functionality.
What you’re asking for is a sort of controller for grouped entities that makes sure they’re ALWAYS in the same state, if I understood correctly. If that’s the case, this is not the automation for that, but feel free to submit a PR, since you state that it can be “easily done”.
Okay, thank you. I have built the automation I’m referring to from scratch. Perhaps if I get some free time I can turn it into a blueprint, as I haven’t come across one yet.
You can check any blueprint code to understand how it works. It’s not hard.
This has been a great help in keeping my WiFi RGB lights in sync between the zigbee smart switch and their counterparts exposed in HomeKit (HK).
Changes in brightness made from the bulb or switch in both HK and HA all stay in sync.
Changes to the color made from the bulb in HK reflect the same in HA, but not the other way around. Wondering if that’s a limitation of HK or I am missing a setting somewhere.
I can’t thank you enough. I had to take/copy your code and add extra commands to the, “on to off” part for my particular situation, but I would have been lost without you.
Its brilliant.
Thanks to @TimU for helping as well.
MrGrey.
2 Likes
@alexdelprete thank you for this blueprint, it´s really usefull. Just a quick question, is it working 100% of the time for you? I realised in my case with only two switches added, if I turn off one of the switches the sync happens, but then if I turn off the other switch, the sync does not happen and the switches end up out of sync. If I then keep switching the second switch, the sync happens again, so it seems the failure only happens the first time I switch the second switch after switching the first switch. I have checked the logs and there isn´t any error there, any idea why this might be happening?
Sorry, never happened something like this. First time I see a report like that. I would concentrate on that second switch, and use automation trace log to see what’s happening.
I´m not too familiar with blueprints and automations as I mainly use node red, but it seems the automation is stopping because the conditions are not met, but I´m not sure why as I have confirmed that the status of the second switch is correctly changing from off to on in home assistant.
This is an example of a correct execution at 10:33:06:
And after that this is one where the sync didn´t happen at 10:36:31:
Logs don´t say much, is there a way to get more logs to understand what is happening?
Hi heisenberg,
Look at the trace immediately before this one. The condition makes sure the thing doesn’t try to duplicate itself, so the trace immediately before this has likely ran fine and this is a duplicate, at least that’s what I get by glancing at the code.
Are they toughly the same second in execution? If so keep going back.