I have the 1.3.1. installed with Homey 6.1.0 for a day. Unfortunately no improvement for me. Beacon still detected / not detected every few minutes.
Tried the following settings:
29.28.1.6
32,28,1,6
35.28.1.6
etc.
Hopefully for a fix. Without the beacon automatic control, Heimdall is much less comfortable.
Hello @Tregobad,
I would like to clarify the current situation.
The latest Homey SDK documentation published only a few days ago (Bluetooth LE - Homey Apps SDK) states:
Setting a custom timeout for a BLE discovery has been removed in Homey v6.0.0. Instead, a default timeout of 5 seconds is being used.
It is not very clear: What about the current Homey v6.1.0? If the custom timeout has been removed, is the new 5-seconds timeout a default timeout or, rather, a fixed timeout?
According to several tests I performed, I can say that the 5-seconds timeout is a fixed timeout in Homey v6.1.0. Thus, the Beacon App setting “discovery timeout” currently has no effect (always 5 seconds).
I asked for clarification to Homey.
The Homey core bug identified by @Koktail prevents the correct discovering when two consecutive discovering operation are too close in time. How close in time? I performed some tests and I can say that a safe value for the Beacon App setting “delay between reading sensor values” is 40 seconds.
In my opinion, today the reasonable settings (using your notation) are 40.5.1.x (where x ≤ 10).
This is an interesting question.
The short answer is:
The AirTags (and recent Tiles) send out some BLE signal but that signal changes from time to time so it cannot be used straigthforwardly for identifying the device.
The long answer is:
A beacon is a simple device that constantly emits the same identifier as a Bluetooth signal. Furthermore, all communication with a beacon happens “in the clear” and isn’t encrypted. Anyone can listen to your beacon and captures your beacons’ identifier.
Having captured the information, an attacker may clone your beacons. Cloning consists of copying your beacon configuration and putting it into another beacon to mislead your Homey.
Hasn’t any manufacturer fixed this security issue?
The solution is to use a pseudo-random identifier that changes periodically. Only authorized apps in possession of a special key can resolve the pseudo-random to a “real” one.
The solution is conceptually simple but it is difficult to put it into practice.
A quite complex centralized infrastructure is needed: the core is a public resolver service for registered beacons; it involves a registration process for sharing an encryption key between service and beacon. The registration process involves an authentication and authorization process (only authorized users can register their beacons; only authorized apps can resolve the real identity of a previously registered beacon).
The beacon itself needs a special firmware; it must store in a secure way the shared encryption key; it must implement a time counter for rotating the advertised pseudo-random identifier; the time counter must be able to recover from a power loss condition.
Today, only a few manufacturers provide secure beacons: Tile (since 2019) and Apple with AirTag (since 2021); these are “closed” solutions. Kontakt.io provides an “open” solution with a public SDK and a public discover service that works with their beacons. In 2016 Google proposed the Eddystone EID “fully open” solution but recently the service has been downsized several times (too complex for manufacturer, developers and users?)
To sum up, today the Beacon App is not able to provide a “secure” solution. If Beacon App users were interested, the only way forward would be the Kontakt.io beacons.
Hello @NoX,
On previous post I tried to explain why the integration of Apple AirTags into the Beacon App is not possible.
However the Beacon App v1.3.1 released two days ago supports an interesting beacon, the Feasycom FSC-BP108 that looks a lot like an AirTag. Similar size (48 mm x 37 x 7.8) and similar weight (15 g); same case protection degree (IP67); same battery (CR2032).
Hello @Peter_Kawa,
There two similar models: the Feasycom FSC-BP108 and the FSC-BP108N. The first one is the most recent device based on the new DA14531 SoC (Bluetooth 5.1). The second one is a device based on the “classic” nRF52832 SoC (Bluetooth 5.0). Differences? As far as I know, the price and the declared battery life (1936 days vs 515 days, based on manufacturer declarations for an advertisement interval of 1000 ms @4dBm).
I bought a Feasycom FSC-BP103B, with Ibeacon. I have Homey pro V5. I connect to it fine as a Ibeacon and/or BLE device. The thing is it says it is connected even when the beacon is miles away. Not sure what to do. Anyone have any ideas?
Thanks for the Tip- I just checked the version again and it’s 6.10 Somehow i turned on auto update. So that me in the same boat as everyone else on this topic. Waiting for Homey BT fix.
Hello @victoroos,
Please note that Beacon app v1.3.1 performs an input validation on values entered in app setting page.
“The interval between updates in seconds (default 10)” must be equal or greater than 1.
“Discovery timeout (default 10)” must be within the range 5~30.
“Verification amount inside range (default 1)” must be within the range 1~10.
“Verification amount outside range (default 5)” must be within the range 1~10.
These constraints have not changed from previous versions of the app.
Recently my homey became a bit slow & hot which made me check the memory status of my apps.
The experimental version of the beacons app seems to be the issue.
I believe every drop in memory was a restart/ptp as i have had to turn off the power for other reasons.
Dont know if you can do something about it, but wanted to inform you. I downloaded the normal version again.
Hi,
I have now installed Homey 7.0 RC12 for 4 days, as well as Beacon 1.3.1 test. According to the Homey Release Notes, the core bug (BLE discovery to fail) should be fixed. But I have the same problem as before, at short intervals: Inside / Outside, although the tiles are not moved. I changed the configuration parameters several times, nothing changed for me. Same flawed behavior.