The last ‘15’ cannot be higher than 10.
How did you manage to save those settings, Michel?
Homey v7.0.0
Beacon v.1.3.1
At settings 40, 10,1 20 had for weeks no false positives. The “20”. Was set before even 6.0. After playing with the setting I was not able to set “20 “ again.
At the moment my settings are 40,10,1,10 and i have too many falkse positives. As only the last paramter changed, it seems to me that the differnec between “20” and “10”. Is relevant.
Regards,
Paul
Hi Paul, pls read all of his post. It’s all there.
IF you are on Homey v.7.0.0 and Beacon v1.3.x that is.
Note, there is a bug about the settings being kept in cache (if I’m correct).
To be really sure your changes are actually getting used, I think restarting Homey is the only way for now.
- : The reason why you should want a longer timeout between two consecutive BLE scanning is Homey’s performance.
I’ve just released an fix for this at test:
v1.3.2 - 30.06.2021
- directly use settings when changed
- update minimal interval to 15 seconds
- update maximal verification to 30 seconds
- removed timeout config because it is deprecated from Homey 6.0.0
3 Likes
Where can it get the… Beta? 
For all aps in the Athom app store, you can access beta slash test versions by altering the URL and add /test or test to it (one / is enough).
If the official version is shown again after altering the URL, a beta slash test version isn’t available.
Like https://homey.app/nl-nl/app/com.koktail.beacon/Beacon/test
2 Likes
Hi Leendert, the bug should be fixed @ v7.0.0, but the false positives still occur a few times a day… the beacons were lying on a fixed spot and didn’t move.
I can’t discover a pattern either.
Any thoughts?
Any hints for proper batteries anyone? I’m aware that using no-name (Grundig) discounter models can be a negative factor.
FW v7.1.0
Beacon v1.3.2 test
The issue is fixed. Only the new firmware uses a fixed discovery time. (It was configurable). That is the reason why there are discovery failures.
Besides that athom add a cache layer that holds the discovered devices for some time.
I cannot make any improvements besides asking athom to change the mechanism.
2 Likes
Thanks, I know it’s at Athom’s side and hope they’ll fine tune those things .
Just an idea: is it possible to rename the capability signal_strength to f.i. measure_signalstrength ?
Like the Flower Care flora_
This way the signal gets displayed on the tile.
No hurries! And thanx in advance.
2 Likes
Hello @Peter_Kawa,
Starting from Homey firmware v6.0.0 Athom shortened to 5 seconds the BLE discovery period.
To increase the likelihood that a beacon will be discovered in a shorter period, one solution is to reduce the period with which the beacon repeats its signal.
With Homey v5.0.0 and the default discovery timeout of Beacon app (10 seconds) the best tradeoff (for me) between discover reliability and battery consumption was 1000 milliseconds. Starting with Homey v6.0.0 I reduced the period of all my beacons to 750~850 milliseconds. This period ensures (for me) a reliable presence detection.
Another (indirect) way for improving the BLE presence detection is to filter the false positives with a contact alarm (or a smart lock) on the main entrance door connected to Homey.
The basic flow for using a beacon that updates Homey presence is:
| When… | The beacon is outside range |
| Then… | Mark a person as away |
The filter is a condition flow card to be added to previous basic flow. The idea is that no one can leave the house without going through the main entrance door:
| And… | The main entrance door contact alarm status has changed within the last n seconds |
The value n should be set according the parameters of beacon app:
n = (5 + “The delay between reading sensor values”) * “Verification amount outside range”
2 Likes
Thanks! It’s a bit funny how Athom’s “improvements” sometimes makes things worse.
I have 4 flows for 1 beacon (no door (lock) check) to make it work for me.
Including timers, away/home status conditions.
But t.b.h. the timers make no sense anymore, while false positives happen just a few times a day. It’s a wireless protocol, I know, and “misfires” can happen too.
Only with confirmation push messages I can prevent my home from switching home/away when it shouldn’t.
Flows:
Back home
Away
Status setting
@ Home
Away
1 Like
Indeed, homey “improvements” make things worse. I use bt beacons to unlock my front door. It takes more than half a minute before it finally reads the bt beacons. At this time I’ve already put down my groceries, and typed the code in the lock.
I’m thinking of using a RPI zero W for reading RSSI of a beacon. I can put this close to the door somewhere outside. This than sends a webhook to homey to open the front door.
This way the beacon will only be used if it’s within a meter or 2 from the RPI.
But… My skills for python or bash are average to say the least… So I rather hope homey will fix this before I take on this new project 
maybe they’ll add the feature to trigger on RSSI
I guess this may come in handy, Fabian:
BLE2WiFi / mqtt
Buy an ESP32 for a couple of € and run the following code on it (thanks for the hint @robertklep)
1 Like
hmm, interesting post. HOw would i go into this? I have mqtt 2 way working (via home assistant as well). But how would this work? The esp32 is a simple mirco controller, I guess it needs a small casing or something?
YOu triggered my project attitude 
Hi Victor, by following the Github link you’ll find a great how-to with examples.
I think a general electronics housing is a start.
1 Like
hi, i just bought some tile 2018, and they are detected fine,
but i have the same problems as others with tags dettected as away, even though they are home, anyone found some stable settings?
another thing, is it normal with a delay of up to 2 min before detection?
that makes it a bit hard to use for deaktivating the alarm 
1 Like
