In one of the previous versions state restore was introduced.
I still used a AppDeamon for this with an app called switch_reset.
I’m now migrating to Hass.io and was wondering if I still need the AppDeamon app. Can anyone confirm that
state restore within HASS works correctly? I see very little posts on it.
state restoration appears to have only been added for input_booleans and input_selects and i’ve never seen it work for my input_booleans. So i guess the question is, what are you using it for switch_reset for? The switch_reset link you provided doesn’t contain the code, so I can only guess what it does.
This is a better link. will read and track the state of all input_boolean, input_slider and input_select and restore them when HomeAssistant restarts.
I have found that the HA state restore only works if the input_booleans are changed within the purge days set for the database. If you have something set long_term, then it returns to the off state on restart.
So I’ve gone back to using the Appdaemon app.
with appdeamon, do you write the state to disk?
The appdaemon app creates a small database that is written to disk.
Got a link to this app? Is it the one that OP linked?
Its the switch_reset app that is posted above.
Does AppDaemon store the ‘status’ of other items as well?
I’m currently working on integrating my sprinkler system and need to know when it last ran - and I would like to have this info available even after a reboot where the normal ‘last triggered’ attribute of an automation shows ‘null’.
At the moment I run a script to store the value in a json file:
curl -k -H POST http://192.168.7.16:8123/api/states/sensor.sprinkler_last_runval > /home/homeassistant/.homeassistant/files/last_sprinkler_runtime.json
I retrieve it it through a file-sensor and work with it from there.
Does anybody know if there is an easier way?
BTW:
I do the same with the precipitation values for the last 7 days so any easier ways would be appreciated
It can do, but I expect you would have to modify the app to do so.
Or maybe create a specific app for your use, as it could do the equivalent of curl, rather than running a separate script.
I’m not good with Python at all.
So if I have to go and store the value in a separate json-file anyway i might as well do it in yaml.
I made a version of the example appdaemon app that saved the state of my alarm_control_panel entity. It was actually not that hard!!
I run most of my sensors / swtichs on one HA to another HA through state stream / mqtt and as a result all states are retained by the mqtt server.
Hi @RobDYI - would an mqtt server save not just the state but also the attributes of the last state change, i.e. not just that an automation was on or off, but also when it was run the last time?
yes, state stream can be configured to save attributes
publish_attributes (Optional): Publish attributes of the entity as well as the state. Default is false.
Thanks for that.
Need to decide if it’s worth the effort to set up a 2nd PI and familiarize myself with MQTT - which is something I tried to avoid so far 
I guess it wouldn’t help me with the second part of my automation because I need a script to cycle through the precipitation values for the last 7 days anyway, i.e. Day1->Day2->Day3->…, by renaming files.
Another post pointed me towards the Input Datetime option:
This retains the stored value even through a reboot - so, I’m ditching the script that stores the value in a json-file am moving forward with ‘Input Datetime’ now.
I don’t think you need to setup two pi’s, its just what I have setup. If your pi sends all its states to mqtt, then that same pi and look up the retain states from the mqtt server when it restarts. The hassle I think is setting up a second mqtt sensors for each sensor you need states retained for. (this actually might be a nice feature request, a initial mqtt state topic as a configuration parameter)