MQTT Topic Advice

[ksum]

I am working on a system to control "workstations" in my shop. An Arduino with buttons and relays will make up most of the system. I do have a couple Z-Wave receptacles and 1 light switch. That said, I am debating changing how I approach MQTT Topics and am looking for some input.

I currently use a series of Topics such as

1st_Floor/Garage/Sensors/Temperature/
1st_Floor/Garage/Sensors/Illuminance/
1st_Floor/Garage/Workstation/01/ (On/Off payloads at this level)
1st_Floor/Garage/Workstation/01/Cmnd (to change internal settings - a Workstation has 1 or more lights and other devices)
1st_Floor/Garage/AirCompressor/
1st_Floor/Garage/Light/01/

From there I would go with On/Off or other payload values.

I intend to have a HomeSeer device called Garage Workstation and have each of the 11 Workstations be On/Off Features. I will also have an "Associated Devices" item for each WorkStation which I suspect will also be a Feature. Unless I can have Sub-Features. So for Workstation 01 I would have Feature for called 01 and another called 01 Devices which will house a JSON array.

Tasmota and some other items seem to take a different approach. Either these have all been done by people with more programming knowledge than I and for good reason, or they did it "just because." I am not sure I need the cmnd, stat, and tele prefixes for most items but wondering if there is good reason to have them as prefixes. It seems like more subscriptions are needed for anything using these prefixes. Why not use them (IF needed at all) later in the topic? Why send a regular status?

So for those of you with more MQTT experience, is there reason I should change my topic use? I see there is no standard, but lemmings follow and I see many in other areas talk about some of these as if it is a standard. Or maybe that is my limited view. Regardless, I am asking for some input and hoping to learn a thing or two.

On top of all these questions, an underlying item is how would I then use mcsMQTT and Associate the various Workstation Features?

[Michael McSharry]

Tasmota default is with the prefix to start a topic. There is a tool to manage a family of Tasmota devices and the tool use the Tasmota default. I have a lot of custom code in my devices so once a device is installed in service I rarely update the firmware to "the latest" version of Tasmota.

I use a convention where the device is the first element of the topic. In your example mine would be Garage/. I do not have install location information in my topic so in my case the topic is 100% a functional description.

As you indicated there is much variation in topic structure. Much like much variation in the locations and name properties in HS devices. My recommendation is to continue with a structure that makes sense to you. Settle on a convention of incoming vs. outgoing topics and use a designated part of the topic for this purpose. For example, Garage/cmnd/Power and Garage/Power being a pair of topics where one that subscribes to /cmnd/ will be the one that has the physical device that is being controlled and it will report the status in the same topic without the /cmnd/ being included. I have see suffix often used for this purpose such as /set or /command being at the end of the topic.

[jimbell]

Your approach certainly is valid. However, as a big user of tasmota on mostly sonoff devices, their approach is very good. Of course cmd is the shortened "command", stat is the shortened "status", and tele is the shortened "telemetry". I send the "cmd" as a command and get the returned status as "stat". For most devices you don't need tele, but is is nice if needed. I use node red as sort of a debugging tool. You can filter the incoming MQTT messages just by the first field. So you can easily see all commands going out in the node red debug window. The same for received status. Are you using any kind of status return be see the current status of your devices? I use this to control the icon in the left of the device in HS.

And lastly, MQTT messages are stateless. So the "cmd" preceding a message was sent to the device and "stat" message is a message sent by the device. In the node red debug window, I can very easily see what is going on and observe how the message flow is proceeding.

I also use some 8266 modules and I have coded them to use the "cmd" and "stat" so everything is consistent.

BTW, if you don't use node red, I highly recommend you install and start using it as a debug tool. It is pretty easy to learn, and in my opinion, is a must for IOT devices using MQTT.

[ksum]

Thank you, Michael.

I have considered dropping the "Floor" but then I think aboiut areas where I may have the same thing on different floors. Such as a bathroom. My "Floors" are:

• Basement
• 1st
• 2nd
• Attic
• Outside

I guess I COULD use BasementBathroom in those cases where there are more than one item. Regardless, something for me to think about.

[ksum]

Thank you, jimbell
I use Node Red but not for watching MQTT topics and payloads. I use MQTT Snooper on my phone for that. And IoT MQTT Panel for sending test messages. I may use Node Red for sending test messages, but the Snooper app is way to easy to use for viewing what is being sent.

As for who sent the message, provided it is screwed on accordingly, I do not care where it came from. So that use of stat and cmnd seems to be overkill.

[Guest]

No matter the topic structure you choose, my only recommendation is to settle on a format before you start implementing as changing this later on could require numerous changes in Tasmota, MCSMQTT, etc.

I started a while back and decided to stick with the standard Tasmota naming convention. Main benefit is one less thing to remember/configure when adding new devices. And ultimately, most of this is actually hidden under the hood when using an automation platform like HS.

[Guest]

I use MQTT Snooper on my phone for that. And IoT MQTT Panel for sending test messages.

Fyi, you can send test messages with MQTTsnooper as well (three dots-Publish)

[ksum]

Fyi, you can send test messages with MQTTsnooper as well (three dots-Publish)

Yes, but I find the panel easier. I can set it to send all possible values and different topics and quickly send messages.