Synchronize the on/off state of 2 entities

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.

1 Like

@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.

  1. 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 }}

  2. I like your action code to act on all other switch/es, the code is so short and sharp. Fantastic!

  3. 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 }}

Thanks and really appreciate this blueprint.

I also am getting that error in my logs now

2022-03-05 16:32:04 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Restarting
2022-03-05 16:32:04 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Running automation actions
2022-03-05 16:32:04 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Executing step call service
2022-03-05 16:32:04 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'to_state' when rendering 'homeassistant.turn_{{ trigger.to_state.state }}'
2022-03-05 16:32:04 ERROR (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Error executing script. Error for call_service at pos 1: Error rendering service name template: UndefinedError: 'dict object' has no attribute 'to_state'
2022-03-05 16:32:04 ERROR (MainThread) [homeassistant.components.automation.sync_floods] Error while executing automation automation.sync_floods: Error rendering service name template: UndefinedError: 'dict object' has no attribute 'to_state'
2022-03-05 16:32:11 INFO (Thread-4) [wirelesstagpy] Start listen for push update
2022-03-05 16:32:39 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Restarting
2022-03-05 16:32:39 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Running automation actions
2022-03-05 16:32:39 INFO (MainThread) [homeassistant.components.automation.sync_floods] Sync Floods: Executing step call service

Version: 2022.3.1

I can confirm that I’m getting this error now as well, it started as soon as I upgraded to 2022.3.0.

This Blue Print works extremely well for quite a while then recently started throwing this error:

Error: Error rendering service name template: UndefinedError: 'dict object' has no attribute 'to_state'

I’ve taken the ideas presented here (especially @hebus’s fantastic template work above) and created a new blueprint which allows the selection of multiple switch devices.

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?

Nice, it works for me using 2 and 3 switches, thanks! It is very easy to extend

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.

Help would be much appreciated.
Thanks

2 Likes

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: -
image

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 :slight_smile:

image

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. :slight_smile:


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. :man_shrugging:t2: