Error in switch_reset on HASS restart

I keep seeing this error when restarting HASS without restarting AppDaemon. If I restart Appdaemon, then the error is gone, but I assume AppDaemon should be able to remain alive through HASS restarts?

2017-12-03 05:13:34.624849 WARNING ------------------------------------------------------------
2017-12-03 05:21:11.003675 WARNING ------------------------------------------------------------
2017-12-03 05:21:11.003771 WARNING Unexpected error during loading of Switch Reset:
2017-12-03 05:21:11.003841 WARNING ------------------------------------------------------------
2017-12-03 05:21:11.004192 WARNING Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 912, in read_app
    init_object(name, class_name, module_name, conf.app_config[name])
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 583, in init_object
    conf.objects[name]["object"].initialize()
  File "/home/redbull/hass/appdaemon/apps/switch_reset.py", line 22, in initialize
    self.device_db = shelve.open(self.args["file"])
  File "/usr/lib/python3.6/shelve.py", line 243, in open
    return DbfilenameShelf(filename, flag, protocol, writeback)
  File "/usr/lib/python3.6/shelve.py", line 227, in __init__
    Shelf.__init__(self, dbm.open(filename, flag), protocol, writeback)
  File "/usr/lib/python3.6/dbm/__init__.py", line 94, in open
    return mod.open(file, flag, mode)
_gdbm.error: [Errno 11] Resource temporarily unavailable

2017-12-03 05:21:11.004340 WARNING ------------------------------------------------------------

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.

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.

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?

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

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.

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:

So I am out of ideas again.

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.

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

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

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

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

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

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

Seems it was added around March:

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

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.

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

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.

@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

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

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

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.

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.