Unexpected service call check for automation that has not triggered

[AJStubbsy (Adam)]

Every time I restart HAOS, I’m getting a repair suggestion.

It’s because one of my entities is created by an esphome device and it’s state is ‘unavailable’ during start-up, resulting in this error
The automation "Synchronize states" (automation.synchronize_states) has an action that calls an unknown service: homeassistant.turn_unavailable.
I’ve adjusted the automation (which came from a Blueprint), so that it doesn’t trigger from ‘unavailable’ and so it doesn’t actually trigger during start-up. I can see that the error was shown upon restart but the automation hadn’t triggered in the last 9 hours.

I’ve cleared the cache from my Chrome browser, just in case it was showing some legacy error message but it reappears after every restart. I’m surprised that a service call is being checked if the automation hasn’t even triggered.

Here’s the amended Blueprint: -

  name: Synchronize states
  description: Synchronize the on/off state of 2 entities
  domain: automation
  input:
    entity_1:
      name: First entity
      selector:
        entity: {}
    entity_2:
      name: Second entity
      selector:
        entity: {}
  source_url: https://community.home-assistant.io/t/synchronize-the-on-off-state-of-2-entities/259010
mode: restart
max_exceeded: silent
variables:
  entity_1: !input 'entity_1'
  entity_2: !input 'entity_2'
trigger:
- platform: state
  entity_id: !input 'entity_1'
  not_from: "unavailable"
- platform: state
  entity_id: !input 'entity_2'
condition:
- condition: template
  value_template: '{{ states(entity_1) != states(entity_2) }}'
action:
- service: homeassistant.turn_{{ trigger.to_state.state }}
  data:
    entity_id: '{% if trigger.from_state.entity_id == entity_1 %} {{ entity_2 }} {%
      else %} {{ entity_1 }} {% endif %}'

As said, the only addition, from the original, (Synchronize the on/off state of 2 entities) was to include not_from: "unavailable". It was suggested from a Discord discussion as a possible solution but I’m still getting the error and subsequent repair suggestion.

Here’s the automation yaml: -

description: ""
use_blueprint:
  path: adchevrier/synchronize-the-on-off-state-of-2-entities.yaml
  input:
    entity_1: binary_sensor.hot_water
    entity_2: input_boolean.hot_water

Thanks Petro for confirming this is unexpected behaviour and for taking a look, it’s much appreciated.

[123 (Taras)]

The automation’s two State Triggers will trigger if the entity’s state changes to unavailable.

When that happens (potentially on startup), the value of trigger.to_state.state is unavailable. As a consequence, your service call’s template will produce:

homeassistant.turn_unavailable

That’s what the error message is complaining about:

unknown service: homeassistant.turn_unavailable

Either enhance the State Triggers to ignore the state changing to unavailable or add a Template Condition that rejects: trigger.to_state.state == 'unavailable'

[AJStubbsy (Adam)]

That doesn’t seem to be the behaviour that I’m experiencing. Originally, I didn’t have not_from: "unavailable" in the trigger and every time I restarted HA the automation would trigger (for the very reason you have explained above). When I added not_from: "unavailable", the automation stopped triggering on restart but I’m still getting the error. In my post above I could see that the error was reported on restart but the last time the automation had triggered was 9 hours before that.

I should point out that I have gone through the process of clearing the error i.e. I’ve had to click to say I have resolved the problem and then hit submit, it just pops back up again if I restart HA.

[123 (Taras)]

@AJStubbsy

That doesn’t seem to be the behaviour that I’m experiencing

Your service call’s template:

service: homeassistant.turn_{{ trigger.to_state.state }}
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

is producing:

homeassistant.turn_unavailable
                   ^^^^^^^^^^^

because the value of:

trigger.to_state.state

is unavailable because these two State Triggers:

- platform: state
  entity_id: !input 'entity_1'
  not_from: "unavailable"
- platform: state
  entity_id: !input 'entity_2'

will trigger if if either entity’s state changes to unavailable.

It’s doing exactly what you programmed it to do. However, I suspect you assumed the state-change would never be to unavailable (only to on or off ). It’s definitely changing to unavailable because the error message is complaining that the automation’s action has called an unknown service named homeassistant.turn_unavailable.

When that error occurs, a quick look at the automation’s trace is certain to reveal that the value of trigger.to_state.state is unavailable.

[AJStubbsy (Adam)]

Your explanation is spot on, I’ve already written the reason for the error in my first post but, as I’ve described and shown from the last time the automation triggered, it is not triggering when the device is changing from ‘unavailable’ to ‘on’/‘off’. My whole reason to try and discover why this strange behaviour is occuring is because it appears that the service call, for this automation, is being checked, even though the automation has not triggered.

The automation last triggered 36 minutes ago, when I turned my hot water on to test.

I’ve just restarted and the automation did not trigger but the error has popped again

The docs do seem to suggest that not_from will filter triggering from undesirable conditions but I know you know your stuff, so I’ll definitely look at the template condition instead. However, it doesn’t change the fact that the automation did not trigger during restart (probably the device wasn’t ‘unavailable’ this time and it possibly was equal to the state of entity_2) and yet, for some reason, the ‘unavailable’ state was passed through to the action and the ‘unkown’ service_call was, as you’ve pointed out, homeassistant.turn_unavailable. I can’t understand why it’s passing through trigger states when the automation has not triggered.

[123 (Taras)]

Immediately after startup, is there anything posted to the Log that is related to this issue?

As an experiment, change the State Triggers to this:

trigger:
- platform: state
  entity_id: !input 'entity_1'
  from:
    - 'on'
    - 'off'
  to:
    - 'off'
    - 'on'
- platform: state
  entity_id: !input 'entity_2'
  from:
    - 'on'
    - 'off'
  to:
    - 'off'
    - 'on'

It explicitly specifies the only state-changes allowed to trigger the State Trigger (basically, on → off or off → on).

[AJStubbsy (Adam)]

There’s nothing in the system logs relating to this, it’s just a repair notification at the top of the settings page.

I have changed the Blueprint to this: -

blueprint:
  name: Synchronize states
  description: Synchronize the on/off state of 2 entities
  domain: automation
  input:
    entity_1:
      name: First entity
      selector:
        entity: {}
    entity_2:
      name: Second entity
      selector:
        entity: {}
  source_url: https://community.home-assistant.io/t/synchronize-the-on-off-state-of-2-entities/259010
mode: restart
max_exceeded: silent
variables:
  entity_1: !input 'entity_1'
  entity_2: !input 'entity_2'
trigger:
- platform: state
  entity_id: !input 'entity_1'
  from:
    - 'on'
    - 'off'
  to:
    - 'off'
    - 'on'
- platform: state
  entity_id: !input 'entity_2'
  from:
    - 'on'
    - 'off'
  to:
    - 'off'
    - 'on'
condition:
- condition: template
  value_template: '{{ states(entity_1) != states(entity_2) }}'
action:
- service: homeassistant.turn_{{ trigger.to_state.state }}
  data:
    entity_id: '{% if trigger.from_state.entity_id == entity_1 %} {{ entity_2 }} {%
      else %} {{ entity_1 }} {% endif %}'

I cleared the error from the settings page, restarted HA and the same notication has popped up

The last time the automation triggered is 1 hour ago now

I think I’ll completely delete that automation and blueprint and rewrite the lot, using the trigger you’ve suggested, just to be sure there’s not something being stored in memory somewhere.

Thank you for looking in to this, I really appreciate it.

[123 (Taras)]

So after making the change I suggested, the Repair feature reported the same error after startup.

Go to the automation’s trace (the one that was produced on startup) and check two things:

1. Confirm the code that was executed contained the modified State Triggers.
2. Check the value of trigger.to_state.state (i.e. is it unavailable).

If there’s no trace produced for the automation on startup then I don’t know why the Repair feature is complaining (and I feel it would justify reporting it as a bug).

[AJStubbsy (Adam)]

The very last trace for this automation was triggered well before my last restart and it didn’t get to the action because the two entities already had the same state i.e. it was triggered because the input_boolean state had been changed to match the binary_sensor state.

Once again, thanks for your help. I’ll look at reporting it as a bug but I’ll see if I can stop the behaviour first by starting fresh and then I’ll be in a better position to see if it’s more related to the actual blueprint/automation or a quirk in my system.

[cwhits (Chris Helming)]

if you create an issue on github can you post it here so people can subscribe?

I’m leaning toward “{{ trigger.to_state.state }}” not being defined because it’s not actually being triggered when it runs its check. I’m doubtful that any changes to the trigger will make a difference.

[AJStubbsy (Adam)]

@cwhits @nullex Here’s the issue I have raised regarding the unexpected behaviour.

Unexpected service call check for automation that has not been triggered.

I can confirm that rewriting the automation in the UI rather than using the blueprint, does stop the behaviour but I appreciate that negates the point of having blueprints in the first place, I just wanted to check.

[nahwel]

Hi, I’m having the same issue with the same blueprint. Was wondering if you guys got any update?

[AJStubbsy (Adam)]

There is a post in the blueprint conversation (Synchronize the on/off state of 2 entities - #64 by Samedarkclouds), where a user has suggested there may be missing quotes but it didn’t resolve the issue for me.

[morilm (Miguel Morillo)]

It did resolved for me (after restart)…

action:
  - service: 'homeassistant.turn_{{ trigger.to_state.state }}'

[nahwel]

Thanks for the tip. Unfortunately, it didn’t resolve it for me either…

[Samedarkclouds]

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. The fixit is likely because the devices unavialbality status was in play at startup. I really think the update destabilized zwave, or at least zwave2mqqt, in a notable way. I am getting far more dead or unavailable devices and its making it seem like automations are broken.

[AJStubbsy (Adam)]

Have you tried changing the trigger for your automation, or including a condition, so it doesn’t trigger on a state change including ‘unavailable/unkown’, as Taras suggested earlier in the thread? My particular issue, is that I’m getting the error when the automation has not triggered. In your case, if you have received the error once your automation has triggered, then that is the behaviour you should expect.

[J.P.Goose (M)]

I’m experiencing the same error, also using an ESPhome device as well as an Alexa virtual switch, I tried a new version of the Blueprint (different author- Link On/Off State of Multiple Devices) and that doesn’t work at all so I’m just going to put up with the error since it doesn’t affect the operation of the blueprint.

[gepetto]

I have found a solution, not so fancy but is working.
Two automation with trigger homeassistant that stop the automation when home assistant is shuting down and turn it on when home assistant is turned on.
For now is working no more repair warning

[ecsfang (Thomas Fänge)]

I have the same problem, but I’m not using any Blueprint.

I have two (and only two) automations that uses the same kind of action:

  action:
    data:
      entity_id: light.kokslampa_matbord
    service: light.turn_{{ trigger.to_state.state | lower }}

I have not changed these in months, but quite recently (some weeks ago?) HA started to complain about them after a restart.

I noticed this because suddenly these two lamps (and only these two) was turned on after a restart of HassIO (e.g. after an update), and this hasn’t happened before.

As @AJStubbsy suggested, it is as if the automation is being “verified” during startup, and the to_state.state is then “unavailable” - and is therefore reported as an error - without the automation being triggered (in my case, the automation is only triggered by a light switch or a remote control).

After startup the automations seems to work ok - so there is probably nothing wrong with the automation or action, but something has changed/been added that checks/verifies the automations during startup and reports any errors found.

I will try the suggested fix by @gepetto to turn off these two automations during shutdown and then on again with a short delay after the system is up and running again.