I use homeassistant quite a while now but that is the first time I cant figure out what is going on. Spent already several hours on it. I updated to 0.84 yesterday and since then no automation is working anymore. Removed all of them beside two for debugging and still cant find the problem. Only thing I see in the logs is:
2018-12-13 11:39:13 DEBUG (MainThread) [homeassistant.components.automation] Automation automation.1_debug_switch_on initial state False from recorder last state <state automation.1_debug_switch_on=off; last_triggered=None, id=debug1, friendly_name=1 Debug Switch On @ 2018-12-13T11:38:55.131475-07:00>
2018-12-13 11:39:13 DEBUG (MainThread) [homeassistant.components.automation] Automation automation.1_debug_switch_off initial state False from recorder last state <state automation.1_debug_switch_off=off; last_triggered=None, id=debug2, friendly_name=1 Debug Switch Off @ 2018-12-13T11:38:55.131958-07:00>
I tried to remove automation from history and recorder but that don’t change these messages and they are not getting triggered. I don’t even see the box opening if I click on the automation in the GUI where I usually could trigger them. Does someone has an idea what I can do here?
Answer myself here. Of course shortly after writing it down I found something which seems to work. I had to add “initial_state: true” to every automation in order to make it work again. The documentation states something about on/off for this parameter which is not working. Wonder why I am the only one with this problem.
leads to this then:
2018-12-13 12:02:55 DEBUG (MainThread) [homeassistant.components.automation] Automation automation.1_debug_switch_on initial state True from config initial_state
2018-12-13 12:03:02 INFO (MainThread) [homeassistant.components.automation] Initialized trigger 1 Debug Switch On
2018-12-13 12:03:21 INFO (MainThread) [homeassistant.components.automation] Executing 1 Debug Switch On
ah, well, i didnt had that line before at all
and sometimes when i restarted HA, all my automations were in OFF state
then i added that line, and now everty time i do a restart, my automations are ON
They changed the way states are stored/restored in 0.84. However, on “first start” with 0.84, it can’t restore the state properly for some items. If you show your automations in the GUI, you will see each has an on/off switch next to it… if they are off your automation is disabled. So make sure they are on should stay on through restarts (or off through restarts if that’s what you want)
I just reverted to 0.83.3, because no automations worked with 0.84.1 . I’ve read about the new “state tracker” and that it causes a loss of all states when initially started. Didn’t think about automations, this should definitely mentioned in the breaking changes …
It is of course my missing mental capability to interpolate this info to the absence of working automations. But - never mind, an automation.turn_on without arguments did the trick.
My comment isn’t about your mental capacity, it’s more about you complaining about the devs not doing something when they did. These guys are doing these changes for free for other people and here you are complaining without reading the changes. Mind you, this occurred directly after you reply to another user who posted the exact breaking change you complain about.
I have some iisue with automation and time conditions… time conditions don’t seem to be taken into account. I have to make further investigations and report but it is strange that since last upgrade some automations don’t ork the way they worked before and the way they are supposed to work
@thundergreen Go to /dev-service (classic UI) and run service “automation.turn_on” without an entity_id. This will enable all automations again and assuming the storage helper works, they will stay on. Alternatively, you could add an attribute “initial_state” with ‘on’ value to each of your automations and reload them.
From a developer’s perspective, this has been mentioned properly by breaking change “State restoration will not work the first time you start 0.84.” . Don’t criticize the devs, they do it for free.
I’m not sure. They may have purposely downgrade. I’ve heard people having issues with !include which could be a result of this downgrade. I don’t know enough about the yaml parser. Think this would best be discussed on the discord server where the mods can respond.
o no! please don’t get me wrong… I don’t critisize at all… it’s more related to my time conditions. I set for example after: ‘10:00:00’ and before: ‘20:00:00’ but this automation would fire even at 09:00:00 and it turn on a light which has even not been set in this automation but in another automation which should fire at this time .
Thank you so much for this! I first thought this problem was related to mqtt since all my automation triggers depend on it. I was following all the guides that currently report issues for mqtt, without success. I spend and hours and days until I realized that only the automation part was affected. Did some googling, found this discussion and problem solved within a minute!