I don’t think they can be “too close”, however 2.4GHz is well and truly into the dark arts area of RF propagation, so line-of-sight I’d expect anything under 2.5m or so you could expect random hopping between them because of reflections etc. But 2 metres or more, with a wall I’d expect should be pretty stable, purely on signal range, anyway.
What you might be seeing is less signal strength and more temporal - if a proxy doesn’t report in for a few seconds and a more distant one does, the odds of the device popping over to the other side go up. There is filtering to reduce this so it would normally take quite some seconds to happen (effectively a close proxy that goes quiet should still “win” for a while, but if another proxy reports a closer measurement than the older one did we jump immediately). Also if a close proxy reports a distant measurement which implies rapid movement, we either ignore it or we filter it to gradually increase the range to that measurement over time.
I suspect (because other Shelly users have reported it, too) that your proxies might be not reporting in for some time (someone else had 70 second gaps in theirs!).
If you call the bermuda.dump_devices service you’ll get a dump of Bermuda’s internal state. It’s a list of every “device” seen, its attributes, and a tree containing data from every scanner that has “seen” it. That tree contains per-scanner(proxy) histories, the one called hist_interval tells us the interval between each received update for that proxy/device combination - most recent first. (tip: use the “fill example data” button to see how to limit the export to a few addresses, will make looking for things much easier).
So for a given thermometer, my main studio proxy has:
hist_interval:
- 59.845819782000035
- 30.15393078204943
- 40.07791629899293
- 12.498973899986595
- 12.501973896985874
- 10.005979107983876
- 9.953979222045746
- 2.558994658989832
- 12.385974148986861
- 5.119989314000122
Which is truly terrible - hopefully that device is at the other end of the house, because this says I am only getting updates for it on that proxy very sporadically - nearly a minute between the last and second-last, 30s before that and so on.
Oh… I just checked and the distance on that thing is only 2.9m or so - I should be getting much better intervals than that! Around 2 to 4 seconds is “typically ok” (but still disappointing).
If I look at the device entry for my “development watch” which just hangs out on my desk, and check the stats for prox-studio on that, I see a distance of 5 to 6m, and the hist_interval is:
hist_interval:
- 0.8139985819580033
- 2.7419952219934203
- 0.4239992620423436
- 0.8269985590013675
- 2.120996303972788
- 0.9479983490309678
- 0.9299983789678663
- 2.0489964309963398
- 1.0239982150378637
- 3.778993413958233
This shows that the proxy is actually working fine, as we’re getting 1 to 2s between adverts (we only check every second, so that’s sort of our min resolution). So that means the thermometer is probably reporting at weird intervals (quite likely, it almost certainly has a flat battery in it, so maybe it’s booting any time a stray neutrino pushes a spare electron out, then dies again).
If you take a look at your hist_interval’s and compare between devices vs between scanners it might give you some insights. @lazmo88 had some issues with their Shellys, you can see the hist_interval in my comment at Bermuda - Bluetooth/BLE Room Presence and tracking [custom integration] - #95 by agittins - good-looking ~3s intervals but with over minute-long gaps every ~10s or so!
These sort of gaps will cause the device to “jump” over to the next-nearest proxy, even if it’s quite far away. And if there isn’t a next-nearest proxy, it will go “unavailable” instead. For the unavailable state, you can increase the devtracker timeout setting in the bermuda global options, it will leave the device in the last-known area for the same timeout in the absence of any competing measurement.(Edit: incorrect. the current version uses a separate, hard-coded timeout of 30s. See my next post for more info).
It’s difficult to filter/tune these things out because one proxy suddenly not seeing a device and another one suddenly seeing it is an entirely valid situation when things move around, so it’s a case of balancing responsiveness/latency against stability. I personally lean toward reducing latency so that entering an area happens promptly.
You can then use the duration param in automations to delay acting on a change trigger until you’re happy to commit - for lights, you might want to trigger immediately since the risks are low, but for a trap-door you want to make sure they’re far enough down the hallway first, say.
I am not sure the OP wasn’t a bit confused between the watch’s ibeacon and what they were reading about the companion app’s ibeacon, but if the watch can send iBeacon adverts then it should work with Bermuda.
