Does bermuda ignore iBeacons with same MAC?

[eigenphase]

I have a few Blue Charm BC04P trackers, by default they all have UUID 1B6295D5-4F74-4C58-A2D8-CD83CA26BDF4, Major 3838 and Minor 4949.
I have changed the Minor to be unique (1,2,3).

Now this beacon also has a movement sensor which temporarily advertises under a different UUID when motion occured. Specifically, it just adds 1 to its UUID (see https://bluecharmbeacons.com/bc04p-beacon-deep-dive-into-the-details).

With the iBeacon integration, a second beacon started popping up on movement.

In Bermuda, I would expect a new iBeacon with UUID 1B6295D5-4F74-4C58-A2D8-CD83CA26BDF5, Major 3838 and Minor 1 to show up temporarily. But it doesn't. In fact, the original iBeacon keeps updating even though motion occured.

This makes me wonder: Since the MAC stays the same, does bermuda ignore the different UUID and still treat it as the same beacon?

If not, what else could be the issue?

[agittins]

Howdy! If you include a diagnostics where both UUIDs have been seen in the last few seconds I'll be able to see exactly what's happening in your system, but generally speaking:

• if you add the device to Bermuda using the MAC address (rather than the iBeacon UUID) then you'll get a single "device" that responds whenever anything (regardless of uuid) is seen coming from that MAC address. For a bluecharm, this should result in consistent tracking for both movement and still modes.
• Bermuda does have specific support built-in for Bluecharm's movement tracking, in that if a beacon changes its UUID (but uses the same MAC address), Bermuda immediately "unknown"'s the previous UUID's device. The idea is that you set up both iBeacon entries (the still one and the moving one) and Bermuda will quickly trigger one or the other, giving you the ability to tell if a pet is on the move or chilling. Downside is that without knowing that (and I have a feeling I haven't documented it properly yet 😬 ) you'd just seen the beacon goingunknown every time it moved.

So if you'd like just a simple non-motion aware tracker, have bermuda watch the MAC address, but if you want to leverage the movement information, you can add both iBeacon UUIDs to Bermuda, and group them for an overview and use the movement one in particular for "they're on the move!" automations.

That said, my memory might be faulty on this, and also as I don't own any Bluecharm devices, the support might have broken or changed over the last few versions inadvertently, so let me know if this doesn't match up with your observations! 😅

[eigenphase]

Great, thanks for confirming. So I would definitely want both devices in Bermuda but it just won't show up (they appeared in iBeacon though).

This is an example where movement sensor triggered and it can be seen that the iBeacon integration beacon is active for UUID 1B6295D5-4F74-4C58-A2D8-CD83CA26BDF5:

Interestingly though the iBeacon integration could be buggy because the "Estimated Distance" updated for both the triggered and non triggered entities. But I want to get rid of iBeacon integration anyway ...

But, now, you can see here that they just don't show up, I can't add them to bermuda!!

To make things just a bit more crazy, 1B6295D5-4F74-4C58-A2D8-CD83CA26BDF5, Major 3838 and Minor 3 randomly showed up and I was able to add it. But Minor 1 and 2 don't.

If you include a diagnostics where both UUIDs have been seen in the last few seconds I'll be able to see exactly what's happening in your system,

This would be very appreciated!
Is there a way to provide you with this file directly? It seems to have a lot of private data in it and it wouldn't be relevant for other people either.

[eigenphase]

I went out and activated motion sensor again and all of a sudden all showed up!

I swear, I tried this multiple times yesterday and they didn't show up!

[eigenphase]

But seriously, now I have the opposite issue that the triggered entities keep getting updated while the normal ones get Unknown.
I have set the trigger advertisement duration to just 30 seconds and sensitivity is lowest, there is no way that these beacons are still sending the triggered UUID.

This must be a bug. Can it be some weird caching issue?

Lo and behold, once I reload the bermuda integration, things work again.

This is after the bermuda integration reload and nothing triggered:

Now I activate the motion trigger by shaking it and after waiting well over a a few minutes still both "Trashcan Black" and "Trashcan Black Trig" get updated in tandem; they always share exactly the same "Last Updated" value:

Then, again I reload the integration and all is normal again:

[agittins]

The diagnostics shouldn't have any personal info, except for the device and area names, which might be a concern. You can attach here or if you prefer feel free to email it to me - ash@ajg.net.au

Also really helpful is to use the History feature in HA to show the timeline of status changes etc, like this:

Easiest way is to trim down the reported range to cover a range of maybe 20 mins to an hour, and use the green "select device" to add the trash can devices, that way it will show all the sensors for those devices - particularly useful are the "area" sensors.

If you could provide the diagnostics after things get "stuck" where both devices are being updated, that will probably be the most helpful, but you could also include diags at other times along the process, as the diags only includes the current state and only 10 to 30 seconds worth of history.

It's quite possible that the feature is buggy, as I don't have any bluecharms and I haven't worked out how to create tests for that sort of thing (PSA: If anyone has tips on how to set up the testing to support this sort of state checking I'd love your input!)

That's weird that the devices weren't showing up in Bermuda's drop-down list. I assume they weren't already selected?

[eigenphase]

Thank you, I really appreciate your help!!

I meanwhile have done lots of research, was also in contact with the CTO of Blue Charms and I believe I found the culprit for both issues that I reported above, and, which unfortunately makes these beacons unusable with Bermuda: It seems that iBeacons are tracked per MAC address and not the triple (UUID, Major, Minor).

I am trying to look into this myself, I checked out the git source already but I need to get an overview of the codebase. But, I am hoping, maybe we can discuss this first and, if needed, support me a bit in case I am doing a patch.

Let me revisit the problem statement

A single device with MAC 4C:75:25:CD:A5:5A advertises two iBeacons (not at the same time though): The first is (1b6295d5-4f74-4c58-a2d8-cd83ca26bdf4, 3838, 1) and the second one is (1b6295d5-4f74-4c58-a2d8-cd83ca26bdf5, 3838, 1). The second one will only be advertised for 30 seconds when the beacon's motion sensor triggers.

Naturally, we want the iBeacon (1b6295d5-4f74-4c58-a2d8-cd83ca26bdf5, 3838, 1) to become "Unknown" when no further advertisements are received.

What happens

The beacon (1b6295d5-4f74-4c58-a2d8-cd83ca26bdf5, 3838, 1) keeps receiving updates, even hours after its last advertisement was received. This is because the beacon (1b6295d5-4f74-4c58-a2d8-cd83ca26bdf4, 3838, 1) received advertisements. In fact, both iBeacons receive updates. This is most likely because an iBeacon is referenced using the MAC address as opposed to its (UUID, Major, Minor) Triple.

My assumption is that whenever a new advertisement comes in, we iterate over all beacons and check which MAC address matches the received beacon and update RSSI data. However, if the advertisement comes from an iBeacon, we should ignore the MAC address and only find the entry that matches (UUID, Major, Minor).

Why this breaks these beacons

The purpose of these beacons (like BlueCharm BC04P) is to detect a motion event via its motion sensor. If the "triggered" iBeacon entry stays active indefinitely in Bermuda, no further triggers can ever be detected.

I should note that the iBeacon integration has exactly the same issue and I already filed a bug report. However, I am pretty invested in Bermuda and would like to get rid of the iBeacon integration (even if it were to get fixed there).

What I am looking for

I am trying to find the code section where Bermuda receives BLE advertisements and then updates its trackers. I would like to confirm that my suspicion is correct and if so, try to change the code that handles iBeacons differently, in particular, matches (UUID, Major, Minor).

[agittins]

What you are describing as the bluecharm feature is certainly how it's meant to be working in Bermuda, and I haven't had reports of a regression from the other users already using it this way - so it might be a bug and those other users no longer use Bermuda, or it might be a config or environmental issue in your system. I can't tell because your description isn't as detailed as a diagnostics, so I can't get all the details of your setup.

Anyway, to give you some broad overview of how the Bermuda internals work in this area:

Bermuda has things it considers "devices".

• Most devices are "normal" and are identified uniquely by a MAC address.
• Some devices are "metadevices". These are identified by something that is not a MAC address:
  • ibeacons are metadevices identified by the uuid_major_minor hex string
  • IRK (Private BLE Devices) are identified by the hex representation of the key
  • Future metadevices will include aggregate devices, string-matching devices etc.

Scanners (proxies) are also normal devices but have additional properties.

HA receives advertisements from "normal" devices, via proxies. Bermuda updates the normal device with the advertisement data from each scanner, keyed by scanner MAC and source device MAC. To Bermuda, an advertisement ties a scanner "device" to a normal device (ie, not a metadevice).

Bermuda looks at all "normal" devices, and decides if any of them are providing information that is relevant to a metadevice. If so, it updates the metadevice property metadevice_sources and copies the scanner:device advertisements to that metadevice. It is at this step that Bermuda will perform bluecharm-specific steps to clear the existing metadevice_sources if the uuid from a source device no longer matches the metadevice's uuid.

Take a look at the diagnostics in the devices tree to see the structure that Bermuda builds and works with. You can view a non-redacted presentation of it via the bermuda.dump_devices action.

If you search the bermuda code for "bluecharm" you'll find the specific bit where it does the special case processing.

Just a heads-up that I don't have the bandwidth to accept LLM-generated patches unless they've already been hand-reviewed for function and smell - indeed it was this feature which first exposed me to the time-wasting, soul-destroying horror of reviewing vibe-coded vomit that wasn't even tested by the submitter, and it completely destroyed my motivation to work on Bermuda for weeks.

Also note that I am not going to accept a patch without the evidence I need to confirm and reproduce the bug - but you may well gather that data as you work toward finding a solution.

Some further reading that might be helpful:

#586 - fixing a regression for the bluecharm support
#236 initial support for the bluecharm beacon uuid changes.

but please, do this FIRST:

Please send me a diagnostics. I spend hours explaining the inner workings of bermuda to help people troubleshoot, but so often it's something I could have spotted in 30 seconds of looking at a diagnostics. Especially when it comes to bug reports (which this is, since this is a supported feature that isn't working right, but ONLY on your system, as far as we know - since other people are using bluecharm's motion feature and they haven;t yet reported a regression).

[eigenphase]

One more debug session. I now added debug statements for the loops through metadevices and sources in update_metadevices.

This is how a normal output (repeated many times a second) looks like (I removed all devices except the ones in question for readability):

�[36m2025-10-13 21:06:30.533 DEBUG (MainThread) [custom_components.bermuda] LOOPING through metadevices; metadevice=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:30.533 DEBUG (MainThread) [custom_components.bermuda]   LOOPING through sources; source=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m

Question 1: What bugs me is that the source of the metadevice points to the metadevice itself. Is this intended?

Then I shake the beacon and this is the output:

�[36m2025-10-13 21:06:32.531 DEBUG (MainThread) [custom_components.bermuda] BermudaDevice::process_advertisement() scanner=4c:75:25:cd:a5:5a, device=dd:34:02:0b:19:fc, manufacturer_data={76: '02151b6295d54f744c58a2d8cd83ca26bdf50efe0001c9'}�[0m
�[36m2025-10-13 21:06:32.533 DEBUG (MainThread) [custom_components.bermuda] LOOPING through metadevices; metadevice=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:32.533 DEBUG (MainThread) [custom_components.bermuda]   LOOPING through sources; source=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:32.536 DEBUG (MainThread) [custom_components.bermuda] LOOPING through metadevices; metadevice=1b6295d54f744c58a2d8cd83ca26bdf5_3838_1�[0m
�[36m2025-10-13 21:06:32.536 DEBUG (MainThread) [custom_components.bermuda]   LOOPING through sources; source=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:32.537 DEBUG (MainThread) [custom_components.bermuda] Source Trashcan Black [dd:34:02:0b:19:fc] for metadev bermuda_1b6295d54f744c58a2d8cd83ca26bdf5_3838_1 [1b6295d54f744c58a2d8cd83ca26bdf5_3838_1] changed iBeacon identifiers, severing�[0m
�[36m2025-10-13 21:06:32.537 DEBUG (MainThread) [custom_components.bermuda]       metadevice.beacon_unique_id=1b6295d54f744c58a2d8cd83ca26bdf5_3838_1�[0m
�[36m2025-10-13 21:06:32.537 DEBUG (MainThread) [custom_components.bermuda]    source_device.beacon_unique_id=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:32.540 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.011 seconds (success: True)�[0m

Observations:

1. The original metadevice (1b6295d54f744c58a2d8cd83ca26bdf4_3838_1) is completely ignored. This is because metadevice.beacon_unique_id != source_device.beacon_unique_id does not evaluate to true
2. The new metadevice (1b6295d54f744c58a2d8cd83ca26bdf5_3838_1) is already in the metadevices list and it has as its source pointing to the old device. This matches now
3. Now the code removes source device of the NEW device, not the old one

Couple of seconds later:

�[36m2025-10-13 21:06:35.531 DEBUG (MainThread) [custom_components.bermuda] LOOPING through metadevices; metadevice=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:35.531 DEBUG (MainThread) [custom_components.bermuda]   LOOPING through sources; source=1b6295d54f744c58a2d8cd83ca26bdf4_3838_1�[0m
�[36m2025-10-13 21:06:35.531 DEBUG (MainThread) [custom_components.bermuda] LOOPING through metadevices; metadevice=1b6295d54f744c58a2d8cd83ca26bdf5_3838_1�[0m

Observations:

1. The original meta device is still unchanged, hence it keeps getting tracked
2. The new device has no source device any more

Hypothesis: Shouldn't the source device be a MAC only device and not a metadevice (iBeacon)? I think this is the root issue.

[agittins]

Off the top of my head, yes if the metadevice has a source_metadevice of itself that does sound like a bug.

Can you send me a diff of your modifications so I can work out exactly where your debug messages are coming from, and what they're reporting?

[eigenphase]

Great, thanks!!

Here's the diff:

diff --color -urN bermuda-orig/custom_components/bermuda/bermuda_device.py config/custom_components/bermuda/bermuda_device.py
--- bermuda-orig/custom_components/bermuda/bermuda_device.py    2025-10-14 14:27:07.750672301 -0700
+++ config/custom_components/bermuda/bermuda_device.py  2025-10-13 00:41:18.756228138 -0700
@@ -739,6 +739,13 @@
                 self.options,
                 scanner_device,
             )
+        
+        if device_address == "dd:34:02:0b:19:fc":
+            mfr_str = {
+                mfr_id: data.hex()
+                for mfr_id, data in advertisementdata.manufacturer_data.items()
+            }
+            _LOGGER.debug("BermudaDevice::process_advertisement() scanner=%s, device=%s, manufacturer_data=%s", scanner_address, device_address, mfr_str)
 
         # Let's see if we should update our last_seen based on this...
         if device_advert.stamp is not None and self.last_seen < device_advert.stamp:
diff --color -urN bermuda-orig/custom_components/bermuda/coordinator.py config/custom_components/bermuda/coordinator.py
--- bermuda-orig/custom_components/bermuda/coordinator.py       2025-10-14 14:27:07.752672339 -0700
+++ config/custom_components/bermuda/coordinator.py     2025-10-13 21:49:09.652074191 -0700
@@ -1096,6 +1096,8 @@
         for metadevice in self.metadevices.values():
             # Find every known source device and copy their adverts in.
 
+            _LOGGER.debug("LOOPING through metadevices; metadevice=%s", metadevice.beacon_unique_id)
+
             # Keep track of whether we want to recalculate the name fields at the end.
             _want_name_update = False
             _sources_to_remove = []
@@ -1105,15 +1107,18 @@
                 # TODO: Verify it's OK to not create here. Problem is that if we do create,
                 # it causes a binge/purge cycle during pruning since it has no adverts on it.
                 source_device = self._get_device(source_address)
+
+                _LOGGER.debug("  LOOPING through sources; source=%s", source_device.beacon_unique_id)
+
                 if source_device is None:
                     # No ads current in the backend for this one. Not an issue, the mac might be old
                     # or now showing up yet.
-                    # _LOGGER_SPAM_LESS.debug(
-                    #     f"metaNoAdsFor_{metadevice.address}_{source_address}",
-                    #     "Metadevice %s: no adverts for source MAC %s found during update_metadevices",
-                    #     metadevice.__repr__(),
-                    #     source_address,
-                    # )
+                    _LOGGER_SPAM_LESS.debug(
+                        f"metaNoAdsFor_{metadevice.address}_{source_address}",
+                        "Metadevice %s: no adverts for source MAC %s found during update_metadevices",
+                        metadevice.__repr__(),
+                        source_address,
+                    )
                     continue
 
                 if (
@@ -1137,6 +1142,8 @@
                     _LOGGER.debug(
                         "Source %s for metadev %s changed iBeacon identifiers, severing", source_device, metadevice
                     )
+                    _LOGGER.debug("      metadevice.beacon_unique_id=%s", metadevice.beacon_unique_id)
+                    _LOGGER.debug("   source_device.beacon_unique_id=%s", source_device.beacon_unique_id)
                     for key_address, key_scanner in list(metadevice.adverts):
                         if key_address == source_device.address:
                             del metadevice.adverts[(key_address, key_scanner)]

[eigenphase]

Hi @agittins, did you already get the chance to have a look?

[eigenphase]

One more kind nudge, @agittins .
If you're busy I stop bugging but I'm hoping you have some feedback ... I am really up for debugging this but right now I don't really know where I could look at.