Why do we need to temporarily disable the white-list when adding a new entry?

Theengs OpenMQTTGateway Bluetooth gateways
1

I read in the Documentation the following

Note: if you want to filter (white or black list) on BLE sensors that are auto discovered, you need to wait for the discovery before applying the white or black list, or temporarily disable it:

Is there a rationale for this ? Why disable the list, why not just add a new entry to the white-list, and let the new device be auto-discovered ? It seem like I’m missing something here :slight_smile:

2

Welcome @benzok

I don’t really know that part of the code, but have you actually tried how you think it should work before posting? :wink:

As I’d also expect it to work like that, and do assume it already does.

3

Thank you @DigiH ,
It seems like the documentation is accurate, you need to disable the white-list to discover new devices. When the white-list is disabled any device can “pop in” and get discovered. Seems like an awkward way of doing it, so therefore my question “Am I missing something”.

I had a look at ZgatewayBT.ino and with a minor change I got the desired behaviour. Not saying it works for all cases but it “works om my machine” ™

diff --git a/main/ZgatewayBT.ino b/main/ZgatewayBT.ino
index 63174824..a9018571 100644
--- a/main/ZgatewayBT.ino
+++ b/main/ZgatewayBT.ino
@@ -388,7 +388,9 @@ void createOrUpdateDevice(const char* mac, uint8_t flags, int model, int mac_typ
       device->connect = true;
     }

-    if (model != UNKWNON_MODEL) {
+    if (model != UNKWNON_MODEL && device->sensorModel_id == UNKWNON_MODEL) {
+      newDevices++;
+      device->isDisc = false;
       device->sensorModel_id = model;
     }

Still, I might have misunderstood the white-list behaviour and this code is superfluous.

4

As I’m not using discovery on my personal setup I only use it when eating the discovery of newly created decoders or device class changes, all that generally without any white-list applied, but my understanding was that

• having an existing white-list with 4 devices present
• then sending a new white-list with a 5th device added to overwrite the existing white-list
• turning ON discovery, for the gateway as it defaults to being turned OFF 30 minutes after a gateways startup
• issue a restart command to the gateway, and after the restart the newly added device to the white-list is also being discovered- assuming it is a known recognised decodable device.

should work.

With the functionality of a white-list being that only these devices will be published by openMQTTGateway, ignoring any other, possibly also compatible decodable devices.

If you’re saying the above doesn’t work as I described it, and your change enables this, and doesn’t possibly cause nay other issues, you might want o submit a Pull Request on GitHub, in which case you should also amend the documentation accordingly within the PR :slight_smile:

5

Let’s see if there is someone else that has any views on white-list behaviour. If everyone is happy about the current way I will not meddle in this :slight_smile:

Thank you for your prompt reply.

6

Does it work for you as I described above?

7

As I am running a patched OMG right now I can’t verify it now. However, I assume that what you describe is correct.

I will check it during the weekend.

8

I have now tried it as you suggested and the new device is not discovered. I do get the readings from the device under the topic BTtoSYS, but nothing under homeassistant/sensor

If I disable the white-list the device (and a number of other devices gets discovered), so it seems to work according the documentation.

9

Then my above expected assumption was wrong, and you might want to propose your suggested change in a Pull Request.

10

Created a PR

1 Like