@agittins 0.6.9rc2 is a massive step forward! I love the additional debug data that is available directly from the UI. Also, calibration is easy, once you get the concept of it
Just wanted to share some personal experiences regarding hardware (perhaps something we could start adding to github wiki/readme).
For people not using ESPHOME / ESP32 boards in their home, I bought some Shelly BLU Gateways. They worked out of the box with HA and Bermuda picked them up as proxies without any issues (there are basic steps to connect these to your WiFi and then configure them on HA with native Shelly integration and enable passive BT scanning). For reference: https://www.shelly.com/en-fi/products/product-overview/shelly-blu-gateway
Using identical BT proxies (anchors). My NUC BT adapter was extremely sensitive and caused unstable readings. Even after manual calibration it was way over the place. Using identical proxies made the tracking way more stable.
Don’t overlook calibrating your beacons! There is a massive difference on tracking accuracy depending on how you configure your beacons. Using identical tags for asset tracking can also help with this, just make sure if you buy separate tags that these tags support adjusting TX power and intervals. In my experience, lower TX power and more dense anchor placement gives you the most solid accuracy.
If you are having a hard time with “area bouncing” even after tuning your anchors and tags you could use automation to filter bounces. Here is example code I am using to make sure tag area is “stable” before triggering any actions.
Can you provide some screenshots? The “configure devices” screen and the screen of the device showing the sensors might help shed some light. There have been issues previously which I thought were mostly fixed, but things are a little complicated by the way we track multiple things (like via IRK, or beacon ids etc) so something may have slipped through or cropped back up.
The best way for me to see what’s going on is if you do a “download diagnostics” and post that to the github, but a few screenshots might be the easiest way to get some more info to start with.
As @lazmo88 noted there is a bug with deleting proxies that no longer exist, but I’m not aware of an outstanding issue with devices (but then my memory is terrible!)
That’s good to know, and yeah, might make a solid option for those not wanting to dig into the whole esp32 universe I’d be interested to see what the hist_interval stats are like from those - if you have time to dig out a bermuda.dump_services or the download diagnostics for some analysis that’d be great. Especially interested in comparing them to both esphome with a known config and with the shelly switches etc. I’ll add them to the suggested devices info.
[on using identical radios where possible, and calibrating otherwise]
yep, definitely agree on that. Interesting that you couldn’t calibrate out the difference with the nuc bt adaptor. I wonder if the attenuation factor might need to be tuned in order to get the offset to line up properly? The attenuation is meant to be a factor of the environment (temperature, humidity, air pressure, amount of garlic in the kitchen etc), but maybe when the ref_power offset becomes large the maths gets a lot more sensitive to an accurate attenuation? It’s also possible that receivers might just never really behave “on the same curve”, and mixing different radio types might never really work well.
Yes, I know I’ve mentioned a number of times but never with the clarity of a yaml snippet - and I don’t know if I have that in the wiki yet.
Great feedback, thanks! When I get a chance I’ll incorporate these tips into the wiki better. I think I’ll need to move the wiki out into its own repo at some point, since the navigation is causing issues for some, and there’s no PR workflow for the built-in wiki
I could adjust the NUC to a certain extent, but I just found the identical proxy so much easier. The NUC readings were very unstable, so could also be the device/location/interference that made it very choppy TBH, I have not wrapped my head around the concept of attentuation and for now the ref/tx power tuning seems to do the trick.
Moving wiki to own repo could make sense indeed!
@agittins I saw the conversions at Implement trilateration of devices · Issue #21 · agittins/bermuda · GitHub - have you stepped into AI code development yet? I noted some ideas/examples were coming from Claude I have been using Claude Sonnet 3.5 with ClaudeDev on VSC and it has shown some pretty decent results. I wonder if we should take a shot at applying the triangulation into the code base? We could perhaps use other projects as reference and see what Claude comes up with?
Well i fixed it manually now, but ill try to explain
I had 3 devices here
If i deleted one there… i assumed that in this screen:
The device would be deleted too, but that was not the case.
I had to go into the device and use the 3 dots to disable the device and then delete it manually
If you use plugs like me cause u dont have any esp32 boards in home and dont want to use gateways but profit from energy monitoring and toggling device on/off too, u could consider this:
This works too with the yaml from agittins provided.
This seems like a very good option as well! I think we should start collecting a list of “out-of-the-box” devices that work well as proxies for Bermuda? Could help someone to get started
I particularly like the concept of identical proxies…
(Could something as simple as 4 Hue BT bulbs in each corner of the room work? Cheap, available, easy to identify, don;t have to configure anything, all the same and on zigbee - cause I’m running out of wifi spots on my dhcp. I assume they are acting as BT proxies?) Time is money in my world.
I don’t regret one bit starting out on this journey early… messing around etc because that’s what I’m like - a tinkerer and there is no doubt having different proxies (I have 4 different types) is the number one issue I am having.
Thing is nobody realises that until after the event, right?
Experimenting early on, also helps you understand stuff under the hood and having the opportunity to discuss things, point them out in a forum like this is fantastic (and thanks to Ashley for giving me that opportunity) I hope the feedback is very valuable for mankind in the future because if this project can be rolled out into the HA community (and adopted in gusto by them) , heck dare I say into the big wild world of the Wildebeest, it’s going to be massive - massive IMHO
@lazmo88 If someone like you could do a utube on it (even better probably more like a series be needed I’d reckon), that would be awesome. I’m waiting for smart home junkie, or everything smarthome, Reed or Geoff or Digiblur to get their head around it and do it - that would be great. Particularly the calibration bit…
Oh and Ashley I do understand what you are saying
Onwards and upwards!
Go Bermuda!
cheers
I had a play with doing ‘per proxy’ calibration last night on a few of my proxies. it was super easy and within no time at all I had 5 of my proxies all reporting the distance to my phone quite accurately.
I’ll try the same with my remaining proxies sometime soon and report back how the device tracking is going as I walk around the house.
Cool… I know you have a utube channel Dave…care to make a vid?/!!!
(P.S I was going to follow your switch the light bulb vid to test a Shelly on a smart bulb until I realised if I burnt the house down… )
My YouTube channel is all 4x4, motorbikes and go-karts.
I could probably look at creating something though. I don’t have any fancy setup for doing so though, all my existing videos are old from a camcorder, phone or action cam.
Great! I have been a bit worried about the UI for calibration, and in my usual style - used loads to text to try and address it!
Did it take long to work out what the process was re using “submit” to refresh the results and ticking the box to apply them etc?
If anyone’s seen other integrations do this sort of thing (ie, interactive back-and-forth in config flow) better I’d be interested to know. Custom integrations particularly. The ZHA integration has some nice features in their config, but they had to add custom stuff to core for that to work, so not really an option for a custom integration.
At first I was a little confused as to how to get the numbers to update but then I read it more thoroughly and all was fine.
It’s definitely really nice seeing all the proxy reported distances in the one table to see which ones need tuning. After re-doing the initial 1m distance calibration I simply left my phone in a central location 5m from one proxy to get the rest sorted. I still need to do more testing and also finish the remaining proxy calibrations but so far so good. Doing the individual calibration was on my todo list for weeks. I have a combination of plain ESP32’s, M5stack ESP32’s, NS Panels and and an Olimex PoE ESP32 so the signal strength from each type is vastly different. This helped a lot.
Yes, we tried doing that at first, and it looked like it was working, but it actually behaved really weirdly, eg when you went back into the calibration it only had a single advert measurement, and wouldn’t update. I think once we save any options it must reload stuff in the backend so the config flow you are in is then a zombie, looking at stale objects that don’t work anymore.
If someone knows what’s going on there and has a fix it would be welcome, just understand that the obvious first-attempt solution doesn’t work the way one would expect
I don’t think Hue BT bulbs can act as a BT Proxy (anchor) (these won’t report advertisements from beacons to HA). Yet, you could use them as beacons (tags) with your setup and perhaps use them to calibrate your proxies.
BT Proxy / Anchors should always be fixed and should have capability to relay data to your HA. ESPHOME, Shelly and generic BT USB radios are good examples of this.
Tags, quite often iBeacon (protocol used alone by non-apple hw) devices are used to track assets or people in the space. You can use pretty much any BT device which is able to transmit advertising packages continuously. You can use your own phone (with HA companion app), or various BLE tags such as AirTags, Chipolo, Galaxy SmartTag etc.
Problem with these consumer level trackers is lack of adjustment of tx power and transmission intervals. Due to this, you can’t fine tune your tag s for better accuracy.
Example: Your AirTag is transmitting data on max tx power, with too slow interval. By maxing out the tx power, more noise there is and more anchors will be receive the signal as the signal can travel 30-50 meters. Which can cause “bouncing” effect of your tags location. If you could lower your tx power, you could limit your signal range to 5-10 meters, which would give you nether accuracy as not all the anchors will pickup the signal, only the closest proxy would report the device to be seen.
Second adjustment is transmission interval, some consumer level tags send out packages with too long intervals. This is most likely due to a battery saving or whatever reasons. Issue with this is, Bermuda could mark theses tags as “lost/unknown/unavailable”.
For above me tined reasons it is extremely important to check that your intended tags can be configured and adjusted to yours needs. HA companion app is great to test this as it does allow tuning all the BLE transmitter settings. Going from Transmitter power High to Medium makes a massive difference.
For sure you can also calibrate your anchors (and maybe you should), but I personally found tag calibration equally important.
I have been using Claude Sonnet 3.5 with ClaudeDev on VSC and it has shown some pretty decent results. I wonder if we should take a shot at applying the triangulation into the code base? We could perhaps use other projects as reference and see what Claude comes up with?
