^ Sure but it doesn’t automatically add the “Beacon” code - which is what you need to have it broadcast a specific (user defined) uuid… and the reason you need a specific uuid (that only you…the end user…knows ) is there are so many hundreds BT signals around (including devices that change their uuid’s multiple times a day)… it’s near on impossible to find then “grab” the actual uuid the device is broadcasting - when configuring it for use by Bermuda… 
Well that’s been my experience anyway…
Shelly’s pop up as “Shelly” so does Hue but as @agittins says pretty much every other BT uuid remain unnamed …
I believe @skank isn’t trying to track the smart plug, but use the smart plug to track some other device… that device to be tracked will need an uuid, not the smart plug, so beacon code isn’t required here.
Am I missing something?
1 Like
I have a mix of Shellies, some of those plugs that @skank is setting up and a bunch of other ESPHome devices. It’s true that every Shelly broadcasts itself as a BLE beacon, but not the other devices, and I still can use those with Bermuda without defining a beacon for those.
stuff about “area settings” and “area sensors” etc.
I believe the root of the confusion is that you had added your proxies to your “configured devices” list - which you do not need to do and gives you no functional benefit. Adding them creates “area sensors” for the proxies that look confusing because it looks like Bermuda is changing their “area setting” but that’s not the case - and to be honest I think that in trying to explain that I caused further confusion.
Fair warning though, I’m going to keep doing that, I can’t seem to help it. 
I think the root of your issue is that you are seeing devices (like your watch) bouncing between different areas. This is a common experience and somewhat inherent to the method we are using. It has been discussed a fair bit here, in the issue queue, and the wiki - which I have just updated with some more info. Solving it in software usually involves some trade-offs so can be a matter of compromise and will depend on your particular situation and needs, so will probably always be an issue at some level. We can’t “fix it”, our challenge is to find satisfactory ways to “work around it”. Trilateration will improve this, but no doubt come with its own set of caveats. Throwing more proxies at the problem also helps, a lot.
So the basic answer is:
- You’re doing the right thing with your automations
- Check the suggestions on the wiki
- You can ignore the “Area Sensors” on proxies completely, they are not “doing” anything. The only reason you are seeing them at all is because you added the proxies to your “configured devices” list. Take them back off the list if they cause angst, it will change nothing functionally.
- Correct, we assign an “Area setting” to each proxy so that Bermuda knows where it is.
- No, you do not need to assign “Area settings” to any of your “bermuda devices”. Bermuda doesn’t care at all about that, but you might find it useful for organising things in HA (eg I place all my personal devices in an “area” called “Portables”, because I like to do that to make them easier to find in HA’s frontend).
Because I can’t help myself I will briefly(!) jump up on my pedant’s soapbox for a moment and address some terminology, because it can get in the way of communicating clearly when we use terms from differing contexts. This isn’t intended as any form of criticism, I just want to clarify where I’m coming from in terms of terminology…
In line with what I think is general usage, I’d suggest thinking of Beacons as just transmitters, and definitely not necessarily fixed. A lighthouse is a beacon, yes - but emergency locator beacons (like EPIRBs etc which are commonly used when hiking or boating) are also beacons, and are most definitely mobile. The strobes on aircraft are also called “beacon lights”, and emergency vehicle lights are called beacons - all quite mobile!
A beacon is something that sends a signal designed to be positively identifiable. That signal might be electro-magnetic radiation (radio, light, infrared beam etc), or smoke, or sound or any other form of signal. A beacon may or may not be fixed in location, but is usually intended to be identifiable (eg: “That’s an emergency vehicle” or “That’s the Cape Byron lighthouse” or “That’s an aircraft” (or “That’s specifically Qatar Airways A7-BEN at 30,000ft”), or “that’s Gondor calling for aid” or “that’s where my cat took off his collar for the fifth time this week”).
Note that a proxy (aka a scanner) does not need to act as a “beacon” to do it’s job as a proxy. Indeed, ESPHome devices by default do not, but Shelly’s by default do.
I’d suggest only using the term “beacon” if you are referring to a device that is transmitting advertisements, and the term “proxy” or “scanner” to refer to… proxies. If a proxy is also being a beacon that’s fine, but it’s misleading to call it a beacon when discussing its function as a proxy. I hope that makes sense!
What will be improving your situation here is that you are installing more proxies, and also that they are ESPHome proxies, which are “better” at being proxies than Shellys on official firmware. This is because Shelly (quite understandably) restrict how much “effort” (cpu time, bandwidth, memory) their devices will put into proxying advertisements in order to guarantee that they still work very reliably for their primary purpose - which typically is vacuuming up the darkness when you press the light switch.
The fixed devices that send broadcasts such as your hue bulbs (which I would accept being called “beacons” in that context) are making zero contribution to the situation, because Bermuda doesn’t currently use one device to firm up the estimates regarding another device. But it will, when we have trilateration. But in either case, you don’t need to add them to your “Configured Devices”, because once it can, Bermuda will just use them silently without you knowing it.
I’m not sure if you were speaking narrowly to your example so I might be taking you out of context, but I want to point out that this is almost the opposite of how it works, and also that certainly in HA, “sensors” have nothing inherently to do with movement. They are things that report a single piece of information. Also the “sensor” in the context of this discussion is not “in” or “of” your watch, it’s “in” HA, and “about” your watch. (I seem to have my super-pedant pants on today! 
).
Sensors are about “perception”. They measure some property of a thing, and make that measurement available in a (hopefully) convenient form. It might measure motion, or voltage, or a fluid level, or the amount of water vapour suspended in the air, or something less finite like an emotional state. In HA, sensors reside “within HA”, not, say, “in your watch” (of course your watch also contains sensors, but these are not in themselves HA sensors). Sensors (particularly in HA) are not the thing, they are information about the thing. In the context of Bermuda, it does not use any sensor “in” your watch. Your watch simply broadcasts signals. When the proxies receive those signals, they measure how strong the signal was when they received it. Bermuda takes those measurements from the proxies, and creates sensors in homeassistant describing things like distance and estimation of “area” based on those measurements. The data contained in the broadcast is largely irrelevant to Bermuda, other than to make choices about what to name the… uhh… “HA device”, to which the sensor belongs.
Hopefully the above clarifies this a bit - so no, the watch (not the sensor) is broadcasting a signal. The sensors in HA are about that signal, based on info from the proxies that have received it. I get that this might be what you were saying anyway and you were simplifying for clarity, but it’s difficult for me to know if you’re simplifying or misconstruing - and then you have to put up with me typing great novels containing my autistic explayonnaise
It might also be worth mentioning here that the uuid (or uuid+major+minor) is nothing particularly special, it’s just an identifying label that is part of the iBeacon:tm: packet format. The benefit is that the iBeacon uuid serves as a stable “label” for identifying a device, especially those that change their addresses periodically. If your device can be set up in the “Private BLE Device” integration you really don’t need iBeacon support at all - except it might help by keeping a phone awake and transmitting more often.
Yes, it’s not called “Beacon”, it’s called “iBeacon”, which is a specific protocol that Apple created and has a very specific meaning. And in this case Bermuda gives you two options for “referring” to this bluetooth device, and it creates two entries in the “Configured Devices” drop-down selector. One is named by the iBeacon UUID, and the other is named by the device’s MAC address. If the device is in the “Private BLE Device” integration then it will just automagically appear, whether it sends iBeacon packets or not.
The bit above and the wiki reference covers most of this, but specifically on what to expect from future updates… Tweaking this behaviour is an on-going effort, but also the issue is inherently tied to the fact that we are using an incredibly noisy and inaccurate method of measuring distances. Many of the remaining levers to pull involve trade-offs between desirable features. I treat latency (how quickly Bermuda decides that you have arrived somewhere) as very important. Two seconds is too slow, one second is tolerable, in my opinion. If one was OK with 10 seconds, then you could have pretty rock-solid area detection, but annoyingly slow to respond to changes. For those that want to trade off some latency for more stable area lock they can have their automations filter the data by requiring a sensor to be in a state for a certain period of time before triggering - this is built right into the gui with the duration fields.
I do see quite a few people who are getting really long gaps between advert reports from their proxies. For example this (via the “download diagnostics” or the service (action) call bermuda.dump_devices) shows a very erratic spacing of adverts. If the device this relates to was close to the proxy the whole time it indicates a firmware, stability or networking problem on the proxy itself:
This is why in v0.6.9rc2 I’ve added some info to the config flow so you can see when each proxy last reported in, giving an overall picture of the bluetooth backend’s “health”:
Here you can see the “camfront” proxy hasn’t sent an update for 5 seconds (because I rudely pulled its plug!) while all the other proxies sent updates less than a second ago.
Egads, I should stop typing!
2 Likes
To clarify, it’s not the uuid that changes, but the phone’s bluetooth MAC address (the mac address looks like de:ad:be:ef:b0:ba, versus an iBeacon uuid which looks like dcf1c203-cedd-cb8f-1609-6ba3ef705f55. Hmm… to be fair they do look a lot alike! ).
If you have an app (like the Home Assistant companion app) that sends iBeacon broadcasts, the uuid in that won’t change.
@skank the best way to track phones is to set up the “Private BLE Device” integration which is built in to home assistant, and Bermuda will use the info from that automagically. There is a bit of mucking about to do it as you need to find the “private key” that your phone uses. If you have an iPhone and a macbook it’s fairly easy, but currently trickier for Android phones. I’ve gathered what I know about the various methods of doing this in the wiki at Supported devices · agittins/bermuda Wiki · GitHub in the “Devices using IRK / Private Resolvable Addreses” section. Let us know if you run into any difficulties with it.
You don’t need to do this, unless you specifically want to track the location of that particular esphome device.
Huh… good point! The docs still say
The Bluetooth proxy depends on ESP32 Bluetooth Low Energy Tracker Hub so make sure to add that to your configuration.
But as you point out that isn’t necessary (I had to try it myself to believe it though! I wonder why skank’s earlier config didn’t seem to work? Ahh well, seems to be working now anyway.
1 Like
On my Android I had to increase transmitting power from ultra low to low in order to be detected. Is a setting in HA companion App
1 Like
I cant follow here anymore.
What i want to do:
I have an esp32 plug which i want to use for tracking. I dont want to track the plug, i want to track a smartphone (and later a watch).
So as i read, i read that i need an esp32 device to track my watch… So far that i bought the plug, and i’m trying to use the bermuda integration. (instead of espresence).
So i follow the yaml provided by @agittins
Is that good now or not ?
Now that i have that all set up, i want to add my smartphone to the devices inside the bermuda integration.
That is correct no? I have to add the devices i want to track?
Thatwshy in the settings of the HA companion app, i enabled this so its transmitting (i first tried and didnt work, i then changed UUID to blanc, didnt work either and then i entered a generic one) .
The smartphone is now transmitting. … . So i though i would now see that device (with the generic uuid) inside the list of devices of the bermuda integration
But i dont see it there.
What am i doing wrong here?
I’m also mixing things up, tracker, node, proxy, beacon
Also just the standard tracking of a phone inside HA is not why i want this, i want to know which room i’m in, using BT tracking, so i thought i was right to be here.
I’m sorry but confusion here is now complete.
Yes, that should be good.
ok but how to add my phone now, so i can track in which room it is?
the esp32 plug is in my “woonkamer” or living room.
Strange but after clicking configure>global options>send
I got warning
Bermuda can currently see 24 active of 41 bluetooth devices, reported across 1 active of 2 bluetooth scanner devices. Life looks good.
Not sure which my 2 bluetooth scanners are…
I thought i only had one (the plug)
But then i could finally see the uuid of my smartphone.
I clicked it, in the device list…
And now i have 1 device (strange name): 3422b44824604fd291838000de6f8343_100_40004
its the uuid, why doenst it take the name of the phone?
I got 2 sensors now, and 6 hidden
Area and distance but both are unknown?
Edit: Aha, guess it needed time… both sensors are now filled in
What i dont know now… Where does he take the name from the area?
Edit 2: Whats hci0? Is this the second bluetooth scanner? But what is it? My raspberry pi? (HA device)
@agittins It is a pleasure to be using (and trialing) your totally awesome Bermuda integration. And no. I’m not taking the piss when I say that! Thanks for the detailed explanation of the terminology you use. I’m sure others will find it useful as well. I added the fixed “proxies” (I call them beacons) …hahaha (sorry about that) anyway I added them into the config of bermuda, because I found it easy that way to figure out distance and what was going on in the integration. It also confirmed they were actually working - “doing their thing”! You’ve said you can remove them out of the integration once everything is confirmed “working”. I find bluetooth such a hidden box of enigma, so I find it’s easier “to see” they are there and that they are working! I’d like to leave them visible in the integration. Is that OK? One last quick question. Is there any downside in doing that? Cheers
Go to Settings > Devices and Services > ESPHome and select the device where the Bluetooth proxy is running. Click to edit its name. You will see a box for the area where that device is installed. That will be used by Bermuda, which will find the area of the closest bluetooth_proxy device and use that in the area sensor for Bermuda.
That is the Bluetooth dongle plugged to your Home Assistant machine. You can also set an area for that one by going to Settings > Devices and Services and looking for the Bluetooth integration.
2 Likes
Cool thx, allright then i already own 2 scanners 
I dont have a bluetooth dongle in it, its just the raspberry pi.
Will add it to area too
What i noticed is, that the sensor area and distance are filled in, but then seconds later unknown, then filled in, again unknown… etc etc
How come?
Also the distance is way further than it actually is. It says 15m and its like i dunnoi 7m or something.
Will try thx
The weird distances can be caused by room layout, furniture, people moving around… Basically, the Bluetooth signal at the proxy appears to be a little weaker, so Bermuda thinks it’s further away.
If you use the beta version of Bermuda (0.6.9rc2), that will allow you to calibrate each proxy individually. More proxies also improves room detection - Bermuda will have more points of reference.
1 Like
ok and what about it being empty and filled in again, is that cause of the same thing?
Esp32 cannot operate Bluetooth and wifi at the same time so it’s a constant redetection. What that’s sayin is that the settings (read the docs he explains this) are set to an assumption of how fast yojr device is polling and allows it to burn out to nothing you’re just not getting g it rewritten before it’s cleared… So look at the timeouts in the configuration and set them appropriately for your setup (no there’s ko magic bullet for calibration and timing you HAVE to experiment.)
And I’m glad to hear per proxy calibration is coming. I wasn’t even going to bother until that became a thing.
1 Like