After the recent 83 update, triggers do not seem to take effect on my automations. Has anyone else had the same issue? I’ve even rolled back the update and no change.
The automations work fine if I manually trigger them. I can see switches working which are used for the triggers and the config is all correct.
You’ll need to post your automations…
It’s not allowing me to upload the automations and I can’t copy and paste them for some reason, so hopefully this works:
https://drive.google.com/folderview?id=1lMIA147KM5GSH4duZEHL13UspWaf_glf
My guess without clicking on a random Google drive link is that none of your automations are set to initial_state: on and on one of the recent upgrades it has refactored your database, causing the saved state of the automations to be lost, and now they’re all switched off.
The Google link is a folder of the two automation files. They are all set as on and they work if you manually trigger them too in the UI. The triggers are wireless buttons mainly and they show functioning in the logs.
You need to paste the text from the files with formatting as per the instructions at top of page
I reinstalled in the end, will remain a mystery!
is that the new default? Previously, when no initial_state was set, automations were automatically On.
Im finding the update stops running scripts to their end…Ill link as to not spam this thread, but would appreciate your thoughts on the matter
Mine all work now after I put a line in each my automation scripts at the beginning right after the alias: line of:
initial_state: truebut you don’t want that, because now after each restart they are all on, while you might have reasons to have them restore state. In fact, by using initial_state, you prevent restore state from working at all…
Or this must have changed completely.
Yes I only use initial state true for ones I want to always be on. The new state seems to work fine after first start of 0.84.x
Read my post properly before quoting one small bit of it and going off on a tangent 
The default behaviour hasn’t changed, but if you don’t set an initial_state you have to be prepared to lose the ‘saved’ state once in a while, especially when the release notes for a new version explicitly tell you that due to changes in that release the saved state is not going to work when you upgrade but will continue to work from the next restart.
Sure, in fact it isn’t so different from an enduser perspective. States are (re)stored, and if a state hasn’t been stored before, one needs to set it/trigger it manually once.
I had it behave like that before many times when it relied on recorder also. Between updates, and mishaps.
Which brings me to the question wether we still need recorder to watch these components entities? Ive explicitly included the items I need restore state for, but didn’t read about that in the release notes?
My problem wasn’t the initial state thing. It was the fact the event type had changed. It used to be just
click
but now it’s
xiaomi_aqara.click