Yes, the Failed to find scanner hci.... in Device Registry
errors are a bug I introduced when refactoring the scanner set-up. I’ll have a fix soon in the next rc / release.
The esphome integration already has a “watchdog” system in place so that it can request proxies to restart if they stop sending advertisements. The main idea of these particular sensors is to give you a good idea of whether all your proxies are working, and to help identify if some are not sending updates as often as they should - this is often indicative of bad firmware settings, but causes may vary.
There is a feature request open currently to provide more detailed diagnostic entities that will be a lot easier to interpret, and can give deeper insights into the troubleshooting process. Some will be on the global device, others on the individual scanner’s device pages. This will also allow for setting up automations/alerts if anything goes awry, and also allowing historical analysis to identify trends etc.
Some initial thoughts on what the sensors will measure and what those things mean are at FR: Add Diagnostic Entities on Scanners · Issue #363 · agittins/bermuda · GitHub
Yes, your diags look good as far as proxy health goes - your intervals are typically around 1s or so most of the time. Your distances however are pretty large, and looking at your phone in the kitchen over the last 10 seconds of that diags, the distance bounces from 5m to 21m, which is fairly variable.
How close do you think your phone was likely to have been to the kitchen proxy at that time? If the calibration is way off, it might be worth sorting that out - it usually doesn’t matter much, but having it dialled in will help the max_velocity
function do it’s job properly (it matters because the velocity filter works in metres/second which is a linear measurement, while rssi is a logarithmic measurement - so if our conversion is off then these absolute comparisons don’t work as well).
Some steps to get more data and make improvements:
- concentrate on just one device for now, such as your iPhone
- in Bermuda’s device page for your iPhone, enable the
distance to...
sensors for a few of the proxies - maybe choose the ones that give you the most trouble (Kitchen, Study, Bath?)
- Go through the calibration process:
- Do the Global Calibration:
- put your phone 1m away from one of the proxies, and adjust
ref_power
until you get a fairly reliable 1m measurement from it. It’s important you start with 1m, not 1.5 etc.
- Move your phone to say 5m or 10m (basically the furthest you can get with a wide free space between proxy and phone), and adjust only the attenuation until the measurement reads the actual distance that your phone is at.
- You can probably stop there, but you might want to do a quick test and see that all the other proxies also read about 1m when your phone is 1m from them. If they vary substantially, adjust the per-proxy offset for each of them until they’re about right.
Now that you’re calibrated, leave the phone in a typical “in the kitchen” place for a few minutes, then go into the History page in HA. Choose + Choose Device
and select your phone - that way you’ll get all the various sensors from your phone on one page of history graphs - like previously but with more data! Sexy. In the time/date range selector, set it to only display the last 10 minutes or so - as long as you can clearly see each update taking affect. You can turn off the “Estimated Distance” sensor from Private BLE Device, and turn off the “Distance” sensor as well, since it will just be overlaying on of the “Distance to…” sensor’s values. Grab a screenshot, and we’ll take a look at it.
If your distances are still all over the place, we can then experiment with the max_velocity
setting to filter out the weaker signals, and the smoothing_samples
to alter the upward slopes on the smoothed distance sensors to avoid crossing the streams so much But grab that screenshot first to ensure we have a good baseline to start with.
As far as positioning the proxies, what you really want for your typical loitering locations (kitchen bench, couch etc) is that the closest proxy is much closer than the next closest proxy. If one is 3m away under the TV, and the other is 3.5m away on the other side of that wall, well… it’ll be rubbish. But move the TV proxy so it’s right near the lounge, and suddenly it’s reading 1m, and Bermuda will have an easier time choosing it versus the 3.5m bedroom proxy. It’s less about the distance between the proxies and more about the difference in distance between you and the two closest proxies. You want one proxy to be a clear winner in the places you tend to loiter - ie, place the proxies near the places you hang out, rather than places that are corners of rooms etc.
Note that this advice is for the current simplistic area matching that Bermuda does. Once trilateration is ready, we’ll probably lean towards having proxies more spread out. Maybe. We’ll know when we get there, I guess