You let your neighbour’s devices connect to your MQTT? What madness is this?
1 Like
Though I too am interested in the answer to Nick’s question, this functionality already exists with the enable/disable feature.
Accept
Happens automatically no need to change this.
Deny forever
Disable the entity/device
Deny now and ask again after HA restart if appears again
Re-enable the entity when/if you want to.
I think he is using an SRD with rtl_433 and autodiscovery. So it is more a question for the add-on developer.
Yes I am using OMG_lilygo_rtl_433_ESP which runs on a $3 esp32, sniffs the air for 433MHz devices and then publishes their output to my HA MQTT server.
It allows me to convert $5 cheap wireless temperature monitors into HA devices - so I can monitor temperatures in different rooms, my refrigerator/freezers, etc.
It’s great except that it obviously doesn’t know which devices are “mine” vs “neighbors”
My MQTT shows only 2 system options:
- Enable newly added entities
- Enable polling for updates
I do not see an option like:
- Query before adding an entity
More importantlty, the “Accept/Deny forever/Deny now and ask again after HA restart if appears again” functionalty you reference seems to be about disabling MQTT entities, not adding them in the first place.
I don’t want to have these foreign entities added at all!
Because then even if my UI is clear, my states_meta gets cluttered with dozens of neighbor entities that only grows every time they change the battery in their devices.
It would seem very natural for the integration to allow the user to choose before the device/entity have been added to HA.
MQTT Discovery only discovers what is submitted for discovery.
Your ESP device finds all 433MHz devices in your neighborhood and submits them to Home Assistant via MQTT Discovery.
It isn’t MQTT Discovery’s responsibility to filter out discovery requests. The responsibility lies with whatever makes the request.
If you have no control over what the ESP device submits to Home Assistant via MQTT Discovery, then that’s a shortcoming with its functionality (not with MQTT Discovery).
Here’s one way to filter submissions from the ESP device:
By default, the MQTT Discovery topic begins with homeassistant. If possible, reprogram the ESP device to publish to an MQTT Discovery topic beginning with temp or discovery433 or another word of your choosing.
Create an automation that listens for anything published to the temp topic and then re-publishes it, in its entirety, to the homeassistant topic but only for the 433MHz devices you want. In other words, the automation contains a “white list” of desired 433MHz devices and doesn’t re-publish devices that’s aren’t in the list.
The automation will only allow Home Assistant to discover the specific devices you want (and ignore your neighbor’s devices). Let me know if you need help creating it.
EDIT
Here’s an example of the automation I described. It assumes the ESP device has been reprogrammed to publish MQTT Discovery messages to a topic beginning with discovery433 instead of the default homeassistant.
If a discovery topic looks likes this:
discovery433/sensor/wxyz4567/config
and it represents a sensor you want to have created in Home Assistant, then you should add wxyz4567 to the whitelist variable (see below).
alias: 433MHz Discovery Filter
trigger:
- platform: mqtt
topic: discovery433/#
condition:
- condition: template
value_template: "{{ trigger.topic.split('/')[2] in whitelist }}"
action:
- service: mqtt.publish
data:
topic_template: "{{ trigger.topic.replace('discovery433', 'homeassistant') }}"
payload_template: '{{ trigger.payload_json }}'
retain: true
variables:
whitelist:
- abcd1234
- wxyz4567
- qrst8888
- mnop4444
1 Like
You do it at the device/entity level, not the whole integration.
That’s a very clever solution.
Unfortunately, it seems like the OMG_lilygo_rtl_433_ESP Web GUI config allows one to change the ‘MQTT Base Topic’ (which defaults to home)
But it doesn’t seem to have a user config to allow one to set the ‘Discovery topic’ to say /homeassistant-preview
Any ideas on how to do that?
With your approach, I don’t even really need the automation.
I could just cut-and-paste desired discovery config messages over from say /homeassistant-preview to /homeassistant
If it defaults to home then it’s not the same as the default prefix in Home Assistant’s MQTT Discovery which is homeassistant.
Did you change the default prefix in Home Assistant from homeassistant to home?
Because anything published to topic with a home prefix will not be discovered by Home Assistant using its default prefix of homeassistant.
My point is that the published data topics have a default prefix of home.(and that is configurable in the OMG_lilygo_rtl_433_ESP Web GUI) and that is fine.
The config messages have a default prefix of homeassistant and in accordance with your suggestion, I would like to send them to another discovery prefix that doesn’t get picked up automatically by HA.
Though according to what you last posted, perhaps if I can’t change the Discovery Prefix in OMG_lilygo_rtl_433_ESP, then I can change it in HomeAssistant and have the same effect. Sort of reverse to what I wanted but should have the same effect.
i.e., non discoverable topics go to homeassistant and discoverable ones will be manually placed in homeassistant-new (or whatever I configure it to in HA)
I see. In that case, you can change Home Assistant’s default discovery prefix to something other than homeassistant.
Sure, if you don’t mind manually republishing each discovery topic and payload.
The automation I posted above spares you that drudgery. All you need to do is populate the automation’s whitelist variable (and delete all existing discovery topics and make the ESP device republish them).
It looks like our messages crossed.
For me it’s even easier to write a bash script to do that.
- Use ‘mosquitto_sub -t homeassistant/# -v’ to get all the existing published ones
- Optionally edit out any I don’t want to copy over
- Loop through them and pipe them through and filter with ‘sed “s/homeassisant/homeassistant-new/”’ and publish them using ‘mosquitto_pub’
DONE!
Though I posted to the MQTT group to see if there is a way to change the Discovery prefix on the OMG_lilygo_rtl_433_ESP end since that seems “cleaner”
Sure, whichever way you prefer, the principle remains the same:
- ESP device publishes to topics with a non-discovery prefix
- Desired topics are copied to new topics with a discovery prefix
Whether you want a tool that does this dynamically or only on demand, it’s your choice. Either way it’s a trivial operation.
If it doesn’t exist as configuration parameter then one would have to modify the source and recompile it. However, 1technophile is responsive to user feedback so he may readily see the value of it, especially if you explain it’s for filtering discovered devices (and for Home Assistant users who may have changed their default discovery prefix).
Thanks for the help here!
1 Like
You’re welcome!
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title indicating to others that this topic has been solved. This will help other users searching for a means of filtering their MQTT Discovery topics.
Looking at the code, it seems like one can change the discovery prefix in OpenMQTTGateway by changing the following declaration:
#define discovery_Topic "homeassistant"
Presumably one could add the following line to the corresponding platformio.ini file:
-Ddiscovery_Topic="homeassistant_staging"
if one wants to see the discovery topics first before copy/publishing them over to homeassistant for auto-discovery by the HA MQTT integration.
Alternatively, one can use the python script rtl_433_mqtt_hass.py (see: rtl_433/examples/rtl_433_mqtt_hass.py at 6f7846e829cf9e9d6d27224ed8adb1f00f9f3a48 · merbanan/rtl_433 · GitHub).
This python script:
- Logs into the MQTT broker
- Subscribes to the event topics under ‘-R|–rtl-topic’ (default: rtl_433/+/events)
- Creates corresponding discovery topics
- Publishes them under discovery prefix ‘-D|–discovery-prefix’
It organizes and constructs the discovery messages a little differently from OpenMQTTGateway but it is supposed to still work with HA.
If you use a different discovery prefix from what HA uses, then you can use the different discovery prefix as a staging area:
e.g.,
python3 rtl_433_mqtt_hass.py -u MQTT -H homeassistant -P <password> -r -R home/OMG_lilygo_rtl_433_ESP/RTL_433toMQTT/# -D homeassistant-staging
Alternatively, one can use the python script
rtl_433_mqtt_hass.py(see: rtl_433/examples/rtl_433_mqtt_hass.py at 6f7846e829cf9e9d6d27224ed8adb1f00f9f3a48 · merbanan/rtl_433 · GitHub).
Unfortunately, the format for naming devices and entities along with other config data differs from the format used by OpenMQTTGateway so this is not a perfect solution.