White-list Retention

Theengs gateway
1

I have read with interest the various posts regarding white-list retention and have been experiencing that the white-list periodically loses its retained status. For example, the following topic:

BLU/theengs_pl01/commands/MQTTtoBT/config -m '{“white-list”: [xxxxx }
xxxx included for brevity.

periodically gets over-written by the topic:

BLU/theengs_pl01/commands/MQTTtoBT/config -m '{“enabled”:true}

And when this happens, my white-list on whatever Theengs device it occurs on stops working and I have to manually re-publish the config:white-list topic.

I have 3 Theengs gateway devices. One theengs-bridge-v11 (v1.70 with v1.75 firmware) and 2 theengs-plugs (v1.70).

On each I have set the white-list in the format as follows:

mosquitto_pub -t BLU/theengs_pl01/commands/MQTTtoBT/config -m '{“white-list”: [
“1F:64:09:83:88:B8”,
“1F:64:09:71:8C:22”,
“1C:9F:25:50:C4:27”,
“1C:9F:25:31:68:5C”,
“1C:9F:25:53:C0:76”,
“D2:38:30:33:58:71”,
“CE:38:30:33:67:40”,
“3C:2E:F5:BD:77:1A”,
“B0:C7:DE:BC:3B:EA”,
“E8:E0:7E:D0:99:31”,
“1C:9F:25:31:C0:CB”

],
“ignoreWBlist”: false
}’ -r

I can then confirm in the broker that these are in fact retained. I can also see they are retained in MQTT Explorer. The gateways are then only publishing data from the white-listed MAC addresses. All good!

But at some indeterminant time in the future, it could be hours or days, something publishes the topic

BLU/theengs_pl01/commands/MQTTtoBT/config -m '{“enabled”:true}

Which then becomes the BLU/xxx/commands/MQTTtoBT/config retained topic and the white-list is gone. This happens to all the three Theengs devices at various times but not at the same time. It makes no sense that the broker would publish it because it should only be publishing its retained message(s). It would seem that some client, or the theengs devices themselves are publishing it. I don’t immediately see a way in either the broker or MQTT Explorer to find out who published the topic.

Any thoughts on this?

Thanks in advance.
Craig.

2

Hi @AA6CG

This only does happen if you send the above command, or any other non-white/black-list command, with the RETAIN flag active, which you shouldn’t.

Only a white-/black-list command should have the RETAIN flag set, so as to retain it indefinitely and always persistent.

See the docs NOTE about this

3

Thanks for the quick response. I read that before but that’s not the behavior I’m seeing. Please see the output from the broker below. Note that the white-list for device theengs_pl01 is no longer retained and has been replaced by the {“enabled”:true} command.

mosquitto_sub -u user -P pass -t “BLU/#” -v --retained-only

BLU/theengs_br01/LWT online
BLU/theengs_br01/RLStoMQTT {“latest_version”:“v1.7.0”,“title”:“OpenMQTTGateway”,“release_url”:“https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.7.0",“installed_version”:“v1.7.5”,“entity_picture”:“https://github.com/1technophile/OpenMQTTGateway/raw/development/docs/img/Openmqttgateway_logo_mini_margins.png”,“release_summary”:"”}
BLU/theengs_br01/commands/MQTTtoBT/config {“white-list”: [
“1F:64:09:83:88:B8”,
“1F:64:09:71:8C:22”,
“1C:9F:25:50:C4:27”,
“1C:9F:25:31:68:5C”,
“1C:9F:25:53:C0:76”,
“D2:38:30:33:58:71”,
“CE:38:30:33:67:40”,
“3C:2E:F5:BD:77:1A”,
“B0:C7:DE:BC:3B:EA”,
“E8:E0:7E:D0:99:31”,
“1C:9F:25:31:C0:CB”

],
“ignoreWBlist”: false
}
BLU/theengs_br01/LOGtoMQTT {“reason”:7,“uptime”:93}

BLU/theengs_pl01/LWT online
BLU/theengs_pl01/commands/MQTTtoBT/config {“enabled”:true}

BLU/theengs_pl02/LWT online
BLU/theengs_pl02/commands/MQTTtoBT/config {“white-list”: [
“1F:64:09:83:88:B8”,
“1F:64:09:71:8C:22”,
“1C:9F:25:50:C4:27”,
“1C:9F:25:31:68:5C”,
“1C:9F:25:53:C0:76”,
“D2:38:30:33:58:71”,
“CE:38:30:33:67:40”,
“3C:2E:F5:BD:77:1A”,
“B0:C7:DE:BC:3B:EA”,
“E8:E0:7E:D0:99:31”,
“1C:9F:25:31:C0:CB”

],
“ignoreWBlist”: false
}

4

I have never included the “ignoreWBlist” command, or any other additional command, within sending the white-list itself, as there is no need for it as a default. It shouldn’t make any difference, but maybe try without it as well, only sending the white-list itself.

I think you need to try and find out what that something is which send this command, not really making any sense if your BT gateway is already actively scanning BLE broadcasts, especially if it also is being sent retained, therefore overwriting the last retained message under that topic, wiping your white-list, as there can only ever be one single retained message per topic.

I am pretty certain it is not the gateways themselves sending this command. Could there be a second broker around which might have these commands as retained messages, sending it whenever one of the gateways might restart for whatever reason? Best to monitor the uptime of your gateways whenever this happens, to see if it is related to restarts and therefor a retained message being sent by someone or something to enable the BT reception again.

Could you also code fence Screenshot 2024-11-27 at 19.44.04 any further commands/code - just makes it a lot easier to read :slight_smile: thanks.

5

You might also want to make sure that all three gateways are on the recently released version 1.8.0, just to see if you are still seeing this behaviour with the latest release.

6

I think I believe I found the offending culprit! I use a home automation program called HomeSeer and am using a plugin called mcsMQTT. It monitors the broker and creates devices within the HomeSeer environment. When I stopped the plugin and restarted it, the retained topic changed to {“enabled”:true} on all the theengs devices. I will reach out to the developer (Michael McSharry) to see what he can do to remedy this. It looks like his plugin might be sending {“enabled”:true} with a retained flag.

Many thanks!
Craig