Hello,
I have several automations that stopped working. When I open it and push the button for example, I see the blue confirmation box that it was triggered but actions do not run.
If I disable and enable the automation, it repairs. Is this a bug from last update?
Home Assistant 2022.10.4
Supervisor 2022.10.0
Operating System 9.2
check your traces on automation. It should tell you where it failed executing. disable/enable actions normally dont do much for automation execution.
It worked for years without troubles and stopped. Disabling/enabling repair it. There’s nothing to trace here. It worked and stopped.
It would probably make it easier to help if we could see the code for at least one of the automations that used to work but doesn’t anymore.
alias: FAN - TOILET - fan ON with on/off switch
description: ""
trigger:
- device_id: a887c351480d4785da12e20354e6699e
domain: deconz
platform: device
type: remote_button_short_press
subtype: turn_on
condition: []
action:
- type: turn_on
device_id: d9a72073f460cfd5689d1948072c2357
entity_id: switch.toilet_fan
domain: switch
mode: single
That looks pretty straightforward. Are there any warnings or errors showing up in the log? Have you tried tracing the automation? (I haven’t used that feature, but it’s supposed to help debug automations, so maybe it can shed some light.)
If none of that helps, maybe enable some debug output and restart HA and try again:
logger:
default: info
logs:
homeassistant.components.automation: debug
homeassistant.core: debug
homeassistant.helpers.script: debug
“there’s nothing to trace” - that would be the case is you don’t have an automation 
The trace is supposed to provide a step by step plan what has been executed - and why - and if the execution was successfull or - if not, why it has failed.
So … yes, it is a debug option that should help to figure out, why exactly an automation “did nothing”.
A different topic would it be, when the automation state does indicate, that the automation was not triggered at all…
I am not sure, if THAT would be visible in the traces.
“there’s nothing to trace” was meant regarding the simplicity to the automation, as you can see on the code
“the automation was not triggered at all” - as I said, I see the bluebox giving me the message that the automation was triggered.
The WHOLE point here is that this super simple automation stopped working after years after the update.
My logs are empty.
The automations, and about already five other identified, are working. What else won’t is beyond my capacity to recognize.
the code of your automation might be simple and small.
But that doesn’t change anything on the statement that traces would be helpful for an rootcause analysis WHY the system has not performed the configured actions.
IF the automation was triggered, the trace information should show, where - and why it has failed to perform the configured action.
Everything else is guess-work.
Looks really as a similar problem.
I cannot trace it now, when it works after disable/enable process, so this is more a report of unexpected behavior of HA.
If you do new automation and and remake it (same trigger, same action) then view the YAML, are the device IDs the same? Perhaps the device entries got recreated by the integration somehow?
Device IDs are hardcoded strings in the entities.yaml, to my shallow knowledge from the age when a lot of stuff was edited directly in HA.
that it cannot be traced after disabling and enabling it - ok… and sorry - if my words might sound a bit rude…
I just wanted to show how a failed automation would look like in the traces (but unfortunately, I don’t have one that has failed recently)…
But in the future, that would REALLY a big additional help
No offense here. It’s pitty I cannot trace it now but you know, I thought the battery is gone, than saw 80% and the bluebox, I was surprised and did not think about the trace given the simplicity of the automation (zigbee mobile switch triggering a shelly switch in the wall that is connected to the fan).
However, @samuel81 has apparently similar experience and he has traces, look at his case.
No they are generated GUIDs by HA core when an integration adds a device. This is why a lot of advanced users avoid them in all automations since if you replace a device you get a brand new device ID and have to update all your automations and scripts.
It also used to be that if you removed and re-added the device or integration then you also got all new device IDs which was really bad. That’s supposed to be fixed but perhaps you found an issue with the deconz integration causing you to get new device IDs for your existing devices. That’s why I was asking you to check if you got the same values when you remade the automation.
You could rule out the device ID issue by changing the action to:
action:
- service: switch.turn_on
entity_id: switch.toilet_fan
The device IDs are the same after creation of a new automation.
True, throught the graphical UI, it produces the following code:
- service: switch.turn_on
data: {}
target:
entity_id: switch.toilet_fan
Yeah, that’s the newer, fuller syntax, but what I suggested should still work. Either way.
But does this make it work now?