Unexpected service call check for automation that has not triggered

Configuration
22

Have you checked the automation trace to verify that the automation has not triggered? If yes, there’s an open issue on github that I posted above, it could help to add your experience to that.

If you do discover that the automation is triggering, these conditions that I’ve seen posted, might help resolve your problem: -

- 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) }}'
23

How to check the automation trace?
At least I can see that these two automation has not been triggered (last time was yesterday for one of them, and two hours ago for the other one) when I check the automation in the list of all automation - but the system was restarted just a minute ago and the error was again reported (other automation that are triggered by the restart are updated in the list - but the two “failing” automation are neither triggered or updated).

I can update the issue on Github with my findings as well.

Edit: I remember that I have recently installed the Watchman integration and thought that it might cause the problem - but disabling it didn’t help - the issue is still reported at restart.

Cheers,
Thomas

24

You are experiencing exactly the same problem I was (I’m not imagining it!! :laughing:). I was also checking the last triggered time from the automation list but the trace is a great way to check variables and conditions through your automations. You can access it from the 3-dots, menu, next to the automation: -
image

‘Traces’ stores information from the last couple of automations that were triggered and is a great way to debug an automation. You can use the up and down arrows, next to a trace, to skip from Trigger, through Conditions and finally Actions, to see the flow of an automation. Obviously, you won’t be able to see automations that have not triggered and so this was a means for me to be confident that my automation had not triggered and 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

Thank you for taking the time to include your experiences. Maybe someone will read this and/or the github issue and spot a solution. ATB

25

For anyone stumbling across this post. I’ve closed the github issue now. It seems that for this particular error, the automation does not log the fact that it has been triggered but instead only raises the error. Personally, I’d prefer the automation is shown as triggered because then you can see that the ‘unavailable’ state has been passed through to the action.

The ‘unavailable’ state is passed through if the desired trigger states are in single quotes: -

to:
  - 'off'
  - 'on'

but changing to double quotes seems to fix the problem: -

to:
  - "off"
  - "on"

This should stop the error from occurring.

Thanks to those who helped to find a solution and explain the behaviour.

26

So I have the exact same problem I’ve been trying to fix for a while now. Using the blueprint of sync states. Obviously, when HA restarts, the automation is trying to run when not everything is in a ready state and causing this error. Is there a way to delay the start of this blueprint running upon startup?

I see the above post on how to “fix it”, but I can’t find anything in the blueprint that has a “on” or “off” on it. Can someone post a corrected blueprint that fixes this issue? I’m a bit lost when it get’s this deep into the woods.

One of the devices is an ESPhome device. I see someone else above is also using ESPhome and getting the error, so maybe related.