Page 1 of 2
API Key Changes on Reset

Posted:
Wed Sep 27, 2017 9:26 pm
by smurfgun
Hi,
My RPI0 w/ AlarmDecoder has been periodically dying. I don't really know why it dies and requires a reset but hopefully will find out one day. But before I get into that, my API Key -may- change on a reset. It doesn't always change buy it may... Any ideas why the API key changes on reset? Without fixing the freeze/crash issue, it would be good if my API key isn't changing.
Thanks!
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:23 am
by kevin
Please define reset? As in reboot? Or reflash of SD Card?
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:26 am
by smurfgun
Specifically what happens is I would notice that my smartthings (what I am using) is no longer updating the alarm state and I can no longer control it from smartthings. I proceed to try and ping my rpi0 but the ping fails and I no longer see an IP address assigned to rpi0 in my router device list. To recover from this, I power cycle the rpi0 (unplug and plug back in). Once rpi0 is back up, the whole system can be working. However, sometimes the API key changes on power up. As a result, I need to go update the API key in smartthings.
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:33 am
by kevin
That's really strange, unless your database is getting corrupted somehow that shouldn't happen.
The SmartThings Notification retrieves the key and url from the database that was set during creation of the SmartThings notification type.
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:37 am
by smurfgun
So, I'm not talking about the API Endpoint / Token generated from ST that we input into alarmdecoder....
I am talking about the REST API Key that is generated by alarmdecoder and that I would input into ST. It is that key that keeps changing on the alarmdecoder side.
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:42 am
by kevin
Again that field is set and retrieved from the database when enabling API for that user
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:45 am
by smurfgun
I see... One thing I noticed is that it switches between 2 keys. I didn't write the whole key down to make sure... But I think when it comes out of reset, it comes up with 1 of 2 keys...
Maybe the database has a couple entries and it is randomly picking one out...
Instructions on how to manually search the database? Maybe upon searching, I'll see a couple entries and I can delete one.
Thanks!
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 8:46 am
by kevin
It's just a sqlite file, you can use sqlitebrowser on it
It is in /opt/alarmdecoder-webapp/instance/db.sqlite
table name is 'apikeys'
Suggest using the built-in 'export' of webapp to save your settings just in case.
Re: API Key Changes on Reset

Posted:
Thu Sep 28, 2017 10:33 pm
by smurfgun
Thanks Kevin.
There seems to be TWO db.sqlite in my system. Each have their own key and those were the keys I was switching between. Any ideas how I ended up with the two instances? Here are were my db.sqlite files are... The first two seem to contain the two api keys.
./var/lib/docker/volumes/a4e01061b761944d5fe2b5c20129527f1c9930188dd8be60d503535cd2b13750/_data/alarmdecoder-webapp/instance/db.sqlite
./var/lib/docker/volumes/795c74732d6de23f839ccda916b4bd087c41b1801dc7156aa6a169658999d237/_data/alarmdecoder-webapp/instance/db.sqlite
./var/lib/docker/overlay2/222e2b5488b4dbb7bd9ce004341de44a1db8d8d645da60e9a65eb8e9cc4f170a/merged/opt/alarmdecoder-webapp/instance/db.sqlite
./var/lib/docker/overlay2/52f551b68d7de2a12e3e3d1275c4a1669fd1d06421b03338af7702b43071ee6e/merged/opt/alarmdecoder-webapp/instance/db.sqlite
./var/lib/docker/overlay2/c867b77761d0afcbf4a9edf8ff0d13da440659b503bbf9edb82490f2756e7035/diff/opt/alarmdecoder-webapp/instance/db.sqlite
./var/lib/docker/overlay2/d5d9443edb92089bc3895dbdee4afa5ed4d245cea749745fb37ae80aa1f42c88/diff/opt/alarmdecoder-webapp/instance/db.sqlite
Re: API Key Changes on Reset

Posted:
Fri Sep 29, 2017 8:56 am
by kevin
Not sure, have not seen this issue before. I would point to something with docker volumes perhaps being the culprit, but I have not run into this issue myself