Automations with 0.84

antistes · December 13, 2018, 6:51pm

Good morning.

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?

Thanks

antistes · December 13, 2018, 7:18pm

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.

id: debug1
alias: ‘1 Debug Switch On’
initial_state: true
trigger:
platform: state
entity_id: input_boolean.test_script
to: ‘on’
action:
service: input_select.select_option
data:
entity_id: input_select.test_select
option: ‘On’

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

pergola.fabio · December 13, 2018, 7:41pm

ah, so this line is not working anymore then?

initial_state: 'on'

does it needs to be changed to :

initial_state: true

antistes · December 13, 2018, 8:12pm

Just a quick test initial_state: 'on' seems to work too. My problem was that I didn’t have this parameter and without it the automations were stuck.

pergola.fabio · December 13, 2018, 8:13pm

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

ha_steve · December 13, 2018, 10:14pm

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)

m0wlheld · December 14, 2018, 6:11am

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 …

pergola.fabio · December 14, 2018, 6:55am

Why not just put the initial state on true? Didn’t that fix it?

m0wlheld · December 14, 2018, 7:05am

I‘ve read this post after the revert, will give it another try later.

petro · December 14, 2018, 12:56pm

So, it’s literally the first item on breaking changes…

Breaking Changes

State restoration will not work the first time you start 0.84. (@armills - #17270) (history docs)

m0wlheld · December 14, 2018, 1:08pm

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.

petro · December 14, 2018, 1:15pm

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.

thundergreen · December 14, 2018, 2:58pm

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

ha_steve · December 14, 2018, 3:09pm

So I assume there’s a typo in the change log… where it says:

This means that the Lovelace YAML config is now parsed with YAML 1.1 instead of YAML 1.2

That should be the other way around, no?

m0wlheld · December 14, 2018, 3:27pm

@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.

petro · December 14, 2018, 3:28pm

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.

petro · December 14, 2018, 3:31pm

Salty aren’t we? If you want changes, submit and issue or request a feature. Complaining doesn’t help anyone.

thundergreen · December 14, 2018, 3:31pm

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 .

mnbrgr · December 23, 2018, 3:47pm

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!