Connhex Message Policy (CMP)
The Connhex Message Policy (CMP) describes a way for connectables to send messages.
What is it and why should I care?
You can see CMP as an abstraction over base message formats, with the main goal of routing messages based on what type of information is carried.
If the connectable-to-cloud communication correctly implements CMP, Connhex Core will automatically route messages to dedicated tables, ensuring faster data retrieval and storage costs minimization. It also provides a great starting point for many communication scenarios.
Components
There are three types of messages: infos, params and data.
| Type | ID | Format | Notes |
|---|---|---|---|
| Infos | infos | JSON | Contains information that describes a connectable (e.g. serial, firmware version, ...). It consists of information that either can't be edited or doesn't change at runtime. |
| Params | params | SenML | Contains all the connectable's configuration parameters (e.g. current operating mode, ...): these can be edited at runtime. |
| Data | data | SenML | Contains any time series collected by the connectable during its operation (e.g. temperature, pressure, ...). |
To tag a payload according to this classification, the connectable only needs to specify the corresponding ID as the last segment of the target path 1:
channels/<chan_id>/messages/events/<ID>
If ID is not specified, all routing will default to data.
Transmission rate
The majority of use cases see data as the most frequent message, followed by params and infos. Use the table below as an additional tool to map your messages into these three types.
| Type | Frequency |
|---|---|
| Infos | At every connectable boot/reboot, after a firmware update, ... |
| Params | Any time one or more parameters are updated, after a network loss event (if any parameters have changed), ... |
| Data | Any time new data is collected, or at regular intervals. |
Typical usage
The CMP is typically used in a device-first approach, where each device dynamically defines the metrics it sends: what follows is a typical use case.
Suppose a web UI needs to display collected metrics as charts. It will request data through the reader API, specifying each metric as name.
To know which metrics should be passed, one could in principle hard-code them client-side. However, this is not flexible, since it requires updating the frontend application each time a new metric needs to be displayed.
The CMP provides an immediate alternative:
- the device sends a
paramsmessage, containing all the metrics URNs - the UI fetches the last
paramsmessage and displays a select menu with all metrics - once the user selects a metric, data is fetched and presented.
Now, let's imagine logged metrics change 2: the device will send another params message and the UI will automatically update. This approach offers the flexibility to choose whether to keep old metrics visible or not: just keep including them in the params message or remove them.
You can find here an implementation of this strategy.