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

[hugalafutro]

The problem

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

What version of Home Assistant Core has the issue?

Home Assistant 2022.10.1

What was the last working version of Home Assistant Core?

Never worked properly

What type of installation are you running?

Home Assistant Container

Integration causing the issue

iBeacon

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ibeacon/

Diagnostics information

none provided by integration

Example YAML snippet

n/a

Anything in the logs that might be useful for us?

no

Additional information

no

[homeassistant]

Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (ibeacon) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

---

ibeacon documentation
ibeacon source
_{^{(message by IssueLinks)}}

[ih8gates]

I'm experiencing the same. I have several Blue Charm BC08 beacons. They advertise a second beacon (for a configurable time) when they sense motion. The motion beacon has it's own UUID. Room Assistant (reporting to Home Assistant via MQTT) sees these motion beacons come and go as expected, but they never turn to "not_home" in the iBeacon integration. Additionally, the estimated distance sensor continues to update.

The only time I've had one of the motion beacons turn to "not_home" is when I've taken them physically far away from my home. The other ones I have are attached to large objects (trash cans, etc), so it's not easy for me to get them out of range.

@hugalafutro Are you using a ESP32 Bluetooth Proxy? I am, but I'm turning it off this morning to see if that's truly the root of the problem. My proxy is shown as the source for the "home" state on my motion beacons.

[hugalafutro]

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.

[ih8gates]

Disabling the ESP32 proxy didn't fix things for me. I'm still seeing a permanent "home" with the bluetooth adapter on my Home Assistant Blue listed as the source.

[mrjackson]

I'm also having this issue with a BC011. It does seem to re-set the Home status when I return, so it's almost working.
I'm using an ESP32 as a BT Proxy, no other adapters.

[KennethLavrsen]

I installed a BLE Proxy (Olimex ESP32) and added the iBeacon integration.

Like the reports above the iBeacons are added and when they are home they are tracked.

But when the iBeacons leave our house (kilometers away) the iBeacon device tracker continues reporting them Home.

The whole point of having an iBeacon in the keyring is to have an extra detection (beyond the app on the phone) that we are home or out.

I already had some other ESP32s on which I run my own homebrewed BLE software which reports when they see the iBeacon via MQTT. And that works 100% reliable.

There is not really anything I can be doing wrong. When an iBeacon goes out of range it is out of range. The device tracker entiry should report the beacon not home after a reasonable time out period (I use 30 seconds in my own code because my beacons sends their periodic message a little faster than that - 1-2 minutes would also be quite OK).

It seems the device_tracker has not implemented any feature related to not receiving a signal any longer

I can also confirm that the distance reports is mostly 0 meters even though the beacon is in my coat pocket in the entrance and my proxy is in the living room 4 meters away with a cement wall between. But that feature I never expected to be accurate because it is so random how a 2.4 GHz propagates indoors. But is is odd that it reports 0 meters because that would requires a huge signal. But that bug must be more in the ESPHome implementation. I assume the device_tracker part is in the HA Integration and should be based on seeing or not seeing the individual beacons. And it seems it lacks the code to time out when it does not get a signal reported.

[NotSteveAtGithub]

Agree with @KennethLavrsen's assessment. I'm using BC08 attached to my mailbox door which is about 300ft from my house. I'm bridging the distance with a ESPHome Bluetooth proxy which works beautifully.

I have the BC08 configured to broadcast a different UUID for 30 seconds after motion, but regardless of what I do, HA continues to show it both UUIDs "Home" pretty much permanently. I've verified using a phone app that the beacon is behaving exactly as I've configured it to behave; the secondary UUID goes away in 30 secondes. The key seems to be modifying the device_tracker portion to time out and mark it away.

(As an aside, thanks to all responsible for these Bluetooth-related features because they're helping solve a bunch of problems I never could before.)

[mrjackson]

Mine seems to be working now, I'm not really sure what I did but I have updated HA to current and changed the ESPHome config to the below.

esp32_ble_tracker:
scan_parameters:
interval: 320ms
window: 30ms
active: true
bluetooth_proxy:
active: true

[hugalafutro]

I would like to say I do not use any esp32 in my config, the issue happens with regular bluetooth dongle, so any possible fix/workaround involving esp32 as mentioned above sadly cannot do anything for me.

Does anyone know if #81740 have any bearing on this by any chance? I switched back to the Passive BLE monitor and rather would not experiment with the native bt until fixed.

[KennethLavrsen]

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.

[avbor]

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.

[avbor]

ESPHome 2022.12, HA 2022.12.5 - issue is still here:


@bdraco ?

[BlueCharmBeacons]

Is this still an issue for some people?

I also had trouble getting it to work, but I had no problem triggering automations based on RSSI strength...which is strange. So I spent the afternoon and evening yesterday fiddling with it, and I think I figured it out.

So far, I am getting notifications on IFTTT regularly when the beacon is turned on or off (simulating that the beacon has left the home or come back home).

The big "discovery" for me was using a State trigger instead of what I was using before (I tried everything else...lol!)

Here's an example:

Here's the logbook showing examples of me turning it on and off:

When the beacon leaves home (i.e. I turn it off), sometimes the HA logs it (and sends a notification to my phone) quickly, but sometimes it takes up to 3-4 minutes. When the beacon returns home (i.e. I turn it on), the HA seems to log that much faster; sometimes within 1 second even.

I know this might not be a true test because I am not physically moving away from the HA with the beacon, but I think that should not matter. Just to confirm, I will try to physically carry it away tomorrow to see if it continues to work properly. Update: moving the beacon away from or coming closer to the HA works the same as turning off or on the beacon.

Edit: There is a problem if the beacon is away, then I restart the HA, and next the beacon comes home. The logbook then shows that the HA recognizes that the beacon is now home, BUT the HA doesn't seem to realize there has been a state change, so it does not trigger the automation. Remember, my automation is based on a State CHANGE. My guess is that the HA assumes the beacon is home after a restart, even if the beacon was away before the restart and even if the HA can not even see the beacon after the restart. Soooo, that's still an issue to be fixed.

[danblah]

Testing on 2023.1.2 via esp32 proxies, with a Bluecharm BC021, using the button triggers for unique UUIDs as well as turning the beacon off for periods of time, confirming with the KBeacon app that broadcasting is happening or not and with which UUIDs.

I have this beacon producing three entities: one for the default UUID broadcasting continuously (ibeacon-bluecharm-defualt); a second with a UUID that is the default UUID+6, which only broadcasts for 60s upon the buttons double press (ibeacon-bluecharm-doublepress);
a third with a UUID that is the default UUID+7, which only broadcasts for 60s upon the buttons triple press (ibeacon-bluecharm-triplepress). See config details on the beacon here.

@BlueCharmBeacons recommended state trigger in automatons works for getting state change notifications. Here's what I'm seeing after about a dozen on/off cycles.

Powering the beacon on, within 20s or less from an away state, I'll get a notification the default beacon is home.

Strangely, within 30s, I'll get a notification the double and triple press beacons are also home, without having activating those broadcasts (confirmed by watching KBeacon and not seeing those UUIDs). Upon activation (double or triple pressing the beacons button), I can observe within KBeacon the UUID change for 60s and then revert to the default UUID. Yet, they never change state to away, confirming by observing the following template:

{{ is_state('device_tracker.ibeacon_bluecharm_defualt', 'home') }}
{{ is_state('device_tracker.ibeacon_bluecharm_triplepress', 'home') }}
{{ is_state('device_tracker.ibeacon_bluecharm_doublepress', 'home') }}

Powering the beacon off, between 4 and 10 minutes, I'll get a notification that all three beacons states are away, all showing unavailable for distance, power, and signal strength.

The behavior for the default beacon is great, working as expected. Reducing the time for reporting away would be doublely great.

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 🤷‍♂️

[BlueCharmBeacons]

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.

[danblah]

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?

[BlueCharmBeacons]

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.

[bseishen]

I am experiencing the same issue with the ibeacon never showing away. Using ble proxy via esp32/esphome. ibeacon is the blue charm(bc021). I have recompiled latest esphome binary using esp-idf framework since the ble stack seems to be more efficient. Flashed it with USB since the flash sectors need to be adjusted.

Beacon is set to advertise ever 1s. HA seems to only get an update ~1min looking at the last updated time.

I do have ~8 or so Xiaomi temp sensors using the same proxy.

[KennethLavrsen]

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?

[BlueCharmBeacons]

I am experiencing the same issue with the ibeacon never showing away. Using ble proxy via esp32/esphome. ibeacon is the blue charm(bc021). I have recompiled latest esphome binary using esp-idf framework since the ble stack seems to be more efficient. Flashed it with USB since the flash sectors need to be adjusted.

Beacon is set to advertise ever 1s. HA seems to only get an update ~1min looking at the last updated time.

I do have ~8 or so Xiaomi temp sensors using the same proxy.

I got it working fairly well, EXCEPT for the strange edge cases where the HA restarts while the beacon is away. Aside from that, it should work if you follow this:

#79833 (comment)

[bseishen]

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

[ibanmda]

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

iBeacon nRF52810
Home Assistant 2023.1.7
Supervisor 2022.12.1
Operating System 9.4
Frontend 20230110.0 - latest

[20:55:30][C][bluetooth_proxy:065]: Bluetooth Proxy:
[20:55:30][C][bluetooth_proxy:066]:   Active: NO
[20:55:30][C][esp32_ble_tracker:870]: BLE Tracker:
[20:55:30][C][esp32_ble_tracker:871]:   Scan Duration: 300 s
[20:55:30][C][esp32_ble_tracker:872]:   Scan Interval: 1100.0 ms
[20:55:30][C][esp32_ble_tracker:873]:   Scan Window: 1100.0 ms
[20:55:30][C][esp32_ble_tracker:874]:   Scan Type: ACTIVE
[20:55:30][C][esp32_ble_tracker:875]:   Continuous Scanning: True

Me too! :(

[GRClark]

I’ve tried two different iBeacons now from Blue Charm and Feasycom and no matter what I can’t get them to say away. Only change I can invoke is if I turn them off and restart HA and it’ll then come back up as unavailable. I’m certain it’s not the Bluetooth coverage because as soon as I turn the beacons back on HA immediately marks them back as home once again. I really want this integration to work as it’d make a great presence solution for those I don’t want to give access to HA.

[BlueCharmBeacons]

Hi Gene,

Did you set up the HA settings exactly like I showed above? #79833 (comment)

Thomas

[GRClark]

Hi Gene,

Did you set up the HA settings exactly like I showed above? #79833 (comment)

Thomas

I’ve set it up like that as well set the state to blank to monitor for any changes at all. Even on the device page under iBeacon tracker integration it never changes. I’d buy a dozen of these things if only they worked reliably.

[KennethLavrsen]

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

[turboc1208]

It's still a problem. I looked at the code very quickly so I may be wrong. It looks like it's based on when it receives an advertisement from a beacon and marks it as home. I didn't see anywhere that it looped through the active beacons to see how long it's been since HA last received an "I'm Here" advertisement from the beacon. I would think it would be fairly easy for someone familiar with the coding standards for HA to add a parameter to the active beacon structure and loop through the active beacons every minute or so, checking to see how long it's been since the last advertisement. If it's been over some configurable time, mark it as away. Again I may have missed something if I did I'm sorry for stating the obvious.

[djdubd]

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

I have also got the a persistent "home" beacon in the form of an Android phone with the companion app and the BLE Transmitter sensor enabled.

[apaperclip]

On HA 2023.7 and 8 and now 9beta (docker) and esphome 2023.7.1 on a quinled esp32 freshly setup a bc021 as an ibeacon, its stuck 'home' There was an improvement a few versions ago to learn the advertisement interval to detect when the beacon has gone away. This is likely something different, perhaps like the ideas mentioned above where its any advertisement from a mac, etc.

This same bc021 is used by some statically defined ble_precense sensors in other esphome devices and the HA device_ble_tracker integration and they all work fine. It's just the ibeacon integration that is stuck 'home'.

[jaymunro]

I can confirm my HA 2023.10.3 has my MikroTik TG-BT5-IN constantly at home.
When the device leaves home, all related state sensors (RSSI, estimated distance, etc) just continue to show their most recent value. This would be consistent with HA logging only state changes as per normal practice.

My interpretation is that there is still no consistently working code present to change the state to not_home and the other sensors to unavailable when the last report is stale.

I say "consistently" as there seem to be some reports above of 'not_home' working sometimes.

[jaymunro]

Following that, for a long while (about 2 days) all sensors changed to unavailable following a restart, and stayed that way.

Then, after I changed the advertising frequency from 5 sec to 1 sec and disabled the iBeacon packets on the MikroTik device, it started working reliably, from 2:53pm. Regular updates were coming in, it changed to ‘not_home’ 7 mins after the device left home, and immediately back to ‘home’ the moment the device came back.

However, after some other updates and restarts in HA, it completely stopped picking up the advertisements again, from 5:57pm. This time not just the MikroTik device, but the other registered BLE device, a Tesla car, became unavailable and have stayed that way.

Something is causing some significant unreliability.

[gafain]

Hello,
I Have 2 installations, at home and at office, and I have the same problem but ONLY IN OFFICE.
I Have same model of ESP32Home installed with same configuration and I use the same iBeancon.
At home the presence and distance work perfectly .
IN Office Dectect correctly the distance when I was in Office, but when I go out the distance go to 60mt and the presence stay at HOME.

[agittins]

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.

[KennethLavrsen]

I only ever tried BLE Proxies and never had a BlueZ based device. The problem reported is not any better with a BLE proxy

Thanks for Bermuda. I will give that a go. Sad that the built in iBeacon integration is not being maintained any longer

[ipha]

Is this a shelly issue? I was using a shelly ble proxy and had this issue, but I recently switch to an esphome proxy and suddenly it's reporting home/away as it should.

[KennethLavrsen]

I have used both Olimex and generic ESP32 Dev kit. It does not work. It reports a device away if you restart HA. But the minute the iBeacon integration has seen the beacon it remains Home until you start HA again. The simple way to test it is to remove the battery from the iBeacon and wait a minute or two and keep an eye on the device tracker for the iBeacon.

The Bermuda custom component posted above does the job. I can recommend that instead.

[BogdanDIA]

I am just trying to use the iBeacon Tracking integration and flashed an ESP32 with iBeacon build and using the BLE receiver of the rpi4 that HA is running on.
When I poweron the ESP, the detection is instantaneous, when I unplug it it takes several minutes to be away.
Checking the bluetoothctl tool on rpi4, the ESP get's deleted from the list in like 10seconds so the integration must have added some delay.
I noticed that in the HA iBeacon sourcecode there the following definition, tried to change it to 10 and restarted but it seems to not have effect, need to investigate mode:

UNAVAILABLE_TIMEOUT = 180 # Number of seconds we wait for a beacon to be seen before marking it unavailable

I want to obtain a fast response from this integration because my plan is to use it to turn on/off lights outside when I arrive/leave home.

[KennethLavrsen]

Unplugging the ESP?? Normally an ESP32 has a wifi connection and when remove the power from an ESP32 you loose the Wifi.

It is a small battery powered iBeacon device that connects via Bluetooth BLE that we want to put in our pocket or keyring so you can use it to track when you are home and away.

[BogdanDIA]

@KennethLavrsen - you misunderstood what I wrote. For me the ESP32 is the iBeacon device that is broadcasting the iBeacon protocol (equivalent to your small battery powered devices). There is no wifi involved here. Plugging/unplugging means taking out the power of the ESP32 to test the home/away state transition.

Today I put the ESP32 inside the car that has BLE and is also broadcasting iBeacon protocol so two iBeacons were tracked by the HA. Also configured notification over Telegram when the tracked state changed. Drove around and the result was that I got notifications from both HA trackers in the same time for both situations, coming home and getting away. Coming home triggered every time notifications exactly at the same location in front of my house and works great. I also got notifications for away state but I was one mile away. This needs to be fixed.

Now for the future perhaps a smart HA integration is possible using several BLE receivers. It will allow one to get a sense of user's position based on the RSSI. This is used e.g. in Tesla cars where there are 4x BLE receivers (front, back, left, right) and so the car determines where the person carrying the phone is. Also identify each weel's position based on the signal from the TPMS sensors.

[jaymunro]

@BogdanDIA, see the Bermuda integration linked above. It's goals are exactly what you a looking for. We need more help there to achieve these, if you're keen.

This iBeacon integration seems unmaintained so it's unlikely that these issues and enhancements will be addressed.

[turboc1208]

The ESP32 devices will use the BLE protocol but are probably more powerful than a simple ibeacon key fob.  Also if you have multiple esp32 stations listening for ibeacons multiple will report at the same time making fine tuned control of lights on a room by room basis problematic. When looking at home vs away updates it’s important to tune the time to account for when you walk to your neighbors and are out of range for just a short time. You may not want the house to go into away mode due to just a couple of missed reads. On the other hand when you are marked as away just a single or maybe a couple of messages would be enough to put the house into home mode. I think the ibeacons and esp32 solutions are for different use cases. Sent from my iPhoneOn Jan 14, 2024, at 12:19, BogdanDIA ***@***.***> wrote: @KennethLavrsen - you misunderstood what I wrote. For me the ESP32 is the iBeacon device that is broadcasting the iBeacon protocol (equivalent to your small battery powered devices). There is no wifi involved here. Plugging/unplugging means taking out the power of the ESP32 to test the home/away state transition. Today I put the ESP32 inside the car that has BLE and is also broadcasting iBeacon protocol so two iBeacons were tracked by the HA. Also configured notification over Telegram when the tracked state changed. Drove around and the result was that I got notifications from both HA trackers in the same time for both situations, coming home and getting away. Coming home triggered every time notifications exactly at the same location in front of my house and works great. I also got notifications for away state but I was one mile away. This needs to be fixed. Now for the future perhaps a smart HA integration is possible using several BLE receivers. It will allow one to get a sense of user's position based on the RSSI. This is used e.g. in Tesla cars where there are 4x BLE receivers (front, back, left, right) and so the car determines where the person carrying the phone is. Also identify each weel's position based on the signal from the TPMS sensors. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[jaymunro]

To try and help the focus here, the ESP32 is a microcontroller. It can be programmed to one or multiple of a number of functions but with respect to BLE and the iBeacon standard there is a transmitter (iBeacon tag) or a "listener". The Esp32 can be programmed to do either (but not both):

1. Pretend to be a tag (transmitter). WiFi is disabled for this.
2. Listen for iBeacon BLE broadcasts (Bluetooth proxy) and repeat them over WiFi (or Ethernet) to HA.

However, as turboac pointed out, even though the iBeacon tags can be set to broadcast every second, some of those broadcasts can be missed and frequently are. Once a sec is draining on the battery though and if you don't want to be changing the battery every few weeks or months, it is better to set the broadcasts to once every 5-10 seconds. Once a second means a super quick detection on arrival and negligible effect from missed broadcasts. Not so with a setting of 10 secs. So it's a compromise between battery lifetime and response/reliability.

So for example, if a tag is set to broadcast every 10 seconds and 4 broadcasts are missed (yes, that and more is common), then there will be 40 secs of "absence". Naturally we don't want presence flipping on and off all the time and nether do you want it flipping to absence if you pop outside to put a tool away or put out the rubbish, so the "timeout" duration needs to be set fairly high to account for these possibilities. That's why it's often set to a few minutes.

Some integrations will dynamically set the timeout based on the average detection over the last x minutes/hours which is a good technique due to the variance in not only the broadcast interval, but also the home layout and interference increasing the missed broadcasts.

As an example the interference can vary greatly during the day within the same home as it's affected by people moving around (we contain a lot of water which absorbs 2.4GHz very well), kitchen being used (microwaves broadcast around the 2.4GHz range too), WiFi use (lots of WiFi packets means more collisions with Bluetooth), etc. etc.

Upshot is that either the integration is a simple 'one size fits all' solution that is easy for the beginner user, or we have an integration with lots of parameters to tweak to tune it for your home and the tags you use. I think this integration iBeacon is the 'one size for all' solution.

Even then, iBeacon is not that reliable for everyone. I think it really depends on the tags you use. I have one tag that would work well (car) and another that once in 'away' mode, would not detect its broadcasts anymore until an HA restart. Other people have issues with their tags not being picked up at all due to the lack of a name in the broadcast. And forget any transmitters that change their MAC addresses every few minutes (phones, watches, etc.)

If you are looking for anything more than the 'one size fits all' then another integration is better. Ones I know of are Private BLE Device and Bermuda.

[KennethLavrsen]

Mmm. Please remind what this bug report is about

What the original submitter reported, and many of us confirmed is that an iBeacon which is removed from your home so it is out of range (kilometers away) never changes state to Away or Unknown. It remains Home. Not for seconds or minutes. Forever as in multiple days. Only a HA restart sets it to unknown. And I am puzzled why a few claims that it works.

it is not about not being able to be detected home. The report is the opposite.

[BlueCharmBeacons]

@jaymunro Great summary and well written!

To add a couple points:

Re broadcast interval: Broadcasting every one second definitely uses more battery power, but any decent beacon will be able to last 16 months at that rate. No need to change the battery every few weeks or months. If the usage case can accept a slightly "fatter" beacon with larger battery, then 48 months battery life is easily achievable at 1 second broadcast interval.

Re missed broadcasts: Your point about missed broadcasts resulting in longer time until detection is exactly correct. Even at 1 second broadcast rate, some broadcast are going to be missed. At a 10 second rate, it is going to be much much worse. More broadcasts missed and more "painful" for each miss due to the long time between broadcasts. So it is much better to stick with 1 second interval or at most 2 seconds. At 2 seconds, a small beacon with a CR2032 battery will last 32 months!

Re missed broadcasts - more: Also keep in mind that the scanner is a responsible party in this as well. With ESP devices that HA people are using (e.g. Presence and Home), it is important to set the scan interval and scan window correctly. "The internet" often says that setting them equal will result in "continuous scanning", but I would not recommend this since it hogs all of the resources and causes other issues. Instead, set them to a ratio of 100/90. So the interval should be 100ms, and the window 90ms. This gives the little ESP some room to better handle wifi reporting during the "10ms" rest period. Even better would be to set them to roughly match the beacon broadcast rate. So if the beacon is set to 1000ms, then set the scan interval of the ESP to 1000ms and the scan window to 900ms.

By the way, we are getting some mini BLE gateways in stock in about 3 weeks that will be very useful for addressing the scanning side of the equation (something we have never gotten involved with before). This "home/away" issue is a piece of cake for a mini gateway. Opening/closing garage doors will also be easy. Turning on/off lights in individual rooms will still be a bit tricky, and will likely require some amount of trial and error to dial in the optimal solution case by case.

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[KennethLavrsen]

Ping

[jaymunro]

I managed to resolve the issue.

Steps were:

1. Uninstall iBeacon. It seems it is no longer supported so pointless hoping for fixes.
2. Install Private BLE Device
3. Install Bermuda Trilateration

As a result:

1. Means I no longer have to concern myself with a unsupported integration
2. Means I can track iOS devices with changing MAC addresses and no UUID.
3. Adds tracking to all other beacons by MAC or UUID. Gives very (very) responsive sensors to home/away events (within microseconds to coming home and configurable away timeout). Additionally it can tell you where in the the home the device is (accuracy is being worked on) and, finally, it is being actively developed.

For anyone wishing to cling onto this iBeacon integration, good luck I am unsubscribing from this issue post.

[BogdanDIA]

Hello all,

For my usecase (tracking car when it arrives/leaves home and reacting fast to turn on/off the lights) I built my own tracker with an ESP32 and ESPHome. I did this because the rpi4 that runs HA is far from the gate and the tracker needs to be close to the gate. Also because HA addons and integrations are usually very slow and having a lot of unnecessary code.

After experimenting for a while, the best solution was not the RSSI method and distance calculation based on both the power sent in iBeacon message and RSSI, but just counting the iBeacon packets that come from the car. This solution proved to work reliable for the last 3 months.

I filter the iBeacons based on MAC, UUID and iBeacon data.

Next step would be to have several such trackers so that trilateration is done.

[KennethLavrsen]

I have given up entirely on Bluetooth. I never wear a device indoors. I used it as a secondary detection for arriving home back when the IOS app was not so reliable. Now I can count on it in combination with detecting the phones connecting to wifi. Before I used my home coded bluetooth code in ESP32s. Only reason I ping this bug is that by principle a bug may still affect many and an official HA integration should not be allowed to have its severe bugs closed by a bot. An iBeacon integration that cannot detect when an iBeacon leaves is broken in its foundation. It is not an edgecase. It is a basic critical feature. And we know from postings earlier that the code to detect the beacon not there is missing. The bug is in the integration itself.

I played with the triangulation custom component. It works for detecting presence and no presence. But detecting which room I am in is only 90% reliable. I would not base my essential automations on that. There is nothing in our house that requires it to know who is in a room. Only that someone is there. For that mm wave radars in combination with PIR is 100% reliable.

[zelch]

Well, it sounds like I'm figuring out the development flow for an integration, so I can fork iBeacon and see about fixing this.

Assuming that I get anywhere, I'll submit PRs once everything works rightish.

Note, at the moment I only have a Bluez device, no BLE proxies, so I'm definitely going to be somewhat limited on testing the proxy side of things for now.

[mrjackson]

I don't know what I'm doing differently, but mine has been working perfectly for a LONG time now.
I'm willing to help if anyone knows what to look at to compare things.