You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since my neighbors seem to have more rtl_433 and BLE devices as I do, my mosquitto_broker and HA potentially get overloaded with uninteresting messages.
Perhaps a simple way of implementing a "whitelist" of which devices to broadcast would be to define a whitelist_prefixes (which could be set to 'homeassistant' for example) which would be a list of one or more MQTT prefixes (default is blank) whose subtree elements would be whitelisted. If set (i.e., non-blank), then OMG will only broadcast to topics referenced in the subtrees of the elements of whitelist_prefixes.
Certain system-related topics would be whitelisted by default such as SYStoMQTT, LOGtoMQTT, LWT, RLStoMQTT etc.
If whitelist_prefixes is blank (default), then everything is allowed through.
To implement, you would use the picoMQTT analog of mosquitto_sub to subscribe to the elements in whitelist_prefixes, parse out the value of the stat_t keys and use those as filters against which MQTT messages to publish. The other keys and topic name could be discarded, saving memory.
It would presumably make sense to only enforce the white list when discovery is turned off
Note that a blacklist and blacklist_prefixes would be implemented similarly.
Usage in practice would be as follows:
Run with discovery turned on until you acquire all the sensors you are interested in (or add them manually)
Turn off discovery
Set whitelist_prefixes to homeassistant (for example)
Now only the devices in homeassistant will be whitelisted.
In this example, any time you add more devices withdiscovery_prefixes =homeassistant (whether manually or via auto-disscover), those devices will automatically be whitelisted.
Alternatively, one could use blacklist_prefixes for similar effect:
Once you have all your desired devices discovered (i.e., listed in homeassistant), change discovery_prefix to homeassistant-blacklist and make sure discovery is turned on (blacklist_prefixes should be blank for now)
Let that run for a while collecting discovery messages for all the devices in your neighborhood (including your own)
Reset discovery_prefix to say homeasistant and/or turn off discovery so no more entries added to homeassistant-blacklist
Edit out the devices you use from homeassistant-blacklist, say using MQTT Explorer
Add homeassistant-blacklist to blacklist_prefixes
The advantage of this approach is it doesn't require any UI changes (other than trivially adding 2 lines to MQTT configuration to accept whitelist_prefixes and blacklist_prefixes, respectively similarly to my PR to add discovery_prefix) and it uses the built-in power of auto-discovery to populate the lists and the existing MQTT Explorer app to edit them.
Not a top priorityf or me but just thought of it as a cool idea to put out there for discussion.
The text was updated successfully, but these errors were encountered:
puterboy
changed the title
Simple approach to implementing "white list" (and optionally "black list" of which topics to publish
Simple approach to implementing "white list" and "black list" of which topics to publish
Aug 30, 2024
Since my neighbors seem to have more rtl_433 and BLE devices as I do, my mosquitto_broker and HA potentially get overloaded with uninteresting messages.
Perhaps a simple way of implementing a "whitelist" of which devices to broadcast would be to define a
whitelist_prefixes
(which could be set to 'homeassistant' for example) which would be a list of one or more MQTT prefixes (default is blank) whose subtree elements would be whitelisted. If set (i.e., non-blank), then OMG will only broadcast to topics referenced in the subtrees of the elements ofwhitelist_prefixes
.Certain system-related topics would be whitelisted by default such as
SYStoMQTT
,LOGtoMQTT
,LWT
,RLStoMQTT
etc.If
whitelist_prefixes
is blank (default), then everything is allowed through.To implement, you would use the picoMQTT analog of mosquitto_sub to subscribe to the elements in
whitelist_prefixes
, parse out the value of thestat_t
keys and use those as filters against which MQTT messages to publish. The other keys and topic name could be discarded, saving memory.It would presumably make sense to only enforce the white list when
discovery is turned off
Note that a blacklist and
blacklist_prefixes
would be implemented similarly.Usage in practice would be as follows:
whitelist_prefixes
tohomeassistant
(for example)Now only the devices in
homeassistant
will be whitelisted.In this example, any time you add more devices with
discovery_prefixes =homeassistant
(whether manually or via auto-disscover), those devices will automatically be whitelisted.Alternatively, one could use
blacklist_prefixes
for similar effect:homeassistant
), changediscovery_prefix
tohomeassistant-blacklist
and make sure discovery is turned on (blacklist_prefixes
should be blank for now)discovery_prefix
to sayhomeasistant
and/or turn off discovery so no more entries added tohomeassistant-blacklist
homeassistant-blacklist
, say using MQTT Explorerhomeassistant-blacklist
toblacklist_prefixes
The advantage of this approach is it doesn't require any UI changes (other than trivially adding 2 lines to MQTT configuration to accept
whitelist_prefixes
andblacklist_prefixes
, respectively similarly to my PR to adddiscovery_prefix
) and it uses the built-in power of auto-discovery to populate the lists and the existing MQTT Explorer app to edit them.Not a top priorityf or me but just thought of it as a cool idea to put out there for discussion.
The text was updated successfully, but these errors were encountered: