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