Bermuda - Bluetooth/BLE Room Presence and tracking [custom integration]

Great!

Yeah, that’s why I’ve been trying to collate as much info as possible on the Bermuda wiki. This is where you’ll find my current recommendations. The big issue now is that i tend to be so verbose that i think the docs can seem impenetrable :sweat_smile: it’s a continual effort to fine-tune/simplify, while still giving enough info.

1000/980 or so used to be my preferred timing, but i think that 320/290 or in that ballpark might work slightly better, or at least should be less likely to cause “time starvation” for other components.

So that page is all “one device”, but the entities come from two integrations. Yes, the one named Bermuda (and Area, Distance) are all from Bermuda.

The 7ac… one and the “Estimated distance” are from Private BLE Device.

That name, 7ac… looks to be the iBeacon uuid. Did you add the iBeacon tracker in Bermuda config’s “add devices”, or did it just show up like that? I’d recommend that if you have IRK set up, don’t add the device manually to Bermuda, just let Bermuda pick it up from Private BLE’s config.

It’s safe to go into Bermuda’s config and remove it now, and you should still see you have one device, and there’s a good chance it won’t show as “away/unknown” on the private ble sensors.

I haven’t played with these myself yet, but i don’t expect it should cause any trouble. If the ld2410 component does a lot of comms then you might need to open up the ble scanning timings a bit, if you get lockups or errors etc. Also the mmwave stuff might reduce the sensitivity of the Bluetooth radio (because of extra rf noise) but i haven’t read of anyone finding that specifically. People would have similar trouble with the wifi if that were the case, i think.

Haha yeah, there’s so many moving parts it can get pretty confusing at times, it’s easy to miss things!

Glad you’re getting some good initial results though. Oh, and don’t be seduced by the max_radius setting. Lowering it might seem like a good idea but it almost never is - i plan to bump it up a lot by default in future, like 200m or something.

1 Like

Bermuda is awesome! Thanks to Ashley we have the most amazing potential with this exciting project. I have it set up accurately doing it’s thing and trigger automations and TS and iphone app location GUI settings in 4 rooms now. Its actually better than one of these dedicated “presence” sensors. Why? Well think about it. Not only is presence specific to a person, but if you have a wearable on in a room (and automations don’t trigger until you leave or enter another room) that individual is “always” present in that room. Look Mom - no other hiwave/IR/ “presence” detector required! I just need updates to the integration and direction how to set up upstairs and downstairs before I roll out anymore rooms. I am keen to try one of these new BT smart rings as the wearable. I just need to find out which one gives a constant uuid with weeks between charge… :smiley: Rock on Bermuda!!!

So I am doing a new post, which after I post I will come back here and share the link, and hopefully you can answer some of my questions there.

I usually do try to read the documentation, but seems you have gone above and beyond compared to what others do in github. Seems most put everything on ONE page of Wiki. You actually took the time to create different pages, and that is why I didn’t know where people were getting the info from.

Instinctively I was ignoring all them nice blue links on the right side. I would just start scrolling down the text looking for the info I needed. That is 100% on me, but confident many end up doing the same thing. As suggestion, on to of TL/DR you might put a big heading stating “Check the blue links on the right for the info you are looking for”. For those like me that just read the main Wiki page we end up very confused!

2 Likes

^ LOL. Get into it dude. Read up! Then roll it out… trust me… once it all “clicks” in your head (it took me a while)…you won’t be disappointed :smiley:

I don’t plan to quit. All I read is that once it is up and running is pretty neat. For me BIG rather HUGE part of the problem was the fact that I hadn’t seen all them links on the right side.

I am close to finally getting it set up, just having a bit of an issue with selecting devices. I do have an ESP32 running the FryeFryeFrye so now I am able to easily get the IRK’s… so I think I am about 95% of the way there!

2 Likes

So I created a new post that pretty much goes step by step on how to get bermuda working. I am 95% there like I mentioned before, now just having issues adding a 2nd device.

Here is the link Private BLE Device for use with Bermuda BLE Trilateration (and others I guess)

@agittins I invite you to read over my post, then when you get a chance give me some more pointers there…

Again THANK YOU THANK YOU!

1 Like

Awesome, I’ll definitely give it a good read over, and will probably link to it from the guides section of the wiki.

Great feedback, thanks!

Yeah i was refering to IRK (= Private BLE). Will try to set it up.
For my garmin watch, theres no beacon app , very pity. Guess im stuck there…
Although i’m thinking to auto disconnect bluetooth on smartphone when i’m home, and auto connect once im out. I think that wont bother me.+ if the watch sensor is alive, report it, if not use the phone… (in case i do use BT at some time)

ok about the pi…
Will try to make it work first how i’ve it up now…
Cause i added an extra plug (scanner).

BUT , both my plugs arent picking up the smartphone all the time, its very strange…

I get this now

Bermuda can currently see 0 active of 28 bluetooth devices, reported across 0 active of 3 bluetooth scanner devices. No bluetooth devices are actively being reported from your scanners. You will need to solve this before Bermuda can be of much help.

I’m 1m away from a scanner lol
nothing…

Still using your yaml… I also see one plug (the first one i tried) has an update… can i click this or will it overwrite your yaml?

It completely stopped working here

Updating failed with this:

 It fails with the following output:

    Change Dir: /data/build/woonkamer-plug/.pioenvs/woonkamer-plug/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_90a15 && [1/2] Building C object CMakeFiles/cmTC_90a15.dir/testCCompiler.c.obj
    FAILED: CMakeFiles/cmTC_90a15.dir/testCCompiler.c.obj 
    /data/cache/platformio/packages/toolchain-riscv32-esp/bin/riscv32-esp-elf-gcc   -march=rv32imc -o CMakeFiles/cmTC_90a15.dir/testCCompiler.c.obj   -c testCCompiler.c
    riscv32-esp-elf-gcc: error: testCCompiler.c: No such file or directory
    riscv32-esp-elf-gcc: fatal error: no input files
    compilation terminated.
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:381 (__project)
  CMakeLists.txt:3 (project)

After clicking message away, he doesnt say he needs an update anymore, strange

@agittins I’ve read the wiki

I have decided to keep all my proxies “seen” by keeping them as “devices” (Config>select devices)

I don’t know… call me weird I don;t care… I just like to “see” what’s going on with Bluetooth

Case in point.

I have a proxy in a room (I set the named area Bedroom)
It was in there with another two proxies
It was always listing it’s “Bermuda” location as (eye symbol) area = Bedroom ↔ Distance = 2.1m

Then I swapped in/out couple of Shelly devices in that room (for my own “Shelly” reasons)
I didn’t change anything on that other proxies yaml
Well blow me down, now that proxy “thinks” it is in the Family Room like 15 meters away, when I
darn well know it;s in the Bedroom (and I aint changed its location!)
Its Bermuda location now swaps between Unknown and Family Room 15m away!

I know you say you don’t have to actually “add proxies that you are giving fixed locations to” in the integration (for it all to work)

But from a practical understanding point of view it sure helps watching what’s going on!

Few more questions

1/ Why would this proxy change it’s location like it did?
From being in a location 2m near another two proxies - to 15m away…
Seems rather weird…
(Both the Shelly’s were configured exactly the same in the Shelly BT config page of the app)

2/ Is there a specific way to “reboot” the entire Bermuda integration? …so previous history of a device starts from scratch and each device sets it’s “Bermuda location” based on whats’ nearby afresh? … or does building a Bermuda set up become like adding zigbee devices… building a mesh so to speak…“trial and error”?

3/how long before we get trilateralisation so we can “set and nail down” specific proxies to a location?

Thanks!

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. :slight_smile:

3 Likes

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 :slight_smile:

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 :slight_smile:

Setting the area setting in HA for a proxy is nailing it down to a single area.

2 Likes

Great!

Not great! :frowning: 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 :person_shrugging:

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 :slight_smile:

1 Like

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) :slightly_smiling_face:

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. :smiley: 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”… :slightly_smiling_face: 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