Flic client disconnecting

[Roaders]

Hi All

I have an issue that's been annoying me (and more importantly my wife) for the last few weeks.

I have a bunch of flics connected to 2 Raspberry Pis. I have livingRoomPi and bedroomPi. NodeRed runs on livingroomPi and connects to Daemons running on livingRoomPi and bedroomPi. Both Daemons are started the same way using the boot script with logging ect.

All flics paired with the livingroomPi seem fine.

Buttons connected to the bedroomPi sometimes stop working.

When pressed the button glows red and nothing happens. When looking at the node-red dashboard it still seems to be connected to the daemon running on bedroom Pi.

if I log into bedroomPi and run the example node client, when I press a button I see it in the console. However as soon as I press this first button nodeRed starts to get events as well. It gets the "new" button press as well as previous, missed button presses. I assume these are the events that did not get through before and are queued. The result is that lights come on then go off and all sorts of odd stuff happens... I also see these queued events in the example client log output.

Any idea what is going on here? It seems as though the daemon on bedroomPi forgets that livingroomPi is connected to it and stops sending events until another client is connected to it then it sends events to all clients.

[pfink]

For me it sounds like the range of the Bluetooth adapter of bedroomPi is not strong enough. Does the issue still occur if you try to push the button directly next to the adapter? Did you try another BT adapter?

[Roaders]

No, the range is fine. If the range was the problem the example app wouldn't work either. This is a Pi 3 so this is the bluetooth adaptor on the Pi.

[Emill]

Is it the same problem for all the bedroomPi buttons or just some of them? I.e. are all disconnected?

[Roaders]

Yes, all of them are inactive.

[Emill]

Is it possible that the tcp connection closes for some reason? Do you run it over wifi? Could you run a wireshark to capture the issue?

[Roaders]

I can still ssh into the box so I doubt it. Also the button remains unresponsive after connecting until I start the exampleClient.

[Emill]

Could you try this flicd? https://drive.google.com/file/d/0B-kW5rSvtUYnaTBUTzd1Vm1pUW8/view?usp=sharing

[Emill]

Have you had the chance to test that new flicd yet?

[Roaders]

I've only just had a chance to install it. Since I opened this issue I've not had the problem again. I'll report back if it happens again. What is different about that flicd?

[Emill]

I found a problem that if multiple commands are sent at once, the flicd may sometimes only process the first. As soon as something "happens", i.e. some TCP or HCI packet arrives, it wakes up again.

[Roaders]

This happened again tonight with the new flicd.

[Emill]

Hmm... Could you possibly run Wireshark or tshark to capture the network traffic? What you observe seems so strange. Send the .pcap or .pcapng file when you have observed it again, and you have started an additional client to magically solve the problem.

[Roaders]

so what network traffic are you interested in? The traffic between the 2 raspberry pis? I've not get any experience running these sort of tools. Would I have to run them on the pi or any machine?

[joachimpr]

Has this issue ever been resolved? Just curious? I see the last post was in 2017. Im currently working on a flic installation and I'm gathering as much info as I can on potential issue I may run into.

[ristomatti]

@joachimpr, one stability tip I can give after over than a year using this is that it works pretty solid when run on Raspberry Pi. I ran it for a year on an Odroid C2 using the recommended Bluetooth dongle but for some reason the Bluetooth stack got stuck in a way I had to actually reboot the machine to fix it. I had the bluetoothd daemon disabled etc.

When I moved flicd to a RPi3 the problem disappeared even though I used the same dongle. I haven't used it with the onboard Bluetooth chip though as I have a Z-wave addon on the Raspberry which uses the same IO pins as the Bluetooth.

I haven't had any issue with client disconnecting even while the client is now accessing the service over the network. I have been using a 3rd party Node-RED adding as the flic client.

The biggest problems I've experienced are batteries running out from the flic buttons all the time (every 3 months or so) but I have a feeling the battery consumption has reduced after moving the daemon to run in the Raspberry Pi. This is probably my imagination though as how I understand Bluetooth LE is that the Bluetooth on the server basically just listens for button presses and does not poll the buttons for any data meanwhile. @50ButtonsEach please correct me if I'm wrong.

[joachimpr]

@ristomatti, I also deployed this to a raspberry pi 3 this week and it is now running as a daemon. So far it has been stable using the on board Bluetooth adapter. Granted it is only one switch for the time being and it has only been 2 days but stability is already better than it was when I was running it without the daemon.

While running without a daemon, it would run for around an hour and then crash. I then have to rerun flicd, it lasts for about an hour, crash. The daemon has been running for 2 days straight with no issues.

One thing I have noticed is that it sometimes does not start up gracefully. I am using home assistant as a client and accessing flicd over the network as the Bluetooth adapter on my home assistant rpi3 is otherwise engaged (Bluetooth tracker). I was forced to move flicd to my file server where the Bluetooth is not being used. Sometimes everything starts up at the same time, I am forced to restart the home assistant service before flicd accepts it as a client. I don't know if home assistant only tries to connect to flicd on initial startup and never again, or what the story is. but after restarting home assistant, I can then see Client accepted message in flicd log. From there on out, it runs stable (for now, and for two days counting :-) )

I guess only time will tell what the batteries will do. Anyway, they work great!! Solved my problem for not being able to use a wifi light switch due to my wiring not being able to support it. Also, I have a 3 gang switch, and a 4 gang switch which requires replacing. You cannot find these gangs in wifi type switches, the biggest I have seen is 2 gang. With the flic buttons, and their click, double click, hold states, I can replace a 3 gang switch with one flic button, and a 4 gang switch with 2 flic buttons and have a couple of states spare for some other automation. Albeit they are quite expensive, they are a godsend! It would be really cool if you could build these buttons into a light switch form factor as well, already mounted into a mounting plate which you can just screw to your wall. There would be many use cases for this. I for one have to now figure out how I am going to mount these buttons to my wall to replace my current switches. I will test it with a blanking plate and the suction cups to see how that goes. Thanks @50ButtonsEach!

[k-tod]

I'm using this the flicd together with the python test client on Ubuntu 18.04 LTS with the built-in bluetooth on a DELL XPS-13 9350. In my case it is continuously connecting and disconnecting, making it unreliable, I can never be sure if the press has been detected or not. Additionally I noticed that the commands are buffered, so if I press the button several times while it's trying to connect the Down/Up presses will be shown later altogether. Any ideas ?

ConnectionStatus.Disconnected DisconnectReason.TimedOut ConnectionStatus.Connected ConnectionStatus.Disconnected DisconnectReason.TimedOut ConnectionStatus.Connected ConnectionStatus.Disconnected DisconnectReason.TimedOut ConnectionStatus.Disconnected DisconnectReason.ConnectionEstablis

ConnectionStatus.Connected ConnectionStatus.Ready ClickType.ButtonDown ClickType.ButtonUp ClickType.ButtonDown ClickType.ButtonUp ConnectionStatus.Disconnected DisconnectReason.TimedOut ConnectionStatus.Connected ConnectionStatus.Disconnected DisconnectReason.TimedOut ConnectionStatus.Connected ConnectionStatus.Disconnected DisconnectReason.ConnectionEstablis

[Emill]

@k-tod this is kind of expected. Wireless communication is not prefect. Anyway, if the button is disconnected and you press it, it will advertise with a short advertising interval so it should connect again immediately. If you don't like the buffered events, you can identify them by the IsQueued and TimeDiff parameters and ignore if you'd like.

[k-tod]

@Emill : thank you very much for the useful information, the thing is that the button is at less than a meter from the laptop, and the disconnects happened in matters of seconds, that is why I assumed this has something to do with the library or some other piece of software. However, I later noticed that if I put the button on the right side of the laptop, very close to it, then I have less disconnects, I only used the buttons a couple of times since I got them last month, but I did not replace the stock battery so I'm thinking now that maybe the battery is weak(who knows how long the button stayed on the shelf before I bought it...), I will replace the battery tomorrow and update the comments with the outcome.