Restore state and automations only work if I don't restart from Hass.io-menu

I have put in a lot of time trying to figure out why states are only restored sometimes and why I sometimes need to refresh the automations after a restart to “activate them”. It is important for me since I use Hass.io as alarm and hence I need it to be activated after a (unplanned) restart.

Today I noticed that all states are restored correctly and all automations startup, but only if I restart from Configuration > General > Server management > Restart .

If I use the Hass-io > 3-dot menu > Restart Home Assistant, the states will not be saved/restored and my start-up automations will not work reliably (sometime they start, sometimes they don’t).

I have recreated the symptom ~10 times now.

It might be a bug, but before I report it it would be nice to hear if there is anyone else with the same experience?

And what differs between “Configuration > General > Server management > Restart” and “Hass-io > 3-dot menu > Restart Home Assistant”?

// Anders

1 Like

I also have issues where the state of input_number/input_boolean are not restored sometimes. I have not figured out why, but I use the three dotted Restart. I’ll experiment with using the Server management > Restart and see if it helps.

I’ve tested using the “Configuration > General > Server management > Restart” several times now and, unfortunately, lost input states every time.

That’s sad. I thought I was on to something.
Out of curiosity, do you use persistence package from dale3h? Or just the built in recorder:?

In parallell, I’m trying out a theory where I think I have to many features activated.
Today, I tried to activate everything again, discoery, router, a few ping sensors and so on.
And suddenly my states are forgotten - even when restarting from Server Management - menu.

The log gives me nothing on the issue so I guess I’ll just keep trying…

I use only the recorder. I wanted to try the persistence package if the problem still persisted after next version. Do you use it?

I tried the persistence package for a few days a couple of weeks ago, but I didn’t see any difference, it still forgot my states, so then I removed it to make the troubleshooting “not worse”.

I am facing the same, well slightly modified, issue. After either planned or unplanned HA restart automations are restored but switches are not restored.
If I restart Mosquitto broker afterwards all switches are restored as well.

:bulb: A little more of research solved my issue : MQTT : cmnd/topic/PowerRetain 1 :slightly_smiling_face:

Now all switches keeps their state after power failure, HA reboot etc., states are restored as well.

@gazoscalvertos has a function in his take on Alarm that writes the alarm state in a json-file. That seemed to work really good so I suggested he’d use that but make it more customizable. And like magic, he did. The result is

and it works just great.

No more restore state problems for me :slight_smile:

1 Like

does this work for automations also? Need eg the last_triggered state of an automation to be read by a python script after a reboot…
thx,
Marius

Well yes, but I assume you would need a input_boolean or use https://github.com/rogro82/hass-variables as a placeholder for the last value and use that value in your script.

That’s how I handle all my persistence values.
I have variables for Last used climate, last used light scene, and so on. And I set the variable from my scripts and automations.

Ok Thanks , will have a look for sure .

Could you please share some code snippets of your approach? Not yet familiar with a Boolean for this . And how to read/write the persistent variable with the last_triggered.

btw, for restoring input_booleans we wouldn’t need the extra script, according to the documentation they are provided for: https://www.home-assistant.io/components/recorder/#restore-state ?
Marius

Hi!

Here is a long answer to a short question:

I use input_boolean to choose if an automation should be active. Typically I want notifications if the lighting changes or if the outdoor lighting should be activated by timer or sunset.

  alias: 'Wake up!'
  trigger:
  - platform: time
    at: '06:30:00'
  condition:
  - condition: time
    weekday:
    - mon
    - tue
    - wed
    - thu
    - fri
  - condition: state
    entity_id: input_boolean.common_lights_schedule
    state: 'on'
  action:
  ...

I use input_selects for choosing states, typically for example “22 degrees inside” or “Relaxed lighting”.
But since I also want to change lighting from automations, scripts and manual switches - and I want the state to be saved, so whenever the input_select’s value changes, I save the chosen state in a variable and trigger the actual change from there.

For example (lighting):
A change in the value of a input_select.lights01 triggers an automation.
The automation sets a new value in the variable.light_state, then sets the input_select back to Välj (that’s Swedish for “Select” ).

alias: 'Light trigger'
trigger:
  platform: state
  entity_id: input_select.lights01
condition:
  condition: template
  value_template: "{{ states.input_select.lights01.state != 'Välj' }}"
action:
  - service: variable.set_variable
    data:
      variable: light_state
      value_template:  '{{ states("input_select.lights01") }}'
  - service: input_select.select_option
    data:
      entity_id: input_select.lights01
      option: 'Välj'
  - service: script.light_sequence

The change in variable.light_state triggers an automation that runs a script that checks the current state of variable.light_state:

light_sequence:
  sequence:
  - service: script.set_light_off
  - service: script.set_light_bright
  - service: script.set_light_wakeup
...

set_light_off:
  sequence:
  - condition: state
    entity_id: variable.light_state
    state: !secret light_off
  - service: script.light_off

set_light_bright:
  sequence:
  - condition: state
    entity_id: variable.light_state
    state: !secret light_bright
  - service: script.light_bright

...

…which triggers the script:

light_wakeup:
  alias: 'Wake up!'
  sequence:
  - service: script.tradfri_weekday
  - service: light.turn_on
    data:
      entity_id: group.lights_dim_grp
      transition: 1
      brightness_pct: 90
  - service: switch.turn_on
    data:
      entity_id: 
      - group.lights_switch_grp
      - group.lights_basement_grp
  - service: variable.set_variable
    data:
      variable: light_state
      value: !secret light_wakeup
  - service: notify.email
    data:
      title: 'Lighting changed'
      message: !secret light_wakeup

I use parameters like !secret light_off instead of the actual names not because the’re secret, but to make sure I don’t do any typos and to be able to change their values at one place.

Why this complex setup?

  1. To make sure persistence works. HASS-Persistence automatically restores the values of my variables. And I have a startup script for re-setting the lighting, alarm and climate.
    This script is the same script that the input_select triggers at change (see above) script.light_sequence.

  2. It’s very easy to set a new value to the variable.light_state from other scripts and automations. And with this setup, I don’t run into the problem where the input_select.lights01 would show incorrect value which could happen if I ran scripts that changed the lighting without changing the value of the input_select.lights01. The input_select.lights01 always shows “Select”. And it’s easy to show current status.


    Easy for the other family members to understand :slight_smile:

  3. I’m sure there are more elegant ways to accomplish this, but for me the structure makes it quite easy to have clean, short scripts and automations. It might seem complex, but I think it’s easy to follow and easy to duplicate for each purpose.

4 Likes

Ιs very interesting, but I can not understand it because i am newbie at HA !!
Can you give me a clear sample for one automation with lights and input_selects step by step ?

Thanks