Definition
Event Stream (Event Stream) displays discrete events reported by devices such as alarms and faults, supports timeline display and filtering, and can be linked to device details and Work Order. It complements continuous data from Telemetry.
Event Types and Handling
The event stream covers device alarms, status changes, OTA progress, configuration changes, security events, etc. Events usually include timestamp, device ID, event type, level, description, associated data, and more. Device Management Platform collects events from MQTT, rule engine, internal system, etc., removes duplicates, aggregates them, and writes them into event storage. It supports filtering by device, product, time, level; real-time push and historical queries are also supported. Events can trigger alarm notifications, Work Order creation, downstream system Webhook and other interactions.
Integration with DMP
Platform displays event streams in scenarios such as Device Monitoring, NOC dashboards, and Fault Diagnosis. Events can be linked to device details, telemetry history, and Log Collection logs to form a complete fault context. When connected with Report Analytics, it can compute alarm trends, MTTR, and other operational metrics. Event data can be exported for audit and compliance analysis.
Use Cases
It is suitable for operations personnel to monitor device status in real time, perform fault tracing analysis, drive work orders with alarms, and calculate operational KPIs. Event streams are the key bridge from "data" to "action" in the Device Management Platform.
One event and a run of samples
An event stream stores facts that have already happened and are worth remembering on their own: a limit crossed, the limit cleared, authentication failed, an upgrade entered a step, a configuration was rewritten. Samples keep arriving on a schedule or on change. An event is recorded at the moment the condition becomes true, and it carries a type, a severity, and the object it belongs to. One event should be able to say which device, when, what happened, and whether a person needs to act. Writing every temperature report as an event floods the stream with samples, and the person on duty cannot find a real change of state. Keeping only samples leaves no separate record of when an alarm started, was acknowledged, or was closed, so later review can only guess from the curve. A time-series store is where samples belong. The event store is where discrete records that can be filtered belong. Line the two up by device identity and time. Neither one stands in for the other.
Changes worth storing on their own
What belongs in the stream is a change that will be searched, tied to a work order, or audited. Severity has to be split in advance. If every record shares one level, a filter does nothing. The deduplication window has to be defined in advance as well: another report of the same alarm code on the same device inside that window should update a count or the last time it occurred, not append rows without limit. Event time should be the time the device produced the event, and the platform should also keep the time it was received. When those two differ by a wide margin, the gap should be visible. Outside systems are notified with a webhook when that is required. A failed callback should be retryable, and the retry must not change the fact that the event is already stored. Raw debug output and high-frequency waveforms do not belong here. They are large and thin on meaning, and they should go through logs or samples. A message with no stable device identity should not be written first in the hope that the identity can be filled in later.
Clock drift and duplicate delivery
When the device clock drifts, events sort into the future or several days in the past, and a timeline filter looks like missing data. If only the platform receive time is trusted, events flushed after an outage pile onto the second the link returns, and the course of the failure is flattened. Duplicate delivery with no event identifier opens several work orders for one alarm. An identifier without idempotent handling still inserts a new row on every retry. If the edge and the platform each define severity on their own, a filter for critical misses some events and includes others. Putting upgrade progress, configuration changes, and security alarms in one default view, with no type filter, hides the items that need to be acknowledged. Once a downstream system has treated an event as handled, the original record should stay. Closing a work order must not delete the fact that it occurred. Archive indexes by device and type. Full-text search alone, on the day of a failure, also pulls unrelated debug lines. A query that crosses midnight needs a fixed time zone, or the same limit event will not line up with the samples from that time. Severity should not be rewritten after it is stored, or there is no way to know why it was treated as something that required action. An export to an outside system should carry the event identifier so the other side can drop duplicates.