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 it 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.
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. |
- Topic if the connectable uses MQTT, URL for HTTP, ...↩