With time (past weeks, couple of months), Ruuvitag readings have become more and more unstable - they lose connection once or twice a day (meaning last reading at some time point and no new readings after that). Cure for this is usually restarting the addon or rebooting hass.io. In addon log I have e.g.:
Are you using the builtin bluetooth adapter on the RPi3 or an external dongle? After years of use, experience and experimenting I’m starting to think the RPi3 (possibly others than 3 too) is really picky/unstable with bluetooth, with many different causes, but there are at least a couple of things you can check/try.
One cause for spikes is a FIFO overflow, as noticed here with a workaround that reduces the spikes. (hardware design issue on some revisions in which case workaround is probably the best you can get)
I have also noticed and heard cases where the RPi3 bluetooth is increasingly unstable when the power supply input voltage differs from 5V; my main RPi3 is using a high quality 5V power supply which supplies very precise voltage and it rarely has issues (apart from the spikes in data which started after upgrading to a newer raspbian, fixed with the above link) while my testing RPi3 uses a old phone charger which supplies around 5.1-5.2V measured with a multimeter under no load (still within specs though) and the bluetooth hangs there from time to time. It’s not a hardware defect on that particular RPi3; I have swapped the raspberries around and it didn’t make any difference.
Yep, I found the link already (however, thanks!), but I’m not sure am I able to do any command-line stuff under hass.io (or at least it is quite restricted) - need to give a try! BTW has anyone tried to find out why spikes are related to newest HA releases? What has changed? Have you any experience with a separate BT dongle?
OK, I need to check the PS. It should be more or less official one, but actually on the PS end the USB connector is bit loose. Also, it is connected to an extension cord with many other devices connected.
Just upgrading my Raspbian introduced spikes in my data, so it’s surely some weird combination of things, so it might even not have anything to do with HA itself, but hard to say.
A bit limited, it’s hard to test these things as it requires time but so far it seems they are more stable. Although the voltage to the RPi usb ports is not regulated, a bad input voltage to the RPi will directly flow through to connected devices, so some adapters might or might not have issues on a RPi if the power supply is not optimal.
Somehow I feel that RPi3 BT is getting worse and worse day by day. Now I get Ruuvi readings only for an hour or two, sometimes a bit longer. Using ‘dmesg’ I see that I get lots of lines:
“Bluetooth: hci0: Frame reassembly failed (-84)”,
also some “Bluetooth: hci0: SCO packet for unknown connection handle XYZ”
and finally “Bluetooth: hci0: hardware error 0x35”, after which BT doesn’t recover without rebooting the system.
In add-on’s own log I have those “noble warning: unknown handle 1191 disconnected!” lines.
All over the Internet I see that this seems to be some kind of kernel problem (which I hope would get fixed). Has anyone else experienced this behaviour?
BTW, I get also the FIFO overflow spikes, but I’m not able to use the workaround (in Hass.io there is no btuart file…? - Is it defined somewhere else?). Are these two issues perhaps connected somehow? This is bit frustrating, since for months Ruuvitags were working fine in HA with RPI3.
Edit: I’ve also re-located the RPI3 to another room (where it originally worked fine) and also tried with two other RPi-dedicated power supplies, so these should not be the origin of the problem.
Funny thing is that in my case, removing the daily reboot routine has made things work better… the last time the RPi stopped collecting data was December 30th, over a week ago. Before that, it seemed that almost every other reboot ended up in the collector or BLE scan not working afterwards.
I have two Raspberry Pi 3B rev 1.2 boards, from different manufacturers, a02082 made by Sony UK and a52082 made by Stadium. Both have the same exact issues with bluetooth.
IIRC finding seller who had RPi 3B rev 1.3 boards, made by Embest, was and is nigh impossible, at least with my googling skills, excluding the Embest website.
Link to RPi revision codes.