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.
Thanks for sharing this! I had the same issue on my Pi 3B, and today I got the same BT USB dongle. Data is now flawless and the signal strengths received from Ruuvitag improved a lot.
Thank you so much! I have been reading raspberryās PRs for more than an hour to understand why I am getting a Tx timeout, while in the end it was a conflict between Piās BT module and the Raspbee IIās