Error in switch_reset on HASS restart

[ReneTode]

its a warning that somehow a file isnt reachable.
this could be caused by the fact that you are using python 3.6 and maybe the lib(shelve) that is used isnt right for that python version.
it doesnt mean that AD is not alive just that 1 specific app(switch_reset) has a problem.

[liquidox]

Hmm but ‘shelve’ is like a really basic library, I tried installing shelve2, same issue.

So not sure what else to try, I would expect more people to have this issue though, am just using latest Python with an unmodified AppDaemon example.

For now I have made an App that restarts AppDaemon whenever HA restarts.

[ReneTode]

i have no idea why shelve is having a problem.
but the error is saying that shelve is having a problem because the resource is unavailable.

self.device_db = shelve.open(self.args["file"])

just a thought: is the file you try to use a file that HA also uses?
if so then could it be that HA is blocking access during startup?

[liquidox]

Nope, it’s only for AppDaemon. Quite odd really.

[ReneTode]

suddenly it hit me:

what could be the problem is that when HA is restarted you get a new init.
shelve has the db already opened.

i think you could solve the problem by creating a terminate function that closes the db.
or you could add a check if the db is already opened before the open command is executed.

[liquidox]

Ah great point. But

if hasattr(self, 'device_db') == False:
  self.device_db = shelve.open(self.args["file"])

does not work, it always returns False.

I can’t close the shelve on close due to:

Listen_event for "homeassistant_stop"

You can attempt to listen for the HASS event but it may well not get picked up by AD because it is busy shutting down and reconnecting things. AppDaemon does have an event for HASS starting which you can use to imply that home assistant has shutdown and later restarted …

So I am out of ideas again.

[ReneTode]

you dont need to close the db when hass stops.
it generates warnings but thats no problem.
you want the db to function when hass is restarted.

the terminate function runs in front of the init.
so if you close it in the terminate you shoulf get:

1. everything running correct
2. hass is stopped, warnings are generated
3. hass restarts
4. ad starts again and executes the terminate warnings stop
5. ad starts the init and everything is running correct.

[liquidox]

Ahh had not found terminate. Seems to work so far, thanks!

  def terminate(self):
    self.device_db.close()

[gpbenton (Graham)]

I stopped using this app last April when the functionality was moved in to HA. Is there some reason you are still using it?

[ReneTode]

i didnt even know they added it.
can you tell me in which update they added it?
and is it optional or automaticly?

[gpbenton (Graham)]

Looking at my git log, I deleted switch_reset.py on April 26th, so it was a release or two (or three) before then.

[liquidox]

Seems the trick would be removing the “initial” tag from input_booleans:

Ability for input_boolean, input_select and input_slider to retain values over a restart

Hi there, sorry to revive an old thread, but haven’t find if today there is a well defined way to keep the status of inputs between restarts, or we still have to resort to custom components like @Danielhiversen I’d like to keep the state of automations (active/not active) as they are between restarts. Looking at other recent threads it seems I’m not the only one confused:

Seems it was added around March:

Restore_state helper to restore entity states from the DB on startup

I also had the idea this was implemented but it never worked for me, this explains why…

[ReneTode]

as i see it it was 0.39 and i run 0.40
but i remember now that it didnt work for me either.
i had the same problem with that as with the app, it did set the states after starting, triggering all kind of things on restart.

and i cant use it now anyway because i kicked out the recorder long ago.

[liquidox]

What helped me a lot to prevent those issues is this automation:

alias: 'Delay automations on restart'
hide_entity: true
trigger:
   - platform: homeassistant
     event: start
action:
  - service: automation.turn_off
    data:
      entity_id:
        - group.all_automations
  - delay:
      seconds: 120
  - service: automation.turn_on
    data:
      entity_id:
        - group.all_automations

[ReneTode]

my biggest problem is that i have mostly “dumb” devices.
TV’s for instance are switched on and off with the same command.

if i have turned on the TV the state in hass is “on”
after a restart hass turn the switch to on and that causes the TV to turn off.

those kind of things are only to be prevented if HA changes the state BEFORE it is active.
so the saved state must be first state to avoid state_change.
as soon as a state is set i can only supress the action by registring that its a first change, and that can be done in AD.

[Tyfoon]

@liquidox is there a way you can post your full switch_reset app here? I seem to have the same problem but I have no idea/experience in writing/editing the apps myself, I just steal with pride. So just re-using your app would be great!

@ReneTode; this seems to be the sam issue we where discussing here

[rb666]

Oh I don’t actually use switch_reset anymore, I do use the (related) persistence package:

dale3h/homeassistant-config/blob/master/packages/drop-in/persistence.yaml

And some of my Appdaemon apps control their own initial state upon reloads.

[Tyfoon]

Thanks. This made me search again on all the options. It seems this is now default behavior of HASS. https://www.home-assistant.io/components/recorder/#restore-state

This works great as long as you do not (!) use an initial state.

[gpbenton (Graham)]

The problem using the HA behaviour is that it doesn’t survive the database purge. Anything that doesn’t change for the length of the database purge time will not be restored, and you get a random value.

[Tyfoon]

Ouch! What is your preferred method?