Ruuvitags in HA more and more unstable with time

I have running on RPi3 and I have always updated to newest releases. I have integrated Ruuvitags (3 pcs from 9/2019, 3 pcs from 11/2019) with GitHub - akx/hass-ruuvitag: addon for Ruuvitag Weather Stations addon (version 0.2.0).

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 In addon log I have e.g.:

noble warning: unknown handle 1196 disconnected!
noble warning: unknown handle 1205 disconnected!
noble warning: unknown handle 1191 disconnected!

but have also got Bad gateway 502 notifications.

Also, the readings have started getting more and more spikes in them.

Do you have any idea why this is happening and what might help?

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.

1 Like

Thanks for the reply.

I’m using the built-in BT of the Pi.

Yep, I found the link already (however, thanks!), but I’m not sure am I able to do any command-line stuff under (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 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.

OK - the problem seems to be solved (I’ve got flawless data - no interruptions, no spikes - for nearly 24 hours now) with these steps:

  • Buying the cheapest USB BT dongle
  • I was lucky to notice that it worked out of the box
  • Disabled RPi3 BT (SD card to Win10 machine, add ‘dtoverlay=pi3-disable-bt’ to the end of ‘/boot/config.txt’)
  • Now the dongle is the default BT and everything works as expected (so far)

Interesting. Another case that seems to confirm my thoughts about the RPi3 bluetooth hardware (that it’s not just a software issue)…

May I ask which dongle you got? It would also be nice if you could follow up after maybe a week or so whether this truly fixed your issues.

1 Like

I got:

Yes, of course I can provide follow-up. Send a reminder here, if you don’t hear anything from me. BTW, I have Raspberry Pi 3 Model B Rev 1.2.

1 Like

Boom - the workaround still works like a charm. 100% errorless data for past week.


Thanks for update.
Just want to confirm that i also have bluetooth stability problem with Pi 3 Model B Rev 1.2.

1 Like

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.

1 Like

Ok, good know. Mine seems to be:
Hardware : BCM2835
Revision : a22082
Model : Raspberry Pi 3 Model B Rev 1.2

1 Like

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.


Good to hear!

1 Like

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

Good to hear about your success!

1 Like

it seemed that almost every other reboot ended up in the collector or BLE scan not working afterwards.

how to resolve it. .