Seeking input on dialing in RSSI/distances in bluetoothLowEnergy (BLE) RA setup

[jdiegmueller]

I'm curious if anyone has any real-world input on stabilizing BLE beacon detection in a scenario with multiple Pis distributed around the house:

At the moment I have 6 Pi 3s and 4s distributed throughout my home. I'm using the bluetoothLowEnergy integration in order to detect a small handful of Radbeacon Dots. I started with room-assistant 2.12.0, although at the moment I'm running 2.13.0-beta3 based on various chatter I've seen here on github.

After a few days of tinkering, I feel I have gotten myself to having a decent understanding of room-assistant. I've got the various room-assistant instances clustered up, and I have a high weight on the Pi [I believe to be] best suited to be the leader (wired connectivity as opposed to wireless). That said, I cannot get room-assistant to reliably report what room the Radbeacon Dots are in (or alternately, for that report to stick as RA seems to think the Dot is moving between rooms even when it is completely idle).

At the moment I'm fighting with two behaviors:

• RA tends to report the Radbeacon Dot being in the wrong room, or
• RA has the Radbeacon Dot jumping between rooms

At first I experimented with the various RA settings (timeout, rollingAverage, debounce, measuredPower) to try and get things stable, but have had no luck with any combination of these parameters. So that led me to start digging in to the fantastic JSON API that RA provides.

Using the JSON data, I can see that the RSSIs that each RA instance observes seems to be the heart of my problem. For example, right now I have a Radbeacon Dot sitting on my kitchen table right next to me. My "1fkitchen" Pi/RA instance sits roughly 7 feet behind me and reports a fairly stable -64 to -66 RSSI. The Dot has a measuredPower of -60 configured on it (which RA helpfully honors), so RA works this out to a 1.9-2.1 meter distance which is pretty accurate. However, reported RSSI from my "0foffice" instance -- which is roughly 10 feet below me, in my finished basement office, through a floor -- seems to range from -48 to -53, which RA works out to be a 0.2-0.4 meter distance. Because that distance is lowest, RA reports that is the room the Dot is in.

If I shut down the "0foffice" instance, the Dot will start flapping between my "1fkitchen" and "1fgreatroom" instances. The "1fgreatroom" Pi/RA instance is roughly 15-20 feet away from the Dot front of me (although no walls, so the yes Dot has line of sight to it). The flapping behavior makes sense, because once again I can use the JSON API to observe the RSSI of the two instances. Both report RSSIs that are very, very close to one another -- "1fgreat room" RSSI seems to vary between -61 and -68 (1.3-1.9 meters) away. Because that calculate distance is (sometimes) lower than the calculated "1fkitchen" distance, RA sometimes thinks the Dot is in "1fgreatroom" as opposed to "1fkitchen".

In conclusion, it seems that RA is doing the right thing based on what it sees, and that my problems are all related to the RF side of BLE.

With that in mind, does anyone have any suggestions on how to dial in the RSSI that each Pi/RA instance sees? Where should I physically locate the Pis within the rooms? Up high in the corners of rooms? Down low in the middle of rooms? Should I stick them in some sort of Faraday cage-like containers with openings facing the room to monitor (and if yes, could you point me to something along those lines on Amazon or whatnot)? Should I (continue to) monkey around with measuredPower on each instance? Should I standardize on a single type of Pi (I have 6 Pi Zero Ws arriving today) to minimize hardware differences between them? Is there a particular transmit strength on the Dots I should use (I've tried everything from the default of -3 to the lowest possible of -18)?

I'm very open to discussion and suggestions on the best way to get the Pis RSSI to mirror (relative to one another) the real-world location of the beacons. I don't necessarily care about the reported distance (although I guess I can influence that figure with measuredPower) as much as I care about accurate room reports. Also worth noting, I do not care about "fast" room reports as much as "accurate" room reports.

Thank you for any/all input or discussion.

[jdiegmueller]

Also worth mentioning:

I have a ton more Pi 3 and 4s available to me from an old project, so throwing Pi hardware at the problem is no obstacle in my specific case. For example, I'd certainly be willing to deploy multiple Pis in different corners of each room or whatnot if that would help get more accurate RSSIs per room. Having said that, though, my [current] understanding of RA is that each instance is standlone and that the reported RSSIs per instance "are what they are".

Is my understanding correct -- ie, that there's no way to have multiple RA instances in a single room, and have them coopoerate by averaging RSSIs or something along those lines?

[tehbra1n]

I've been digging into this too using iBeacons. So far the best results seem to come from using the measuredPower option in the config for each tag as well as the rollingAverage and debounce entity config.

I measured the RSSI from my tag using a BLE app on my phone and placing it 1m away from the tag. It was about -67 so I set that as the measuredPower for the tags. Right now I'm experimenting with different values for the window in rollingAverage and the wait time in debounce. I have them set to 300 and 5 respectively.

I'd love to know if there are any other ideas. I think a feature request to have the Pis do some triangulation when you have several seeing the iBeacons was made but I'm sure its not a trivial implementation.

[jdiegmueller]

Ok, so that's the path I've been headed down as well. Some additional thoughts: My Radbeacon Dot beacons do happen to advertise measuredPower (which RA honors), which the Radbeacon app helps you properly set by placing the beacon 1 meter away from your cell phone and measuring RSSI. That said, I feel as if I've hit a roadblock since in certain locations of the house the "wrong sensor" sees a stronger RSSI. No amount of rollingAverage or debounce tweaks is going to change that fact. Moving sensors around typically just moves the locations that are problematic for me. Tweaking measuredPower with manual overrides on certain sensors helps with the "wrong" sensor detecting location, but then changes the problem to be the tweaked sensor doesn't think you're in that room unless you're right up against the sensor. I guess given the way my house is built and the fact it appears to let 2.4GHz pass through the walls without too much trouble, I don't think room-assistant is going to work for me without the ability to tri-lateration or some sort of handling multiple sensors in a single room (perhaps by blending the multiple sensors' RSSIs or whatnot). I burned way too many hours on this last week. :) I'll probably revisit this in a few more.