#Beacon secondary UUID never goes "away"

1 messages · Page 1 of 1 (latest)

boreal bloom
#

I'm using Blue Charm BC021's with the iBeacon integration. Goal is to have one device that can tell me the bins are at the curb and when they've been picked up.

The problem I'm running into is that the modified UUID address (hex +1) of my two beacons never goes "away", and seems to update roughly in line with the main unmodified UUID. The beacons have been sitting perfectly still on a counter top, right next to a Shelly 1PM bluetooth proxy for about 60 minutes, yet my modified UUID movement sensor entities keep updating their estimated distance, thus preventing them from going to away mode. The troubleshooting I've done so far consists of deleting them all out of HA, using the kbeacon app to modify the UUID/major/minor of my second beacon, readding them and restarting the ibeacon integration. My first sensor UUID ends in 3, movement ends in 4 (default settings), second sensor ends in 5, movement ends in 6. I left the default major/minor of 3838/4949 on the first sensor but changed the second sensor (UUID 5/6) to 3939/5050. I did this because the HA docs had a limit of 5 devices for devices with the same UUID/major/minor combo. I have the sensitivity set to 30 on both of them. I've verified in the kbeacon app that they don't appear to be broadcasting the modified UUID when they are still, so I'm not sure what to think aside from HA might be tying their MAC's together somehow and updating the modified UUID because the main UUID was updated during a broadcast.

Thomas @ Blue Charm seems to think it's a cache issue either with my proxies (Shelly gen 2/ESP32S/m5 stack atom lite) or in HA/the integration.

Some other settings:
Trigger adv mode always enable
Trigger adv type ibeacon
Adv time/interval 60/400
Button trigger off
All other settings default