This one work perfectly so far. Thanks @hebus , I have tried everything including fast clicking of either switch, never get into flipflop situation. I like the fact that you did not use the delay method, which I think is not addressing the root cause. Great Job, Thanks…
If you have time to explain your blueprint line briefly, that will be greatly appreciated…for learning.
Just need to understand the “Condition” and “Action” code…
I disagree with @chinhhut, either his conditoin is different or he accidentally refer to the wrong blueprint. My condition: 2 zigbee wall switch, use Z2M, HASS on Pi4, ZZH dongle.
The condition filter out events that were triggered by the automation itself. The documentation is not very precise on the “context” field used here. I ended up with that condition through trial and error.
The action selects every switches that did not trigger the automation and turn them to the target state.
@hebus, thanks for the explanation. I studied your code and I did alot of permutation, not to doubt you but try to learn each and every line of the code.
What I found out. Actually you gave a very deep thought in the code.
In your second condition, you allow the manual switch trigger, you block the automation trigger but you allow automation triggered from outside of current session.
This is exactly my situtation, my light switch is also triggered by a motion sensor, very usefull.
1b. However I don’t quite understand the AND logic,
{{ trigger.to_state.context.id != this.context.id and trigger.to_state.context.parent_id != this.context.id }}
I like your action code to act on all other switch/es, the code is so short and sharp. Fantastic!
However, I find that the first condition is not neccessary (maybe I’m wrong), to_state and from_state isn’t by design they are not equal?
{{ trigger.to_state.state != trigger.from_state.state }}
I tried to remove the first condition and it does work perfectly.
Could you kind enough to explain 1b. please?
{{ trigger.to_state.context.id != this.context.id and trigger.to_state.context.parent_id != this.context.id }}
HI, I have a wall switch named switch.radio_button which fires script.radio. Script.radio turns on mediaplayer.onkyo + sets network mode and fires internet radio threw google cast integration - this works great.
I wanted to sync state of mediaplayer.onkyo and the wall button, after onkyo is turned on by remote controler or phisical button. This works …almost. Because every time sync is trigered, script.radio is also trigered.
Can you advice, how to use this blueprint, together with a condition, that sync should not triger the script?
Does anyone have a work around to stop the Repair Error - The automation "Synchronize states" (`automation.synchronize_states` ) has an action that calls an unknown service: `homeassistant.turn_unavailable` .?
I know that one of the entities’ state is ‘unavailable’ when HA restarts but that entity is created by an esphome device, so I don’t think I can give it a default value in HA.
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.
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.
@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.
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.