Hi Ashley - I am sorry, but this is driving me nuts…
For this integration to be practical
You’ve got to be able to anchor down “Bermuda area” in trilateration…
You can’t have a beacon/proxy that you want “fixed” in position in a room… wandering it’s “Bermuda area” away from that room…
If I have three (or in my case now 4) proxies - each in a corner of a room, each of them must always only show a Bermuda “area” in that room… ie “be trilateralised” to that specific room only….
The room in question now… my Bedroom… has 4 proxies. One in each corner.
The room is 4 x 10 meters
It is 15-20 meter away from the nearest room with other esp32 devices in it (also with Bermuda)
Yet one proxy is “wandering” to that distant area…
It is then “dragging” the newer proxy with it (that I just added)…
You can’t have this happening for this all to work…
You got to be able to “fix them” all in one room position…
Or to put it another way… “bind all these proxies” together (in logic/or in HA) somehow so their Bermuda Area only relates to each other….
I’m sorry… otherwise things just start randomly wandering all over the place as one tries to rollout more proxies…
my apologies
Just MO
Cheers
Read the docs. This is like step 1 on a path to… (and it’s quite a step even with the random pulls (yes I’m seeing them too, it’s inevitable if you’re just grabbing last heard)
The dev intends to eventually enable true triangulation. (they mentioned iwhat it takes and why they’re not there yet) Which will solve your issue but that takes. A lot.
The integration will have to:
Positively ID each sensor in 2d space. (doesn’t have that yet. Just uses area now. will need a relative x, y)
Then provide a normalized strength indicator (they require per proxy calibration for that - note recent versions, dev noted it’s coming)
Once you’re getting a calibrated signal strength from three sensors. You can position the radio source in 2d space with trigonometry…
So as soon as signal calibration is available I’m working on positively I’ding mine on a grid map I pulled from my vacuum. 
Ok
I managed to set my garmin watch to transmit BT…
Using bermuda, i now can see in which room im in , using 3 scanners, yes even the raspberry pi is picking it up, and so far, its far more stable than my phone, which isnt working anymore.
Since my watch cant be connected to my phone.
I need to have an automation to disable bluetooth, once i’m home and enable it once im not home (but not in a room either).
If my watch does disconnect BT when im home… (for example i want to check garmin connect manually by turning on BT) it should use my smartphone to check in which room…
How do i do all this?
Also my location… it should use my watch when i’m home or smartphone when bt enabled…, but when tthey are unknown or unavailable, they should tell “home”.
IF im out, it should tell away or the zone i’m in…
Who can help me here?
I actually have a sensor now, but it doenst use the watch yet, and the watch makes it complicated lol
- platform: template
sensors:
locatie_me:
friendly_name: "Me's locatie"
value_template: >-
{% if states('sensor.me_huidige_kamer') != 'unknown' and states('sensor.me_huidige_kamer') != 'unavailable'%}
{{ states('sensor.me_huidige_kamer') }}
{% else %}
{{ states('person.me').replace('not_home', 'Away').title() }}
{% endif %}Ok, Imma have to ask you to slow down and really digest this. Apologies if I come across a bit blunt, but this is my third attempt at conveying my meaning (not counting discarded drafts).
Proxies don’t wander. Why would they? AREA SENSORS ON PROXIES ARE INVALID, you should not turn them on. Go into “Select devices” and remove your proxies from those lists - as previously advised. They don’t DO anything - except cost me hours trying to explain why.
The area sensor answers the question “what’s the area of the proxy that this thing is probably closest to?”. This is not a question Bermuda asks internally for any reason, it has no use for the answer - but you asked it to calculate it and tell you.
So, “what’s the area of the proxy that this thing is probably closest to?”. Since a proxy can’t “see” itself, if “this thing” is a proxy, the answer will be “the area of some other proxy” That’s why the area sensor on a proxy will show you the area of (and distance to) SOME OTHER PROXY, and so for almost any purpose (and certainly every purpose you have mentioned) is INVALID.
What I think is going on here is that you are probably experiencing a problem - perhaps with other devices bouncing - then you have looked around for what might be causing it, and you have fixated on the area sensors of your proxies - which are irrelevant and only exist because you chose to turn them on - and you decided that THOSE are your problem. I can assure you they are not, they having nothing to do with your problem, because they don’t DO anything. To anything. Except your own confusion. This non-related thing is then what you are blaming for your root issue, because you are not listening to what I have been telling you about what they (don’t) mean.
What this means is that the nearest other proxy that can see this proxy, is a bedroom proxy, estimated at 2.1m away. If it was measuring its distance to its own location it would be 0m.
No, it doesn’t - and this is the incorrect conclusion that I think is causing your confusion.
I’m not sure if that’s an accurate quote (it might be though, I do go on a lot) so to clarify my meaning: Adding proxies that don’t physically move to your configured devices list serves no purpose. If doing so feels bad, stop doing it.
It clearly doesn’t
It didn’t. You enabled a sensor that makes no sense and does not do anything, and then you decided it’s doing something.
The measurements are recalculated each second, but filtering/smoothing is done based on the last 30 or so seconds (depending). There are no measurement aspects that survive more than a minute or so, or a restart of HA. They are almost certainly also reset by a reload, but I haven’t verified that. The only things that persist over a restart are the configuration options that are set, so every startup happens “from scratch”.
I don’t know. Almost certainly more than a week. Estimates beyond that are really hard to make. A solid weekend in flow-state might do it. Or it might not. It’s the number one goal as features go, but I am also trying to improve the docs as I go so that I can point to pre-prepared answers to common set-up issues, to reduce the amount of time I need to spend on support - because if trliateration works at all, I think the number of people trying it out is likely to balloon. Plus, you know… real life, and all that
Setting the area setting in HA for a proxy is nailing it down to a single area.
Great!
Not great! 
It’s probably worth checking how you are trying to track the phone - if Bermuda is tracking the MAC address it may have changed - but the IRK or an iBeacon UUID should both be stable.
Any time I have a build failure with yaml that should work I usually find that “clean build files” tends to fix it (in the three-dots menu for the device in esphome).
But you really don’t need to worry about updating every version of esphome that comes out, unless it specifically mentions improvements in a thing you are using or has relevant security fixes.
It’s a bit trickier than that, even (sorry!) - you want your phone to disconnect from your watch, but still have bluetooth active (so Bermuda can see them), If you are using Gagetbridge to connect to your watch, it supports being controlled by “intents”, which you can send from the HA companion app in an automation. Otherwise you might need to see if HA companion can disconnect a specific device from bluetooth - I don’t know for sure if that’s possible or not 
I think it should:
- use your watch’s “area” if it’s not unavailable/unknown/away
- use your phone’s “area” if it’s not unavailable/unknown/away
- use your phone’s bermuda device_tracker if it’s not unavailable/unknown/away
- use whichever device_tracker sensor give you zone names.
You shouldn’t expect it to say “home” if it can’t see your watch or your phone - for bluetooth signals all we can know for sure is when you are there. We can only assume that you’re away if we haven’t seen any bluetooth packets for a while.
Sorry I can’t help with the actual yaml/jinja - but I think you are on the right track generally, and there is probably a clever way to do it with just jinja filters - I don’t have time (or internet connectivity) right now to come up with a useful example, but hopefully someone else will have some ideas. You could also create a separate thread for ideas on the jinja since it’s not bermuda-specific - you might be seen by more jinja experts that way
The phone is using ibeacon UUID (but i changed it by myself, maybe thats the problem… but i dont know how to reset it to default in the companion app.
About the disabling bluetooth. Why should i want to disconnect the phone from the watch…, then i have re-enable the connecting everytime i want to watch.7
Wy not just put out bluetooth entirely, i dont think i need it inside my home anyway and it preserves energy
ok about the ninja, will look into it.
Anyway, other question, i might have found a bug?
Inside the bermuda integration i can configure-> select devices.
I deselect a device there to stop tracking, but in my integrations its still there.
Somehow i cant delete it?
Even restarting doesnt solve…
Yes.
This is Exactly what is needed
For fools like me to understand and make it work.
As usual, I am too early on what is otherwise a very exciting project
I now understand that the sensor “bermuda area” of a proxy is "what’s the area of the proxy that this thing is probably closest to ?” (Lets for argument sake, say area “x”)
The point I am trying to make is that for a mere mortal like me to make Bermuda work (and certainly to run automations off it) - in the real world of varying BT signals and roll out in my particular circumstance, that assumption “probably” is just not solid enough…
In my opinion to make the project practically viable “probably” needs to be set in logic (in other words on occasions) be permitted to be overridden in the integration by the end user, as “no it’s not”… it’s closest to area “y”…
Only the end user knows where a proxy (they have in a fixed position) “actually is”
Since when in any form of “area survey” is the end user taken out of “confirmation of position”?
AI gets things wrong - I mean it;s always needed humans to get to this point
('Im getting philosophical now) 
I already have 3 different types of proxy boards. Shelly’s (several), a self made and programmed esp32 chip and now SMLight POEs (the ones with large antennas)
For me - that was the quickest way to get to the point where I’m at…
Yes I get all this needs “calibration”… the question is with everything else going on in the roll out of something like Bermuda - (it takes a very long time to get to the point I am at) how many hrs of time and effort does it take to get that calibration correct enough to just make “things work”? And is recalibration required every time a different (type) of proxy is added or its fixed position moved?
Wouldn’t it be easier (if possible) if the end user could simply confirm a proxies Bermuda area rather than spend endless hrs calibrating? Particularly if problems are noticed to be occurring ?
There is a caveat here. I have no idea if this is (or will ever be) possible.
Anyway - nobody who gets to a Home assistant stage like me (a large HA project, building esp32 BT proxies, hacking iPhone BT, 70 odd zigbee devices, matter, voice, touch screens, several other HACS etc etc - self built) is ….“daft”
We are all on a quest, and I get that people spend hrs developing things, but please - no shooting the messenger. Someone just trying “to make it work” (in a practical situation)
This is not a critique. It’s meant as simple feedback from an end user. I never said I wasn’t appreciative, or that Bermuda wasn’t awesome
It is
I’m clearly not worthy
Cheers
POE Bluetooth Proxy and ESPHome | SLZB-06 * Series Manual I think it’s the SMlight that is causing the issue. Why the situation changed after I swapped out the two Shelly’s I have no idea. Maybe each Shelly has a slightly different BT signal/config - I have zero idea because I can’t look into the code of a Shelly. They are both set up exactly the same in the Shelly app and in HA. They are from Bulgaria. The SMlights are from Ukraine. And I am all the way across the reverse (both direction and polarity) the other side of the world. 
Anyway after I swapped them over from a 1PM to an i4, that’s when the Smlight sensor Bermuda area was “probably” in Bermuda area “Family” (some 20m away) when previously it was “probably” in the area it is supposed to be “Bedroom” (making up a trilateral). Now it’s probable area is “unknown”. has been for over 20mins. This is why on occasions I think it would be useful to actually instruct it "no you were correct the first time… Your Bermuda area is always actually “Bedroom”… Does anybody know the best setting for the BT radio on an SMlight? This information is not available in their manual as ESPHome is flashed over the proprietary firmware, and the code is directly accessed from github via the yaml “package” command. The actual yaml file is unsearchable … thanks
This is what we have been trying to explain to you mate, the BT proxy ‘area’ never changes because YOU SET IT.
eg:
The ‘area’ that gets reported by Bermuda is not ‘of the BT proxy’, but ‘of the device that you are tracking’. ie: which BT proxy it is currently considered closest to and whatever ‘area’ that BT proxy has been assigned.
If you are run the Beta of Bermuda you can ‘tune/ calibrate’ the reported signal strength/reported distance from proxy for each BT proxy to compensate for the varying signal capabilities of differing BT proxy hardware.
You mean this code???
Or this one??
^ I know all that mate…
What I am demonstrating is the sensor “Bermuda Area” (the one with the eye) changes area on a proxy that is physically static
… based on other proxies around it changing (being swapped in or out) …within the same room
I am saying it’s confusing (when rolling out lots of proxies) …or physically changing them around
I don’t write the code mate
If it’s confusing for me good luck with the general public
(Of course I have set the area up the way you say…)
Bermuda is beta enough for me as it is.
Before spending anymore time on it, I’ll wait for proper trilateralisation (triangulation) as per @NathanCu
Did you catch his post above?
Cheers
But this is not the case. The proxy area does not change. What you are seeing change is the reported area of your tracked device. To get that more stable you will likely need to calibrate the BT proxies as I mentioned. What is likely happening (as you rightly thought) is that some hardware ‘sees’ the tracked device better than others and thus think the tracked device is closer than it is, which then causes Bermuda to report your tracked device as being closer to that other proxy, which may then result in it being reported as being in a different area/room.
Yes, this was the plan for Bermuda from day one.
What “tracked device”?
When the reported changes occurred on the Bermuda Area on the proxy that was physically stationary - none of my “tracked devices” …(my phone or apple watch) were actually moving…
Nothing was “moving around”…
The only change made was one Shelly went in place of another (in the same physical location) and the original Shelly was moved to a different room
All the Shelly’s had their location area in HA reset (as you said) appropriately to the correct room
Cheers
The whole purpose of Bermuda is to track bluetooth devices that you carry around…
This one.
As I said, the reason Bermuda is REPORTING that it is moving is because you need to calibrate Bermuda.
testesphome/bt.yaml at 94ed52d1ed96c39110180ea037dcff688506d85d · smlight-tech/testesphome · GitHub Ok this would be the code I would use on the SMlight
I haven’t actually installed this exact code on the device …
I have the link to the code in the yaml as
packages: SMLIGHT.SLBZ-06(Bluetooth-only): github://smlight-tech/testesphome/bt.yaml
I thought that is all you have to do?
Yeah, that’s what I linked to where you can see the actual YAML in that package.
Well sure… I have no idea if those settings in that package are appropriate for Bermuda?
No idea…
Would anyone?
I am the first to acknowledge "calibration’ is a massive hurdle…
My apologies
I have done next to zero calibration.
It’s taken me days… weeks (hrs a day) even to get to this point
Buying the proxies, flashing them, wiring some of them, working out what to do with them, working on the Shelly’s etc etc
That’s why I am looking forward to Bermuda “triangulation”
My guess is most people in the future will be the same
Cheers
Anyone know , why the device isnt deleted if i stop tracking it in “devices configuration”.
Its a bug?
How do i delete it?
I think deleting tag/asset and anchor/proxy is not yet implemented. I have similar issues with old BT proxies which are still displayed in the integration, no matter if they have reported anything in ages or not.
Please read my post(s) again. I believe the reason you are having so much trouble is that you are willfully ignoring the instructions, and all of my (and others) attempts to help you. I know you’re capable of understanding it, but I am so freaking confused why you seem to choose not to pay attention to the words I’m saying.
Bruh.
You are totally misunderstanding what’s going on.
Then why won’t you listen to the person who does?
The bluetooth settings look OK given the device is using ethernet. They’re using the android sdk instead of esp-idf, the android stack is considered less performant for ble proxy stuff (mainly due to memory use, I think) but no harm in just trying it - it’ll probably work decently - and you can just try seeing if it builds OK using esp-idf as well - I think the only thing that might break would be the web component, if they’re using it.
No, you are nowhere near the first to believe it’s a massive issue, but many folk have then found that they can get consistently good results without it in the majority of situations. But they tended to follow the instructions. Others have found that the calibration features that exist now are solving some of the corner cases. I’m sure there’s still situations where it’s an issue, some of which could probably be addressed in other ways like proxy placement etc. But none of it is set in stone, always up for improvements.
Refusing to follow the instructions is unlikely to yield good results even after we have trilat.
I’m not offended by your feedback, I am confused (and annoyed) as to why you misinterpret people’s posts and won’t follow advice, especially when you’re clearly intelligent and excited about the project’s potential. You could be having so much fun with it, but instead you’re tangled up in a falsehood you can’t seem to move beyond.
I’ll try again because I really do want to help you: The area sensor with the eye, on a proxy, serves no function. That’s why I don’t enable them automatically in the first place.