Strange. I tested it just now on iOS 13.3.1 and it works.
- (void)button:(FLICButton *)button didDisconnectWithError:(NSError *)error;
And you are sure that the delegates are set properly and that you are not accidentally calling on a nil-object or something?
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.
@Emil hmm, how do I do that?
Take Notifications as an example. I add the “Get notification when a Flic is pushed” in IFTTT, set the button by name and Click Type.
What do I do in Flic then? If I add IFTTT to the button, all I can set in the app is Tags, how do they work?
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.
Other than that, it should work fine.
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.
But please correct me if I'm wrong.