Definition
Dashboard displays summary metrics such as the number of devices, online rate, and today's alerts by dragging and dropping components. It supports custom layouts and large screen display modes. It can interface with NOC large screens, Grafana, and BI.
Component Types
Dashboards typically include: statistic cards (total devices, online devices, number of alerts, number of OTA tasks, etc.), real-time charts (online rate trends, alert distribution, device geographic distribution), tables (latest alerts, offline device list), and maps (device location distribution). It supports drag-and-drop layout, component resizing, and data refresh interval configuration, meeting display needs for different roles and scenarios.
Large Screen and NOC Mode
For operation centers, command centers, and similar scenarios, large screen display mode is supported: full-screen layout, dark theme, automatic rotation, and highlighting of key metrics. Combined with the NOC network operations center large screen, it can centrally display the operational status of devices across multiple products and regions, supporting 24/7 operations monitoring and emergency response.
Data Sources and Extensions
Dashboard data can be obtained from platform-built APIs or Event Stream event streams. It supports interfacing with external BI tools such as Grafana, Tableau, Power BI to merge device data with business data, enabling richer analysis reports and self-service exploration.
Why card totals and device details disagree
A dashboard means gathering device metrics, at one moment and inside one permission scope, into cards and charts that can be scanned, to see whether this set looks abnormal. It does not replace the raw record of a single device. Every card needs a clear statistical scope: which products, which groups, whether not-yet-activated devices are included, and what time the figures run until. Once that scope disagrees with the viewer’s data permission, two people see two totals and both think they are looking at everything. The refresh cycle is part of the definition. An online count refreshed every ten seconds and an alarm count refreshed every hour cannot be drawn as facts that happened in the same second.
What belongs on a dashboard is a summary that already has a stable definition and needs to stay on screen. A one-off filter used for a temporary investigation should stay in the device list, not become a public card whose definition anyone can change. Wallboard mode also has to consider viewing distance. Keep only a few key numbers, and leave detail in a list that can be opened. A card related to connection status should say which rule set the offline threshold comes from, or the offline count on screen cannot be checked against the alarm rule. Permission trimming should take effect at query time, not by calculating the full total first and hiding it in the browser, or the interface still exposes counts of devices the viewer may not see.
When a wallboard refresh leaves old alarms on screen
A likely mistake is each component keeping its own cache. The map is still the morning distribution, the alarm list is already the afternoon, and side by side they look like the same moment. Another mistake is a drill-down that does not carry the card’s filter. Clicking “offline in a region” opens every device. Mixed time zones make “today’s alarms” jump around midnight. Overlaying a live stream and a historical summary on one chart without a label makes the viewer treat a backfilled historical point as a fault that just happened.
When a template is copied to a new project, if the data source still points at the old product, the wallboard quietly shows the wrong object, because the title has already been changed to the new project. When a number looks wrong, it should be possible to drill into the list of devices that entered the calculation, not only to see a total. If device health score is shown as an average, a few very poor devices are diluted by the many normal ones, and the screen still looks fine. For a situation that needs intervention, the count and the list of low-score devices are more useful than an average pulled upward. A layout change should not change the metric definition. A change of definition needs its own version, or yesterday’s screenshot and today’s cannot be compared.
Why people with different permissions see different totals
A device total on a dashboard means something only after the statistical scope is written down. One person can see the projects they are responsible for, another can see every product, and different card numbers are normal, provided each person’s scope can be read on the card. If the scope is hidden inside the refresh logic, people cite each other’s screenshots and argue about whether devices increased or decreased. A drill-down must carry the same scope and the same cutoff time. Opening the list from alarms in a region, if the region condition is lost, makes the list an order of magnitude larger than the card, and the person thinks the card was calculated wrong. If a map, a curve, and a table refresh at different intervals, each should be labeled with its own data time when they are watched together. They cannot be assumed to be a snapshot of the same second.
Summaries such as an average score or an online ratio are especially good at hiding a few severe objects. A screen that needs intervention should also give the count below the threshold, and allow that list to be opened. After a template is copied to a new project, check whether the data source still points at the old product. Changing the title does not change the query. If a cache crosses permissions, an administrator who logged in first may put the full total into the cache, and a project member who logs in later may see a total that is not theirs. The first step when a number looks wrong is to check scope, cutoff time, and definition, not to conclude at once that the site changed by the same amount. Layout can be adjusted for a wallboard. The metric definition should keep its own version.