THe MQTT Conventions Document
This document is to highlight, document and improve our practices while designing MQTT Topic in our Deployments, keeping in mind
- Resource optimizations
- Use-case possibilities
- Empower Composability
- Provide Granularity
- Improve Verbosity
MQTT concepts and terminologies: EMQX docs - v3
These topics are broadly divided into two types. Administrative and Product Topics
These are topics on which administrative, metadata flows.
Data and events that are essential for the upkeep of the infrastructure itself. In our case,
- our region-wise presence topics: Kento/presence
- OTA topics
- Reset topic
The general form of these Admin Topics will be:
CURRENT_REGION would always be the first stub for a developer/custom created administrative topic.
These are topics on which product specific information flow, the data/information that drives the features/utility of the product.
The message update topic:
ROOT_STUB: Something that helps us easily identify the product line. example: digitalicon, homeswitch
PRODUCT_STUB: To identify the batch of the product line. Example: name of owner, name of usecase, mesh_id
DEVICE_ID: The unique id to each h/w device, can use: MAC address, or IMEI number. MAC prefered as on date.
ACTION_STUB: name of event/action to trigger or log.
NOTE: There is no hard limit of having exactly 4 sub parts of topics. General use-case discussed here
Topics only lowercase, numbers and dashes.
Topic stub from Left to Right :: General to specific
While Subscribing, multi-level subscriptions (using
#) are highly discouraged. Use single level wild-card (using
+) for stubs like DEVICE_STUB on open listners.
Use MAC address if possible as DEVICE_STUB.