Definition
Device Monitoring (device monitoring) provides operation and maintenance personnel with real-time Connection Status (connection status), Telemetry (telemetry data), Event Stream (event stream) and other multi-view displays. Supports device list, map distribution, real-time curve, Dashboard, NOC large screen, Grafana/BI docking.
Monitoring views and capabilities
Device monitoring covers list view (online/offline status, last online time, Device Health Score), map view (geographical distribution, aggregated display), real-time telemetry curves, Event Stream, Device Shadow, and more. It supports filtering by product, group, and tag; supports multi-device comparison and historical playback. Data comes from access layers such as MQTT, Time Series DB, and the rule engine. In coordination with Remote Diagnosis, diagnostics and Log Collection can be initiated directly from monitoring.
Integration with DMP
The Device Management Platform treats device monitoring as a core capability, supporting NOC operational dashboards, custom dashboards, and report analytics. It supports connecting monitoring data to BI tools such as Grafana and Power BI. Alerts can trigger work order creation and push notifications. Monitoring is the core entry point for operations personnel to perceive device status and is the foundation for ensuring SLA.
Use Cases
Suitable for 24/7 operation and maintenance monitoring, quick fault detection, device health trend analysis, and maintenance KPI statistics. Device monitoring is a key capability of the Device Management Platform from "connection" to "visualization".
What the list, the curve, and the events each answer
Device monitoring means giving operations several views that complement each other. The list answers which unit is in which connection and health situation. The curve answers how a property changes over time. The event stream answers which discrete facts happened in between. The map answers roughly where they are distributed. These views should point at the same device identity, and they should not stand in for one another. A short disconnect that is invisible on the curve may exist only in the events. Online on the list does not guarantee that every property is still updating. Monitoring assumes the access layer has already stored sessions, telemetry, and events where they can be queried, and that the query scope is constrained by permission. Seeing another project’s counts on an overview without data permission leaks the boundary.
What belongs in everyday monitoring is a phenomenon a person needs to react to on the scale of minutes to hours. Comparison over a longer period should go to a report, not draw a year of raw points on a live chart. Opening one device’s detail should show the latest connection changes, key properties, and unacknowledged events together, so time does not have to be matched across several pages. Split from the rule engine, monitoring is responsible for showing the situation to a person, and rules are responsible for notifying or opening an order when a condition is met. If the two sides each write their own threshold, the screen looks normal while an alarm has already gone out, or the reverse. A wallboard is only one layout of monitoring. The definition still has to match the list.
Abnormalities missed by watching only the online rate
Watching only the online rate misses “connected, but the data is wrong.” A sensor stuck on the same reading, a unit suddenly ten times larger, and events that stop while the heartbeat continues can all leave the online metric looking fine. Another miss is looking only at the current value and not at gaps. The curve connects a break with a straight line, and an interruption is drawn as steady. When a map aggregates too far, a fault at one site is diluted into the normal color of a whole city. A filter left on the previous group makes the next person on shift think they are looking at every device.
If the time range defaults to the last hour, a low-frequency device shows as having no data and is misjudged as a fault. Comparing several devices requires aligned time zones and sampling, or the order is an artifact of the drawing. Jumping from monitoring to remote diagnosis should carry this device’s identifier and the point in time, not make the person search again. A terminal already retired in the device lifecycle should not keep appearing in the default list of in-service monitoring, or the offline number is raised by stock and disposed devices. After an abnormality is found, monitoring’s job is to locate the object and the time. The conclusion still has to go back to the raw message and the site. A problem should not be closed from a chart alone.
How to read a gap that was drawn as a straight line
When a monitoring chart connects two sample points with a straight line, the blank in between is read as steady running. For a device that reports only once an hour, most of that line is drawn, not measured. A disconnect, a stop in reporting, and a value stuck on the same reading should leave a gap or a mark on the chart, not be filled into a continuous curve. Online on the list also cannot replace the curve. When the heartbeat is still there and a property has already frozen, the online ratio still looks fine. A map that folds many devices into one color dilutes a fault at a single site into the normal color of a city. If the default time range is the last hour, a low-frequency device often shows no data, and the person coming on shift easily treats it as a new fault.
A filter stays on the group of the previous person on duty. A newly opened page is not necessarily every in-service device. If a retired record still appears in the default list, the offline number is raised by stock and disposal. Entering diagnosis from monitoring should carry the device identifier and the time of the problem, not make the person search again. If rule alarms and on-screen thresholds are each written on their own, the chart looks normal while an alarm has already been sent, or the chart looks abnormal and nobody is notified. Monitoring is responsible for pointing at the object and the time. It does not replace the raw message, and it does not replace a measurement on site. Closing a problem should be able to return to the raw points of that period, not leave only a chart that has already been connected.