MQTT Topic Specification
MQTT topic, payload, buffering, and broker-reconnect specification for H3, H5 Lite, H5 Pro, H6 Lite, and H6 Pro.
MQTT Topic Specification Document
Applies to: H3, H5 Lite, H5 Pro, H6 Lite, and H6 Pro.
Overview
This document describes the MQTT message topic specification used by the Mocreo Hub system
Message Format Description
- Message Format: JSON format
- Encoding: UTF-8
Topic Naming Convention
- Basic format:
mocreo/<hub_sn>/<category>/<target>/<action> - Hub SN: 12-digit device serial number, e.g. MC1234567890AB
- Node ID: 16-digit hexadecimal string, e.g. 0030AEA400000100
Backfill After Broker Reconnect
This behavior applies to all MOCREO Smart Hubs. In Hybrid Mode, the Hub has two paths: the direct MQTT connection to your broker and the connection to the MOCREO cloud.
- If only the MQTT connection drops while the Hub-to-cloud connection stays up, that data is not buffered for MQTT and is not backfilled when MQTT reconnects.
- If both paths go down at the same time, the Hub buffers data locally and backfills it once either path comes back.
In short, as long as one path stays up, nothing is queued for MQTT. Only a full outage of both paths triggers local buffering.
1. Node Measurement Data Reporting
1.1 Topic Information
- Topic:
mocreo/<hub sn>/node/<node id>/data - Publisher: Hub device
- Subscriber: Third-party servers, monitoring systems
- Example:
mocreo/MC1234567890AB/node/0030AEA400000100/data
1.2 Overview
This message is sent when the Hub receives measurement data from a Node. The message contains measurement values, timestamps, and other data.
1.3 Trigger Conditions
- Node actively reports measurement data
1.4 Single Data Payload Structure
{
"measureId": 1, // Measurement data counter
"timestamp": 1760682172, // Timestamp when Hub received data (Unix timestamp)
"model": "LS1", // Node device model
"temperature": 2850, // Temperature data (actual temperature = value/100, unit: Celsius)
}1.5 Field Description
- measureId:
- Normal measurement data: incremental counter
- Used for data deduplication
- Range: LoRa Sensor [0 - 0xFFFFFF]
- timestamp: Timestamp when Hub received data
- model: Node device model, used to identify device type
- temperature: Temperature value, needs to be divided by 100 to get actual Celsius
1.6 Example Message
[{
"measureId": 1,
"timestamp": 1760682172,
"model": "LS1",
"temperature": 2850,
}]2. Node Rule Event Trigger/Recovery
2.1 Topic Information
- Topic:
mocreo/<hub sn>/node/<node id>/event - Publisher: Hub device
- Subscriber: Third-party servers, alarm systems
- Example:
mocreo/MC1234567890AB/node/0030AEA400000100/event
2.2 Overview
This message is sent when rules configured in the Smart App are triggered or recovered. Used for alarm notifications and other scenarios.
2.3 Trigger Conditions
- Temperature threshold rule trigger/recovery
2.4 Payload Structure
{
"timestamp": 1760683821, // Event occurrence timestamp
"event": "trigger", // Event type: trigger/recover
"temperature": 28.6, // Temperature value when triggered (Celsius)
}2.5 Field Description
- timestamp: Timestamp when event occurred
- event:
trigger: Rule trigger (from normal state to alarm state)recover: Rule recovery (from alarm state back to normal state)
- temperature: Actual measurement value when triggered
2.7 Example Message
{
"timestamp": 1760683821,
"event": "trigger",
"temperature": 28.6,
}3. Node Configuration Information Query
3.1 Topic Information
- Request Topic:
mocreo/<hub sn>/node/<node id>/config/get - Response Topic:
mocreo/<hub sn>/node/<node id>/config - Request Publisher: Third-party servers, monitoring systems
- Response Publisher: Hub device
- Examples:
mocreo/MC1234567890AB/node/0030AEA400000100/config/getmocreo/MC1234567890AB/node/0030AEA400000100/config
3.2 Overview
Third-party servers can query Node unit information through this mechanism.
3.3 Interaction Flow
- Third-party server sends empty message to
config/gettopic - After Hub receives the request, it queries the corresponding Node's configuration information
- Hub returns configuration information through
configtopic
3.4 Request Message
{}Note: Request message is an empty JSON object
3.5 Response Payload Structure
{
"model": "LS1", // Device model
"units": { // Unit information
"battery": "%",
"signal": "dBm",
"temperature": "℃",
}
}3.6 Field Description
- model: Device model, used to identify device type
- units: Units for each measurement value
3.7 Example Response
{
"model": "LS1",
"units": {
"battery": "%",
"temperature": "℃",
"signal": "dBm"
}
}4. Node Dynamic Information Synchronization
4.1 Topic Information
- Topic:
mocreo/<hub sn>/node/<node id>/state - Publisher: Hub device
- Subscriber: Third-party servers, monitoring systems
- Example:
mocreo/MC1234567890AB/node/0030AEA400000100/state
4.2 Overview
This message is published when real-time status information of a Node needs to be synchronized. Used for device status monitoring and other scenarios.
4.3 Trigger Conditions
- Click button on Node
- Within a period after Node is first added
- Node online status changes (online/offline)
- Node probe status changes (disconnected/recovered)
4.4 Payload Structure
{
"found": true, // Node status: true: Node online, false: Node offline
"battery": 72, // Battery level (0-100%)
"signal": -15, // Signal strength (dBm)
"probe": 1 // Node probe status: 1: probe connected, 0: probe disconnected
}4.5 Field Description
- found: Current online status of Node
- battery: Battery level percentage (0-100)
- signal: Signal strength
- probe: Probe status, this field is not present in every payload, only carried when the field exists in the data reported by the Node
4.6 Example Message
{
"found": true,
"battery": 72,
"signal": -15,
"probe": 1
}