MQTT is still completely new to me, and I am currently looking into the best structure for my home MQTT tree.
After reading for some days now I understand that there are two main approaches: the semantic and the physical approach, so either:
Currently I think that I prefer the semantic approach because this is much more clear, but I am still in doubt about what to use as the root topic type.
As I see it now there are still two semantic methods to choose from: locational or functional.
Up to now I only saw the locational approach or “location as root” used in examples, like this:
Like that it seems to me that it is easier to filter the different functional usage types in the IoT network, for instance when using wildcards.
I can accept that for large MQTT networks with many local MQTT Brokers, like office buildings or complete companies, it might be preferred to use the “location as root” setup for performace reasons, but does this also count for a single family house with probably only one MQTT Broker?
Are there any strong cons against the functional approach?
If you can fully control your mqtt setup, either makes sense. However, it does not always work that way.
Certain systems force a tree on you.
E.g. Zigbee2MQTT, esprflink, openmqttgateway have their own root topics. HA autodiscovery needs a root topic of homeassistant (can be changed, but still needs its own root topic)
Tasmota is more flexible, but it is either %prefix%/%topic%/ or %topic%/%prefix%, or with a root topic before them.
Thanks again Francis, you are always very helpful.
OK, so it is more complicated than I initial understood.
However, I currently am only using Home Assistant with an RFXtrx433XL, some basic sensors and some ESP8266 devices, and nothing based on Zigbee, esprflink, openmqttgateweay or Tasmota.
So if I would set my functional tree with a root topic as “homeassistant” (or another self-chosen root topic) like this:
Then this would work for now?
And if I later add something that insists on having another root topic, I can still add this to the same MQTT Broker, right?
I’ve been using a “semantic - physical” structure for over three years and have not found any need to do “filtering”. MQTT entities you have in Home Assistant don’t leverage topic structure. Organize the topics the way you prefer (I’ve been using a “semantic - physical” structure for over three years ) but it won’t matter to Home Assistant.
FWIW, I’ve never found a need to do any “filtering” of the topics. What application do you have (or envision) what will need to do “filtering”?
MQTT is still completely new to me, and up to now I could do everything without using MQTT, but I am now looking into an application that apparently insists on using MQTT.
So that’s why I am now looking into it, and for what I read about MQTT it seems that a well-thought-out tree structure is essential?
Regarding the filtering, I had the idea that when using the functional approach it could be useful like this:
Assumed MQTT tree:
home/sensor/temperature/livingroom/unique_id
home/sensor/temperature/bedroom/unique_id
home/sensor/humidity/livingroom/unique_id
home/sensor/humidity/bathroom/unique_id
home/switch/light/livingroom/ceiling/unique_id
home/switch/light/livingroom/window/unique_id
To filter for the topics of all humidity sensors:
home/sensor/humidity/#
To filter for the topics of all light switches:
home/switch/light/#
To filter for the topics of all light switches in the living room:
home/switch/light/livingroom/#
When using the locational approach I don’t think it will be of much use to for example filter for everything in the living room:
home/livingroom/#
So how would functional filtering be done when using the locational approach?
Or are this possibilities:
Assumed MQTT tree:
home/livingroom/temperature/unique_id
home/livingroom/humidity/unique_id
home/livingroom/ceiling/light/unique_id
home/livingroom/window/light/unique_id
home/bedroom/temperature/unique_id
home/bathroom/humidity/unique_id
All humidity sensors:
home/+/humidity/#
All light switches:
home/+/+/light/#
All light switches in the living room:
home/livingroom/+/light/#
So I guess in the end the question is: can multiple wildcards be combined?
OK, so I think I can answer this question myself now, at least, when the HA implementation of MQTT follows the MQTT v5 Specification.
This is from the v5 specification:
“The single-level wildcard can be used at any level in the Topic Filter, including first and last levels. … It can be used at more than one level in the Topic Filter and can be used in conjunction with the multi-level wildcard.”
So my examples for functional filtering in an locational setup should be viable, but still I have the idea that with the functional approach the filtering is more simple to do.
I don’t dispute the value of an organized topic structure. However, gou overlooked to explain why you will be using filtering.
It’s sole application in Home Assistant is for an MQTT Trigger and that’s rarely, if ever, needed if you have created entities with the MQTT integration. Therefore, it must be a requirement for whatever other application you had mentioned. What is it?
It could very well be that I am misunderstanding how MQTT normally is used with Home Assistant, thus asking the wrong questions.
The application I am looking into at the moment is for monitoring the status of a Windows PC, and especially whether the attached display is in standby or not.
Some options could be “IOT Link” or “Win 10 Assistant”, which work through MQTT.
I did not use MQTT at all up to now (I even didn’t install it yet), so that’s why I am looking into MQTT now. And while reading about MQTT and trying to understand it (in general, so not specifically for those applications), I understood that wildcards are used to make selections in the MQTT tree, and I assumed that Home Assistant would work like that as well. But this is not the case at all?
Is it not an option to use the MQTT wildcard filtering in HA Automations to access specific entities?
Automations work with entities and the entities may use different integrations. For example, you may have 20 lights, 10 use the MQTT integration, 5 use Zigbee and 5 use zwave. The lights are controlled via their respective integrations. If you want to turn on/off all 20 lights, you don’t have to be concerned with the specifics of how that’s done for each type of integration.
I explained in my previous post that it is possible to employ MQTT filtering but it’s for a very specific use-case (MQTT Trigger). If you configure entities for each MQTT device you have (which would be the normal thing to do), it’s highly unlikely you will ever need to use an MQTT Trigger to interact with the devices.
Home Assistant doesn’t need the MQTT topics to be organized in any manner. When there’s a need to communicate with multiple MQTT devices, it uses each device’s topic (it makes no assumptions about topic structure so it doesn’t employ wildcards to communicate with multiple devices).
The exception is an MQTT Trigger but that’s not how you normally interact with MQTT-based devices (in Home Assistant). You would use an MQTT Trigger for a device that isn’t easily modeled as an entity in Home Assistant.
OK, thank you Taras and Francis, and sorry for me holding onto this misconception for such a long time
Case closed, and the conclusion is: when a MQTT Broker is solely used with Home Assistant the MQTT tree structure is not that critical at all.
I will install the MQTT Broker soon now, and see what all can be done with it.
I must say that I like Home Assistant a lot, but (mainly due to the almost unlimited possibilities) I often find it difficult to find the correct information.
