iBeacon Tracker IDs change every Time

Configuration
1

Hey there,

I have set up a BT test system using an ESP32.
I set it up with ESPHome and enabled bluetooth_proxy and esp32_ble_tracker on the device to make sure it will forward all BLE beacon transmitter signals it receives to HA.

Additionally I activated the iBeacon Tracker integration on my HA installation.

When I now enable the BLE-Transmitter in my mobile app, the iBeacon Tracker recognizes the device and automatically adds it. So far, so good.

But there is a major problem with this: Every time I enable the transmission on my phone, the integration creates a new device because the id changes. Most of the id stays the same: UUID_Major_Minor but there is always added a blank space and a four digit Hex-String. Why is this? This way I cannot create an automation with the device.

Thanks in advance!

1 Like
2

Mine was doing this yesterday, until I updated to 2022.10.1 and so far that seems to have stopped it. Now instead of getting a UUID constantly changing in the list, I have something that looks more like a MAC address and the UUID is available in the attributes. The entity name is still the uuid + major + minor though: device_tracker.9036c424_42b9_4dc4_8cc7_cd2e48c8873c_100_1 This has now been visible since 7pm yesterday. On 2022.10.0 this was instead showing up as a new (different) iBeacon roughly every 20 minutes.

3

I am on 2022.10.1
The MAC address is not reported at all. Not even in the attributes.
Very frustrating.

4

On mine, the iBeacon Tracker integration device list is showing the name of the BLE device. For iBeacons, this works great, but for other BLE things that don’t have names, it might be substituting some other data for the name.

I have not clicked through to see if the uuid is listed, plus I am not using an ESP to gather the BLE device info, so my case may be different from yours.

I get the feeling that the new iBeacon Tracker integration is trying to make things more user friendly by focusing on beacon names rather than long strings of uuid. That said, in the background, I assume the integration is not scanning for beacon name, but rather is scanning for uuid-major-minor. So everyone will need to be sure their iBeacons have unique names AND unique minors (at least).

Imgur

Edit: I just looked at my image and saw the 4 mysterious hex characters you mentioned that added to the end of the beacon name! No idea what those are. I don’t think they are the MAC. In my testing, these don’t seem to have any effect.

Another thing you can try: click on the three dot menu on the tracker integration and turn off the “add new BLE items automatically” setting. (Wording might be slightly different)

Edit 2: Just checked my HA device list and compared the target beacon name. The name showing on the device list is the iBeacon’s name (on my image above, the first one is named BlueCharm_134735) and four hex numbers are the last four digits of that beacon’s MAC.

Edit 3 :roll_eyes:: check the documentation. It says “ iBeacons with a randomized MAC address will be combined into a single set of entities once the integration discovers the same UUID, Major, and Minor combination has been seen coming from 10 or more MAC addresses. This allows distance and presence detection based on the last reporting data. When using randomized MAC addresses, only one device must broadcast the unique UUID, Major, and Minor combination.”

It sounds like you should just let the integration collect device info for a while until it sees your phone app uuid/major/minor repeated ten times with different MAC addresses. Then it will conclude that your device is a phone with randomized MAC, and then will only pay attention to the uuid/major/minor for that device. So please ignore my earlier advice to turn off the “automatically add new devices” setting. You need to leave that on until the integration collects ten different MACs from your phone.

5

Same issue here. HA 2022.10.1

6

Ah! I missed that, that makes sense!

As I say - this is how mine looks:

image
image1047Ă—1055 70.3 KB

7

Actually, after finding 7/8 times my phone, HA cleanded up all beacons itself and my phone was shown with one single beacon

8

so is the Home Assistant integration able to do what (correct me if I’m wrong @andrewjfreyer) monitor.sh can’t do and track iPhones with their randomised MAC addresses?

Weirdly my HA Pi this morning decided to ask if I wanted to track bluetooth beacons and I added the integration but it’s yet to actually discover any beacons, and I know for sure there is one it should be picking up on because Monitor.sh is successfully tracking it.

Actually, looking at the debug logs from the integration, I CAN see my ibeacon tag is appearing, so maybe it’s just waiting for it to appear x number of times??

2023-03-31 10:15:43.975 DEBUG (MainThread) [bleak.backends.bluezdbus.manager] received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_HR_21_FA_33_A1_25): ['org.bluez.Device1', {'RSSI': <dbus_fast.signature.Variant ('n', -85)>, 'AdvertisingFlags': <dbus_fast.signature.Variant ('ay', bytearray(b'\x00'))>}, []]

(mac address anonymised)

9

I’m not the code owner of HA’s BLE tracker, but I personally have found that beacon tracking is a very unreliable presence sensor. Neither monitor nor presence depend on beacon advertisement for phones or BT classic devices.

To correct one thing, your phone sends randomized mac addresses only in certain circumstances. Most of the hay about randomization is the (static) hardware MAC address. They used to be sequential with WIFI MAC addresses, which was a pretty big security concern.

monitor and presence still work just fine with iOS 16 beta 5 and the most modern iPhones.

It will continue to work unless Apple drops support for Bluetooth Classic.

10

thanks for this - but I’m right in thinking monitor wouldn’t work with my iPhone X on iOS 16.1 ?

11

Yes, it works just fine. You’ll have to manually enter the bluetooth mac address from Settings > Gen > About, and it’s likely that you’ll have to connect to at least one bluetooth classic device at least once. Else, your phone will default to disable support for BT classic AT commands (that monitor relies on).

I had an iPhone X for a long time, monitor worked just fine. I currently have a 13 and a 12 both with dev betas of iOS 16 working on a daily basis.