The topic is the magic behind MQTT. It's what makes it possible to route messages to the correct client. A topic is similar to an address but is more sophisticated. A topic can have multiple fields and each of these fields can be used by subscribers to select the messages they want. When subscribing to a topic some of the fields can have wildcards which means the broker does not filter on that field. Subscribers designate which messages they want by subscribing to a set of topics. When the MQTT broker receives a message it sends it on to subscribers that have subscribed to that topic.
A topic in LabTime consists of 3 to 5 fields separated by the slash ('/') character. It looks like a file path on your computer. The secret to a great MQTT solution is to properly design and use these topics.
The fields in LabTime topics are:
- Project ID - with a special project id of 'a' for messages that are administrative
- Action ID - inp, out, hum, upper, lower, high, low, msg, cmd, rsp, cod
- Client ID - Usually the publishing client - sometimes the receiving client
- User ID - optional - allows for user to user private chat
- Telegraf ID - optional - triggers loading data into historian (future: Drupal)
Here are some examples of LabTime topics: (rf is the project code for my cabin at Red Feather Lakes)
- a/cmd/administrator
- a/cms/cmd
- rf/inp/arduino5/ignore/safire
- rf/out/arduino5/ignore/safire
- rf/msg/labtime/ralph
- rf/act/labtime/ralph
When a client subscribes to the MQTT broker it can use wildcards. For example the telegraf loaders ignore the first four fields and use the fifth field:
+/+/+/+/cb_safire
The telegraf loader named safire receives any messages that match and loads it into influxDB.