by Jesmi | Mar 28, 2022 | MQTT | 0 comments
MQTT messages aren’t sent directly from one thing to another. Rather, they are assigned to “MQTT topics.” The MQTT broker then distributes the messages to any clients who have subscribed to them. The term topic in protocol refers to a UTF-8 string used by the broker to filter messages for each subscribed client. When someone subscribes to a topic and then publishes a message to that topic with the retained message set to True, the topics are established. When the last subscriber to that broker disconnects, a clean session is established. Clean session is set to True when a MQTT client connects.
sensors/water_level/water_status – sensors, water_level & water_status are topic levels.
Forward slash ( / ) – a topic level separator.
The topic is made up of one or more topic levels. A forward slash separates each topic level (topic level separator). The broker does not require that topic to be pre-registered.
MQTT topics are very lightweight in compared to a message queue. Before publishing or subscribing to a topic, the client does not need to create topics. Without any prior initialization, the broker accepts any valid topic.
Here are a few examples to look at:
A look at MQTT Topics used in Bevywise Broker.
Except for the length of a UTF-8 encoded string, there is no restriction to the number of levels in a Topic Name or Topic Filter. Topic Names and Topic Filters are subject to the following guidelines:
The Topic Filter of a subscription can contain special wildcard characters that allow you to subscribe to multiple topics at once. The wildcard characters can be used in Topic Filters but not in Topic Names. Wildcards are classified into two types:
When one of the two wildcard characters is encountered in Topic Filters given by subscribing Clients, the use of the topic level separator is significant. Separators for topic levels can exist anywhere in a Topic Filter or a Topic Name. A zero length topic level is indicated by adjacent topic level separators.
A single-level wildcard character in a topic is represented by the plus symbol “+.” The Topic Filter’s single-level wildcard can be used at any level, including the first and last. It must fill the entire level of the filter wherever it is utilized. It can be used in the Topic Filter at multiple levels and in conjunction with the multilevel wildcard.
Any topic like “tank/water_level/+” matches “tank/water_level/flow_rate1” and “tank/water_level/flow_rate2,” but not “tank/water_level/flow_rate1/increase.” Also, because the single-level wildcard matches only one level, “tank/+” does not match “tank,” but “tank/” does.
The wildcard character “#” is a multilevel wildcard that can be used to match any number of levels within a topic. The parent and any number of child levels are represented by the multi-level wildcard. The multi-level wildcard character must either be given alone or after a topic level separator. It must be the last character supplied in the Topic Filter in either scenario.
If a Client subscribes to “tank/water_level/flow_rate1/#,” for example, it will get messages published under the following topic names:
Topics beginning with a dollar sign ($) are reserved topics. The $-symbol topics are for the broker’s internal statistics. Topic Filters that begin with a wildcard character (# or +) must not be matched with Topic Names that begin with a $ character. Clients should not be able to send messages to other Clients with such Topic Names, according to the Server. Topic Names that begin with a leading $ character may be used for additional purposes by server implementations. $SYS/ has become a prominent prefix for topics containing Server-specific data or control APIs. A topic containing a leading $ character cannot be used by applications for their own reasons.
All of the following information is usually stored in $SYS/, however broker implementations differ. A few instances are shown below.
The above are the basics of message topics. MQTT topics, as you can see, are dynamic and offer a lot of flexibility. Keep using its extensibility without changing the whole topic hierarchy for the subsequent inclusion of new sensors by adding these to your topic tree.
To Learn more about the protocol,
Please take a moment to fill this form