Please bring back some kind of working whitelist / ignore everything else

[corgan2222]

Is your feature request related to a problem? Please describe.
Bring back a working whitelist, that only connect to given macs.

Describe the solution you'd like
Ignore ALL devices, macs, tags wich are not in the config whitelist.

Additional context
One of our raspberry zeros is mounted at the office frontdoor in a highly frequented public area. There are hundreds of people around at daytime. RA tries to connect to them and runs into a timeout, force an unlock and then restart the service.

In this time there are two different bad things happen.

1. No actual devices from the whitelist can be discovered.
2. The Home Assistant Sensor shows error/not at home for all clusters and devices. But there is no reason for doing so, because the office node is working fine and has detected some devices.

On a pi zero the restart takes around 4 minutes in between the hole cluster did not work.
So it would be great if RA would be ignoring everything what's not in the config whitelist.

Here you can see this

[corgan2222]

btw, this happens every 5-10 minutes. Every time if this happens, RA did not receive incoming whitelisted devices.
As you can see here in the loki log from the frontdoor, where so many people are around.

If there are no people around, RA on the other node run complete fine. Both are PI Zeros with the same images, installed drivers and packages.

[mKeRix]

For detecting iOS devices unfortunately the connection needs to happen before the allowlist is evaluated, as otherwise it's just a random MAC address that can't effectively be assigned to anything. In theory it should only try to connect to iOS devices that have the room-assistant app installed & running though, because it looks for a specific bit in the manufacturer data that denotes the RA GATT service id (the so called overflow area on iOS). It's possible that a different app also using the same Bluetooth APIs might cause the same bit to be activated though, which would load room-assistant to think that there is a companion app device where it really isn't... although from what I've seen not many apps use these APIs.

Two questions that might help spawn possible software fixes for your use case:

• Are you tracking any iOS companion app devices that should be detected at the front door already? I could add an option that disables the whole connection logic, which should resolve the timeout problems. This can also work in a hybrid mode, where you can have some nodes in the cluster with it activated that will still share the information with those that don't.
• Do you think that the healthcheck watchdog integration could be improved somehow or do you think your restarts are valid (i.e. the software actually got locked up due to all the BT timeouts)?

[corgan2222]

ah, ok thanks for clarification. I think there could be the problem, because we are in a high frequently area with a lot if tech companies around. The changes are high, that some people have the comp app running on their phones.

to your questions

• i only track my own ios device and a bunch of androids.
• not sure about that. Is there a way to debug this? If you like I can help to debug this, as you can send me your loki url (via pm)

[corgan2222]

After updating all nodes to 2.18.4 and rebooting, it looks like its getting worse.

[jkpe]

• Are you tracking any iOS companion app devices that should be detected at the front door already? I could add an option that disables the whole connection logic, which should resolve the timeout problems. This can also work in a hybrid mode, where you can have some nodes in the cluster with it activated that will still share the information with those that don't.

It would be nice to be able to disable the companion app connection attempts. I live in an apartment and I am seeing "Tag xx should have the companion app, retrying in 15s" or "Failed to discover companion app ID due to error: timed out" quite frequently.

Here is what it eventually returns if it is of any help: BluetoothLowEnergyService: Tag xx seems to broadcast the app with manufacturer data 4c0010073e1f68d99858580100000010000000000000000000000000

[SisyphusMD]

Idk if this is the right place to post a question like this, but thought I should try. I don't want to start a new issue because I may just be doing something wrong myself. My struggle is to use the logger function on an RPi Zero W to a grafana/loki instance (working fine from my pi 4bs, just not from the zero ws. After running sudo npm install -g winston-loki and adding the relevant logger configuration, room-assistant will no longer run until removing the logger configuration. And I receive the error: "Liftoff bailout should not happen. Cause: Armv6 not supported"

I'm asking here, because I see that corgan2222 successfully has rpi zeros reporting to a loki log. So maybe I'm just missing a step. Any ideas? Or should I post this question somewhere else?

[corgan2222]

I switched to ESPresense because I could not get this run stable on a Raspberry Zero.

It seems, that there are a lot of people having Problem with this Problem:

using --no-expose-wasm as node argument did the trick for me. The command instead of node . is node --no-expose-wasm .
homebridge/homebridge#3005

but launching the node binary with the --no-expose-wasm parameter did the trick.
sidorares/node-mysql2#1327

[townsmcp]

@corgan2222 sorry to side track this thread, but from the ESPresence site, I see a line that states “ Unfortunately if your household has many iPhones, eventually the nearby info will start to collide and lead to duplicate fingerprints.” - would 4 iPhones and 4 apple watches be classed as to many for reliable tracking? Do iPads, with Bluetooth on but not part of ESPresence tracking come into play on that?

[corgan2222]

Good Question which is not easy to answer. Apple's BLE implementation kind of suck.
If you only have one iPhone, it's superfast and easy to detect your iPhone. See in the screenshot the ID: exp:20 reports nearly instant, but for every Apple Device.

Tracking down to a specific device works well, but not that fast. You can see, that the IDs grouped by the iPhone Version and an ID.
I don't have 2 iPhones from the same series, so I can't tell. But it would be interesting how they report. I'm not the developer of the fingerprinting algorithm, I only implement the sensor stuff. :) If you want to give it a try, please report on the ESPresense Repo.