So I put in zigbee2mqtt in the weekend with the home assistant flag turned on.
And it’s being picked up by paper ui.
What in the MQTT topics is allowing it to be found? I have a number of python based “devices” I wish it was that easy to add to openHAB. And if I knew how, I’d get some development done on them.
In particular I’ve done work on pardoxalarminterface, and I know that has a home assistant mode as well but that doesn’t show up.
The MQTT 2.5 binding supports automatic discovery of devices that follow the Home Assistant or the Homie standards for MQTT topics. I don’t know the specifics for Home Assistant and I’ve not looked at the code but my guess from playing with it and looking into the Homie standard is that when the binding scans, it subscribes to # which will cause it to receive all retained messages on all retained topics. The Homie standard and I assume the Home Assistant standard defines one or more topics that use a retained message to indicate the device exists and describes the device.
The readme seems to point to that topic being homeassistant/../../object. Anything more than that (e.g. which specific topics the binding relies upon) will require looking at the code. I hope it’s enough to help.
I think there must be something else looked for, as the default for home was a topic starting homie, and homeassistant I’m not even sure if there’s a default base…but in my case that’s actually irrelevant, as I moved the base of zigbee2mqtt to sensors/homie
I’ll have a look for the binding code, I suspect it’s an $onlinem, but there must be something else as well
According to the docs I linked to (which you haven’t clicked on) the home topic is homeassistant and it discovers things through a subscription to homeassistant/../../object.
There has to be a default base. The binding needs to know ahead of time where to look for the topics.
That link also takes you to the source code for the binding.
Yeah i know I hadn’t looked at them yet. It was breakfast time. 
But my point is I’ve moved the base for homie, and don’t remember configuring something for mqttv2 as to where that is…but I could be wrong.
I just had a quick scan through all my configs and could see my manually mqtt items set…and I scanned user data as well for something set up in a thing for my changed base of sensors/homie.
Again, till I look at the source, I’m guessing it’s scanning all topics for #/$online maybe or something.
So this doco is saying that it looked for something in homeassistant/../../object which is plainly incorrect, as my item starts at sensors/homie/
And as we can see here in my inbox it’s identified as a HomeAssistant MQTT thing:
Maybe it’s old
"configuration": {
"properties": {
"topics": [
"binary_sensor/0x00158d00027bac3a/contact",
"sensor/0x00158d00027bac3a/linkquality",
"sensor/0x00158d00027bac3a/battery"
],
"basetopic": "homeassistant"
}
},
As there’s nothing on that topic as far as I know.
Ahh there is:
homeassistant/binary_sensor/0x00158d00027bac3a/contact/config {"payload_on":false,"payload_off":true,"value_template":"{{ value_json.contact }}","device_class":"door","state_topic":"sensors/homie/0x00158d00027bac3a","json_attributes_topic":"sensors/homie/0x00158d00027bac3a","name":"0x00158d00027bac3a_contact","unique_id":"0x00158d00027bac3a_contact_sensors/homie","device":{"identifiers":["zigbee2mqtt_0x00158d00027bac3a"],"name":"0x00158d00027bac3a","sw_version":"Zigbee2mqtt 1.14.0","model":"MiJia door & window contact sensor (MCCGQ01LM)","manufacturer":"Xiaomi"},"availability_topic":"sensors/homie/bridge/state"}
homeassistant/sensor/0x00158d00027bac3a/battery/config {"unit_of_measurement":"%","device_class":"battery","value_template":"{{ value_json.battery }}","state_topic":"sensors/homie/0x00158d00027bac3a","json_attributes_topic":"sensors/homie/0x00158d00027bac3a","name":"0x00158d00027bac3a_battery","unique_id":"0x00158d00027bac3a_battery_sensors/homie","device":{"identifiers":["zigbee2mqtt_0x00158d00027bac3a"],"name":"0x00158d00027bac3a","sw_version":"Zigbee2mqtt 1.14.0","model":"MiJia door & window contact sensor (MCCGQ01LM)","manufacturer":"Xiaomi"},"availability_topic":"sensors/homie/bridge/state"}
homeassistant/sensor/0x00158d00027bac3a/linkquality/config {"icon":"mdi:signal","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}","state_topic":"sensors/homie/0x00158d00027bac3a","json_attributes_topic":"sensors/homie/0x00158d00027bac3a","name":"0x00158d00027bac3a_linkquality","unique_id":"0x00158d00027bac3a_linkquality_sensors/homie","device":{"identifiers":["zigbee2mqtt_0x00158d00027bac3a"],"name":"0x00158d00027bac3a","sw_version":"Zigbee2mqtt 1.14.0","model":"MiJia door & window contact sensor (MCCGQ01LM)","manufacturer":"Xiaomi"},"availability_topic":"sensors/homie/bridge/state"}
But I can’t tell if they’re old retained messaged before I moved the base topic.
Ahh so that was interesting. Hmm for my next trick I want to see if I can change the base topic…
And looking a th esource, I see the way the home assistant code and homie code work are quite different.
Home assistant code looks for homeassistant/# no ifs or butts.
Homie looks for +/+/$homie
Pity they’re not a little more consistent.
Homie allows for changing the root topic. From The Homie convention
The root topic in this document is
homie/. If this root topic does not suit your needs (in case of, e.g., a public broker or because of branding), you can choose another.
All of the examples on the Home Assistant site (MQTT - Home Assistant) use “homeassistant” as the discovery prefix but that doc strongly implies that other options are allowed.
discovery_prefix
(string)(Optional)
The prefix for the discovery topic.
Default value:
homeassistant
In most cases the inconsistency between the two can be blamed on differences in the two standards. But in this case, I think the Home Assistant binding might be updated to support user defined discovery_prefixes. However, the gotcha will be figuring out how to supply that parameter. I’m not 100% positive that there is a way to ask for it prior to doing a scan and it seems awkward to add it as a parameter to the Broker Thing. It’s probably worth filing an issue for it and see what the devs say.
Exactly. I figure if homeassistant allows the base to be changed, then everyone implementing that standard should as well.
It must be a config item somewhere in the binding, you can have parms on a thing? So I’d expect a base homeassistant topic as part of an mqtt broker definition. Expecially if configured via things file, or paperui.
Homie, is more flexible in that a specific topic is needed, and I guess once that is found, then you know where you are somewhat. The homeassistant standard isn’t that specific where a wildcard base search could be used.
There’s a catch-22 here. You can’t discover the Thing until you set the discovery_prefix. You can set the discovery prefix on the thing until the Thing is discovered.
The only way I could think of to do this is to either:
So we have one approach that is likely impossible and another which is pretty ugly to stay the least. There is also a strong argument to be made that setting the discovery_prefix in the Broker Thing is inappropriate anyway since it’s strictly a Home Assistant discovery parameter.
Yeah i’d expect the latter. It’s a broker thing, and generally something someone would set up in their mqtt schema
Its not something you’d be wanting to change on every scan