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.
1 Like
“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.
1 Like
You could rule out the device ID issue by changing the action to:
action:
- service: switch.turn_on
entity_id: switch.toilet_fan
2 Likes
The device IDs are the same after creation of a new automation.
1 Like
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?
Strange, I’m really not sure then. So when you press the button on the remote you see the blue “triggered” in the UI but nothing happens? Or you don’t see the blue “triggered” and nothing happens at all?
If it’s the second one what I would probably do to debug is go to Developer Tools → Events and see if I can capture the raw event. Unfortunately device triggers hide what the actual event type is which makes this a bit tricky. But what you can do is put * as the event type to listen to since that will listen for any and all events. Click “start listening”, press the button on the remote and then immediately press “stop listening” before you get flooded with events. Make sure you can find one in the list that comes from your deconz remote to see that it’s working, if not then that’s your issue.
If it’s the first one (you see a blue “triggered” but nothing else happens) then I’m at a loss. I don’t really understand how that could occur. Maybe debug logs can give some clue but it makes no sense why the actions wouldn’t fire if the automation was triggered without an error in the logs.
Yeah, something is missing here.
@Vahaldor I’d still suggest adding the debug logging I suggested above (and then restart HA.) Everything the automation is doing should go into home-assistant.log which should allow you to better understand what’s happening (or not happening.) I’d be happy to help interpret the messages if you’re not familiar enough with this logging output. I pretty much overhauled the automation/scripting infrastructure, but I haven’t touched it in a while, so I don’t know if something has recently changed that could be causing your issues. Also, I wasn’t involved with the tracing support that was added and have never used it, but I would think that should help, but don’t really know.
Thank you ALL for your care here! But given the fact that disabling/enabling the automation made it working again without possibility to replicate the problem, I think we won’t be able to move on here .)
To @CentralCommand I SAW the blue box but as I said I cannot replicate it, I now see the bluebox but the actions are executed.
I did not have anything in logs, so there’s nothing to dig here.
Good idea is to capture the raw event. I will try that if the problem surface again.
@pnbruckner Thanks for the idea. I will run this debug and see whether the problem surface or not.
Thanks all for your time and ideas!