MQTT Topic Design

datamonkey · September 22, 2018, 2:12am

Hi community,

I seem to be adding more and more things to MQTT and that is a good thing.
But so far I have just taken the topics as they were defined by whatever I added:

Sonoff Tasmota:

- platform: mqtt
  name: "Ensuite Fan"
  command_topic: "cmnd/sonoff_ensuite_fan/power"
  state_topic: "stat/sonoff_ensuite_fan/POWER"

Battery Sensors:

homeassistant/sensor/

BRUH LED Lights:

- platform: mqtt
  name: "Holiday Lights"
  command_topic: "bruh/mqttstrip/setpower"
  state_topic: "bruh/mqttstrip/setpowerpub"
  rgb_state_topic: "bruh/mqttstrip/setcolorpub"
  rgb_command_topic: "bruh/mqttstrip/setcolor"
  brightness_state_topic: "bruh/mqttstrip/setbrightnesspub"
  brightness_command_topic: "bruh/mqttstrip/setbrightness"

and all of this works. But it feels like there should be some design behind it.
Maybe there is and I just can’t see it?

I was wondering if anybody has put some thoughts into their topic setup?
How are you running your topics?

edit adding some ideas:

TYPE / BRAND / NAME / ATTRIBUTE / COMMAND|STATUS

switch/sonoff/<sonoff name>/power/command
switch/sonoff/<sonoff name>/power/status

light/bruh/<light name>/setpower/command
light/bruh/<light name>/setpower/status

not sure how to fit the battery sensors here …

datamonkey · September 22, 2018, 3:03am

one approach I found:

github.com

mqtt-smarthome/mqtt-smarthome/blob/master/Architecture.md

# mqtt-smarthome

_Note that this project is not associated with or endorsed by http://mqtt.org_

## Overview

This document describes an architectural concept for a Smart Home Automation system
which ties together heterogeneous hardware using a centralized message bus: MQTT.

_Effectively, it just defines a convention for exchanging messages, and a message format._

It's goal is to provide an interoperability layer close to the hardware level.
Logic and Visualization are to be implemented at a higher level, on top of the MQTT bus.

```
+---------------+                                                          
|               |                        +----------------------+          
| Logic Engine  +-------+          +-----+ Hardware Interface A |          
|               |       |          |     | (e.g. KNX)           |          
+---------------+    +--+----------+-+   +----------------------+

This file has been truncated. show original

stevemann · September 22, 2018, 3:13am

Lets see, how many people are on the forum? That’s how many different topologies you will get. I think that typically most use a top-down hierarchy. As long as they are all different is all that really matters, but sometimes you want the MQTT client to get data from multiple topics using the wildcard. I’ve never needed to do this, but I’ve seen it done.

I am switching all of my ESP stuff (NodeMCU, ESP8266-01 and Sonoff’s) to Tasmota, and I am pretty much stuck with the weird hierarchy that Tasmota sets up. I can change the prefix and topic but I am getting used to the defaults.

datamonkey · September 22, 2018, 3:49am

You can actually change that: GitHub - arendst/Tasmota: Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
I just tried mine and changed it to reflect my idea above, it almost worked …

Full Topic:

switch/sonoff/%topic%/%prefix%/

resulted in

switch/sonoff/sonoff_ensuite_fan/stat/POWER

still not exactly what I wanted …