core: iBeacon never changes from "home" regardless if kilometers away or battery off.

I keep on updating both HA and ESPHome and the problem never gets fixed. It is so easy to reproduce. You have a beacon, it is reported home and within a few meters. You move it away a bit and it may say 5 meters. Then you either take it completely away or remove its battery and it continues as 5 meters and the device_tracker entity stays Home. Always Home.

If I restart Home Assistant with the battery removed from the beacon then it is reported Not Available but the device is still there. That is also wrong. A known device with a device_tracker entity should be reported Away. The whole idea of a device tracker like an iBeacon is that you can use it to detect that someone or something is home.

It seems the integration totally fails to time out when a beacon is not announced within a reasonable time. We can argue about the time. Should it be 1 minute or 5 minutes. But surely we all agree that hour or days is no good.

Please add a timeout that turns the device tracker from Home to Away after 1-5 minutes of no reception of it.

And please maintain Away after a HA restart.

And please do not forget to have a means to delete a device at device level that has been seen but you do not want to stay in HA.

finally the distance attribute should have a value for infinite when the beacon is gone. It just reports the last distance forever which is bogus. And 0 is not a right default for away. I can move fast enough out of my home to leave a 1 m distance forever. That is no good.

I have written my own software that reports the same beacons in 4 other ESP32s and they report presence flawlessly via MQTT and I am a hopeless programmer. I simply report a beacon “Away” when I have not seen it for about a minute. I do not use distance as I found that too dependent on keys in pocket etc.

As far as I can tell no actions have been made to address this. Go away bot

I have never seen an “away” state for the device_tracker entity, only reports “home”.

I had to give up on the HA bluetooth completely.

The most basic use I have is to put an iBeacon in the pocket of my coat and have HA detect when I come home and when I leave. I cannot be more basic than that. And I had no problem getiing my iBeacons detected.

The problem is when I leave the house the device tracker remains home for the entire day. I could live with a time out of minutes. Even half an hour could be good enough.

I never understood why @bdraco removed himself from this bug report. Did we say something wrong?

Not a direct solution yet for iBeacon, but I’ve written an integration ( Bermuda ) which is reasonably reliable now at providing a home/not_home indication for MAC Addresses of BLE devices. That is, it doesn’t yet do anything smart about beacon’s UUID (or the rotating mac addresses of iphones etc) but if you want to automate against the location of a static ble mac address, it’s working fairly well. Note that it only really works with ble_proxies, because the BlueZ stack for locally-attached bluetooth dongles doesn’t log timestamps for advertisements - which might be part of the core problem of this bug. It also provides sensors for what Area the device is in, if you have enough proxies to make that meaningful. Support for iBeacon UUIDs is planned but not done yet.

For those wanting to persist, perhaps try using some ble proxies and disable the local dongle to see if you get away statuses working - it could be the stale info from BlueZ that is persisting and causing the issue.

I’m using bt dongle on extender cable on rpi3 and the beacon is feasybeacon triangle. I can add the same as ibeacon to ble_monitor hacs custom component and it works as expected, but I was trying to migrate to native integration. I useb the native iBecaon for a day where I went to work and back and the sensor never changed from home since it was added.

@hugalafutro are you saying that if I use this HACS integration instead of the native one my iBeacon will work marking home and away as it should?

Assuming that is whats going on @BlueCharmBeacons, what is an ideal fix? An integration-wide config variable to disable consolidating beacons with different UUIDs but the same MACs? An entity-level variable to treat entities with this MAC as distinct beacons? What are other better imagined solutions?

I’m still not 100% sure that’s the source of the problem. One reason I’m not sure is that I remember the coder explaining that the HA waits until it sees 10 different uuids from the same MAC before the HA concludes that it’s just one piece of hardware with randomized uuids. So in your case, it shouldn’t be doing that since you don’t have ten different uuids.

But if my guess is actually correct, then either one of your suggestions would work. I think it would be up to the coder to decide which one would be easier to implement.

Have you tried using the iBeacon Tracker integration for these specific automations? That was the integration where I read about the randomized uuid thing requiring ten different uuids. Maybe that integration would work for you since you are only using three uuids with the same MAC.

Edit: Oops, I just realized this thread is all about iBeacon Tracker, so probably you are already using that one.

Edit2: For what it’s worth, I just replicated your issue, so it’s not just you.

Edit3: I thought this (see below) would work for sure, and even changed the button trigger broadcast time from 60 seconds to 4 minutes, but no luck. It doesn’t work.

Not being able to automate from the button pushes is a bummer. I’m not sure if what’s going on there is something within the integration, the beacon, or unique to me 🤷‍♂️

My guess is that this is related to the feature that was included recently in HA to handle phones that switch UUID’s but keep the same mac. After the HA sees the same MAC broadcasting different uuids, it eventually concludes that these uuids are all the same piece of hardware and thus consolidates them as one single item.

In your case, when the HA sees the regular uuid at home, it also considers the other two alternative uuids to be at home. So when you trigger them with button pushes, the HA sees no change of state, and does nothing.

In the same way, when you power off the beacon, the HA eventually notices that the main uuid is away, reports its state as away, and also concludes that the other two uuids are also away.

Further, when you power on the beacon, the HA will conclude that all three uuids are now at home.

That’s just my speculation, since I don’t have access to this code. But it is an expected behavior that has been mentioned a lot recently re the iBeacon Tracker integration. I guess you could say they solved one problem but created another.

I wonder how ESPresence handles different uuids from a single beacon? Maybe it would handle it properly.

It looks like no one wants to or can deal with the problem. Too bad, there is no point in this integration, I will have to continue to get out of the situation with the sensors on esp.