Messages

RSMP 4 defines the following messages with corresponding topic path structures:

Message type	Topic path
Presence	<node>/presence
Status	<node>/status/<code>[/<channel>]
Channel	<node>/channel/<code>[/<channel>]
Throttle	<node>/throttle/<code>[/<channel>]
Replay	<node>/replay/<code>/<channel>
Fetch	<node>/fetch/<code>[/<channel>]
History	<supervisor>/history/<code>[/<channel>]
Command	<node>/command/<code>
Result	<node>/result/<code>
Alarm	<node>/alarm/<code>

Most topic paths (except presence and channel state) follow this layout:

<node>/<type>/<code>

• node: The unique identity of the RSMP node.
• type: the type of message, e.g. status, command, alarm.
• code: the code of command/status/alarm within the module.

Components are not part of the topic path. When a message relates to specific components, the component is identified in the message payload. This keeps topics simple, avoids parsing ambiguity, and allows atomic multi-component messages.

Payload CBOR Encoding

Message payloads consist of JSON encoded in binary format using CBOR (Concise Binary Object Representation).

Using CBOR encoding saves space, while still retaining the JSON data model, which is very easy to work with.

CBOR is natively supported in many MQTT tools, making it painless to interact with RMSP 4 messages encoded with CBOR.