English is currently available.
IoT & MQTT DISCUSSION
I am planning topics for around 200 sensor nodes across several buildings. My first draft was one topic per node with a JSON blob of everything, named like /Sensor_Data_Node17. A colleague says this will be painful to subscribe to and to secure later.
What are the rules for the + and # wildcards, can I subscribe to everything on a broker, and what does a sensible topic hierarchy look like?
Topics are strings split into levels by /. Wildcards are allowed only in subscriptions, never when publishing. + matches exactly one level: site/+/temperature matches site/lab/temperature but not site/lab/rack2/temperature. # matches any number of levels, including none, and must be the last character of the filter: site/lab/# matches site/lab, site/lab/temperature and everything deeper.
A wildcard must occupy a whole level, so site/node+/temp is not valid. Topics are case-sensitive: Site/Lab and site/lab are different topics.
Subscribing to # gives you every application topic the broker lets you see, which is handy for debugging with mosquitto_sub -t '#' -v. It does not include topics beginning with $, such as the broker statistics under $SYS/; those need their own subscription, for example $SYS/#.
There is no command to list all topics, because a broker does not keep a directory of them. A topic exists only in the moment a message is published to it. You see a topic when a message arrives on it or when it has a retained message.
For the hierarchy, order the levels from general to specific and keep identifiers as separate levels so wildcards can select them, for example acme/building2/floor3/node17/temperature. Then acme/building2/# is one building, acme/+/+/+/temperature is every temperature, and acme/+/+/node17/# is one node. Embedding the ID in a name, as in Sensor_Data_Node17, makes all of those impossible.
Avoid a leading slash: /a/b has an empty first level, which is legal but wastes a level and confuses filters. Use lowercase ASCII without spaces, and keep the number of levels the same for the same kind of data.
On one JSON blob versus one topic per value: separate topics let consumers subscribe to exactly what they need and let retained messages hold the latest value of each quantity, at the cost of more messages. A single JSON message keeps values taken at the same instant together and needs fewer packets, which matters on battery or cellular nodes. A reasonable split is one JSON message for each group of measurements sampled together, plus separate topics for status and for commands.
Keep commands in a separate branch from data, for example .../node17/cmd/... against .../node17/state/.... Access control lists work on topic patterns, so a clean split lets you grant a node write access to its own state branch and read access only to its own command branch.
Back to IoT & MQTT community
