I have figured it out. When I started flicd through /etc/rc.local it was running as root with no environmental variables, and the data of the buttons was stored in the root directory. When I ran the exact same command as user pi, the environmental variables were set, PATH, USER etc. The fix was simple: use full path names for the data base file.
My apologies for wasting your time when the error was mine.
@Emil Our client is sending 4 buttons to a tender and with the issues that are happening on version 8 could we request the following buttons also be placed on version 7 for the mean time. They are
BA48 – A39996
BA48 – A54514
BA48 – A54466
BA48 - A51788
It would be greatly appreciated.
I think Web Bluetooth implementations kind of sucks at this stage because of the following reasons:
No good scan API.
No browsers implement the ability to abort a pending connection.
No possibility to "store" a device persistently and later re-connect upon next page reload.
Some platforms were very bad at either having multiple pending connections or pending connections that were long-outstanding.
Correct me if I'm wrong, but I seem to recall that if an app wish to communicate with another app using the x-callback-url scheme, then that app needs to be in the foreground in order to send the request? If so, then it would unfortunately defeat the purpose of a button.
Yes it's possible. If you actually get a status code such as 404 then it was the server that responded with the error code 404. Maybe you have the wrong url?