Routable types summary
When devices publish messages that require routing to business applications. These messages can be device events, data detection or network events, message routing is applied. Messages can be consumed via Application mode (MQTT over FIFO topics), HTTP push (webhooks), and the Listen REST API (when applicable).. To help their dispatching and use, the messages are labeled (by type) and versioned.
This section provides a global overview of supported routed event types, please refer to specific section for detailed output data model.
| Description | Public type | Available version number | Available filters in triggers & actions feature |
|---|---|---|---|
dataMessage |
1 |
connectors, groupPaths, deviceIds, tags |
|
matchingFired |
1 |
ruleIds |
|
stateChange |
1 |
ruleIds |
|
deviceActivity |
1 |
ruleIds, deviceIds |
|
deviceCreated |
1 |
connectors, groupPaths, tags |
|
deviceDeleted |
1 |
connectors, groupPaths, tags |
|
deviceStatus |
1 |
connectors, groupPaths |
|
commandStatus |
1 |
status |
|
loraNetwork |
1 |
messageTypes |
|
loraGatewayStatus |
1 |
— |
|
connectivityManagementPlatformEvent |
1 |
eventPayloadTypes |
|
alarmEvent |
1 |
alarmRule.type |
| At the moment, only version 1 is available. If new versions are added to the versioning space, the support team will notify you of the change. |
About action policies, triggers and actions
To route messages and events, you define an action policy that links: - one trigger (what to route, with optional filters), and - one or more actions (how/where to deliver: FIFO publish, HTTP push, etc.).
See: - Action policy - Triggers - Actions
Data Messages vs Events: what gets routed
Data Messages and Events are both “routed messages” (they have a public type and a version), but they do not come from the same source and they don’t carry the same kind of information.
-
Data Messages (type=dataMessage)
-
Emitted by: devices (or a business app posing as a device) via MQTT, LwM2M, LoRa, REST ingestion.
-
Purpose: transport business payloads from the device (measurements, states) in the value field.
-
Nature: “raw” device data enriched by Live Objects (metadata, tags, extra, location…).
-
Routing: you select them with a dataMessage trigger and filters like connectors, groupPaths, deviceIds, tags.
-
Events (types: matchingFired, stateChange, deviceActivity, deviceCreated, deviceDeleted, deviceStatus, loraNetwork, loraGatewayStatus, connectivityManagementPlatformEvent)
-
Emitted by: the platform (services like SEP/SP/AP/Device Management), the network (LoRa), or an external platform (e.g., CMP). Not by the device itself.
-
Purpose: signal a change, a detection or a lifecycle/status transition. These are notifications, distinct from the device’s business payload.
-
Routing: you select them with the corresponding event trigger and its specific filters (e.g., ruleIds, status, messageTypes, eventPayloadTypes, connectors/groupPaths for some DM events).
Filtering at a glance
| Routed type | Emitted by | Typical filters | What you receive |
|---|---|---|---|
dataMessage |
Device / Business app |
connectors, groupPaths, deviceIds, tags |
The original device payload under value plus Live Objects metadata |
matchingFired, stateChange, deviceActivity |
Platform (detection/processing services) |
ruleIds (and sometimes deviceIds for activity) |
An event describing the detected condition or state transition |
deviceCreated, deviceDeleted, deviceStatus |
Platform (Device Management) |
connectors, groupPaths (status only) |
A device lifecycle/status notification |
loraNetwork, loraGatewayStatus |
Network (LoRa) |
messageTypes (loraNetwork) |
A network‑level notification (e.g., UNCONFIRMED_DATA_UP, JOIN_REQUEST…) |
connectivityManagementPlatformEvent |
External platform (CMP) |
eventPayloadTypes |
A CMP notification (e.g., prepaid_bucket) |
How routing ties them together
-
Devices publish Data Messages; Live Objects enriches them (type=dataMessage when routed).
-
The platform may independently emit Events (not sent by devices) when rules or state machines fire, when device lifecycle changes, or when the network/external platforms notify something.
-
Your Action policy picks what to deliver:
-
Use a dataMessage trigger to route device data.
-
Use an event trigger (matchingFired, stateChange, deviceStatus, loraNetwork, …) to route notifications.
-
-
Filters use:
-
OR logic inside a list (e.g., connectors: ["mqtt","lora"]).
-
AND logic across different lists (e.g., connectors AND groupPaths).
-
