MQTT as information model

Mqtt is my central communication platform at my smart home, every digital bit and byte should be reflected in the mqtt topic tree and all devices should communicate over mqtt. Data sources which don't support mqtt will be tranformed and forwarded to mqtt by Node-RED. This also applies to mqtt topics that can not be configured to fit the model described below.

MQTT schemas

The mqtt topic tree is the semantic description of the values. Generally it contains a description of the source of a specific mqtt message. There are two approaches commonly used:

• location-based: Home/Bathroom/light/isOn:true
• device-based: zigbee/00212effff0058a2/isOn:true

Both topics describe the same data source, the location-based approach is perfectly readable by human, but you need a mapping to actually address the device at the backend. The device-based approach contains the address of the light bulb and can be directly addressed without additional mapping.

A very good approach is described by Martin @harizanov.com. He is grouping the values into three groups: places, cloud and people. The places tree is mostly a location-based approach mixed with devices and the actual values as leaves.
This schema is perfectly readable by human but not by a machine. You will have to hard code the topic or you have to create complex regular expressions to get the context of the data integrated into the MQTT tree.

The people and cloud branch are even harder.

The new schema

There are many blog post regarding how to structure your mqtt topics, but I was not able to find one of them, which is really machine readable without domain or application specific knowledge and also perfectly readable by human. Together with some colleges we tried to define a mqtt tree structure which addresses this topic. We defined a convention to address the issue and to easily transform the topic into a tag oriented model.
To automatically parse the topic and assign a description to the data in the mqtt topic, we decided to add the type to the topic structure surrounded by brackets.

• [places]/springfield/[rooms]/kitchen/[sockets]/coffeeMachine/isOn
• [places]/springfield/[rooms]/bedroom/temperature

What is the benefit of it?

You can easily transform this schema into a semantic description of a leaf by transforming it into a json obect, e.g.:

{
  isOn: true,
  place: home,
  room: kitchen,
  socket: coffeeMachine
}

This makes it much more easy to process the value in your application and works well with e.g. Time Series Databases like influxdb.

Another benefit of this structure is, you can easily utilise the + character to subscribe to special classes, e.g.
[places]/+/[rooms]/+/temperature
This will help you to get all inside room temperatures. You will not get temperatures from outside or something else, without creating complex pattern.

Still it has some drawbacks, e.g. if you have different hierarchical levels: Think of one place has floors, the other does not. This is still not resolved.

In the picture below you can find a screenshot of my current mqtt tree.