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

Data message

dataMessage

1

connectors, groupPaths, deviceIds, tags

Matching fired event

matchingFired

1

ruleIds

State change event

stateChange

1

ruleIds

Device activity event

deviceActivity

1

ruleIds, deviceIds

Device created event

deviceCreated

1

connectors, groupPaths, tags

Device deleted event

deviceDeleted

1

connectors, groupPaths, tags

Device status event

deviceStatus

1

connectors, groupPaths

Command status event

commandStatus

1

status

LoRa® network event

loraNetwork

1

messageTypes

LoRa® gateway status event

loraGatewayStatus

1

 — 

Connectivity management platform event

connectivityManagementPlatformEvent

1

eventPayloadTypes

Alarm event

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

  1. Devices publish Data Messages; Live Objects enriches them (type=dataMessage when routed).

  2. 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.

  3. 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.

  4. Filters use:

    • OR logic inside a list (e.g., connectors: ["mqtt","lora"]).

    • AND logic across different lists (e.g., connectors AND groupPaths).

Routing overview (schematic)

@startuml
top to bottom direction

skinparam shadowing false
skinparam linetype ortho

skinparam defaultFontSize 18
skinparam rectangleFontSize 18
skinparam ArrowFontSize 16
skinparam NoteFontSize 16

skinparam nodesep 30
skinparam ranksep 40

skinparam rectangle {
  BackgroundColor White
  BorderColor #888888
  RoundCorner 12
}

skinparam note {
  BackgroundColor #FFF8DC
}

' =======================
' SOURCES
' =======================

rectangle "Sources" {
  rectangle "Device /\nBusiness app" as DEV
  rectangle "LoRa network" as NET
  rectangle "Orange CMP (external)" as CMP
  rectangle "Device\nManagement" as DMGT
  rectangle "LoRa gateway" as GW
}

rectangle "Data Messages" {
  rectangle "type = dataMessage" as DM
}

rectangle "Platform detections" {
  rectangle "Simple Event\nProcessing" as SEP
  rectangle "State\nProcessing" as SP
  rectangle "Activity\nProcessing" as AP
}

' =======================
' EVENTS
' =======================

rectangle "Events" {

  rectangle "Data events" {
    rectangle "matching\nFired" as MF
    rectangle "state\nChange" as SC
    rectangle "device\nActivity" as DA
  }

  rectangle "Device events" {
    rectangle "device\nCreated" as DC
    rectangle "device\nDeleted" as DD
    rectangle "device\nStatus" as DS
  }

  rectangle "Network events" {
    rectangle "lora\nNetwork" as LN
    rectangle "loraGateway\nStatus" as LGS
    rectangle "connectivityManagement\nPlatformEvent" as CMPE
  }
}

rectangle "Action Policy\n(Triggers & Actions)" {
  rectangle "Trigger + Filters" as TRIG
  rectangle "Actions" as ACT
}

rectangle "Destinations" {
  rectangle "FIFO publish" as FIFO
  rectangle "HTTP push" as HTTP
  rectangle "Azure Event Hubs" as EH
  rectangle "Email" as MAIL
  rectangle "SMS" as SMS
}

' =======================
' FLOWS
' =======================

DEV --> DM : publish
DM --> SEP
DM --> SP
DM --> AP

SEP --> MF
SP  --> SC
AP  --> DA

NET --> LN
GW  --> LGS
CMP --> CMPE
DMGT --> DC
DMGT --> DD
DMGT --> DS

DM  --> TRIG
MF  --> TRIG
SC  --> TRIG
DA  --> TRIG
DC  --> TRIG
DD  --> TRIG
DS  --> TRIG
LN  --> TRIG
LGS --> TRIG
CMPE --> TRIG

TRIG --> ACT

ACT --> FIFO
ACT --> HTTP
ACT --> EH
ACT --> MAIL
ACT --> SMS

note right of TRIG
Filter logic:
- OR inside a list
- AND across lists

Examples:
- dataMessage: connectors, groupPaths,
  deviceIds, tags
- matchingFired/stateChange/
  deviceActivity: ruleIds
- deviceStatus: connectors, groupPaths
- loraNetwork: messageTypes
- CMP: eventPayloadTypes
end note

@enduml
Version 2026.9.1 • Updated date 2026-10-08_07:03:47_UTC