Dashboards overview
Ta treść nie jest jeszcze dostępna w Twoim języku.
A dashboard is the operator’s view of a workspace: a page in the sidebar that shows live readings, history, and controls for the equipment the workspace connects. It looks and behaves like the rest of the product, follows the operator’s theme and language, and works with the operator’s own access to the workspace.
Dashboards work through parameters
Section titled “Dashboards work through parameters”A dashboard never talks to devices directly. It reads and writes parameters, and Overvis HMI does the device communication:
Endpoints → connectivity (the devices and gateways HMI reaches)Parameters → values (where each value comes from and how it is decoded)Dashboards → presentation, and writes to parametersThis keeps device access, permissions, and history in one place. One parameter feeds Setup, dashboards, and reports alike, and a write from a dashboard is checked like any other write. Moving a value to another register changes the parameter, not every dashboard that shows it. MC252 and MC261L controllers are the exception: a dashboard can also call their device API, under the same permission checks.
Ways to make a dashboard
Section titled “Ways to make a dashboard”Not every dashboard needs code. Setup offers templates:
- Value tiles: a board of live values, gauges, trends, and controls that editors arrange on the board itself.
- Canvas: a drawing of equipment, edited in the browser, with parts that follow live values.
- Map: named sites on a map.
- Create from report: a dashboard that shows an existing history report.
- Empty: a blank React dashboard for anything else, written in a pulled workspace.
The assistant can also build dashboards: for one device model, such as a relay or a refrigeration controller, or composed answers such as analyses, proposals, and cost estimates. A dashboard for a device model can be added before the device’s parameters exist; it then shows which bindings are missing.
Configuration instead of fixed IDs
Section titled “Configuration instead of fixed IDs”Each dashboard has a JSON configuration, and the dashboard describes its shape. Plant-specific choices, above all which parameters the dashboard shows, live there rather than in its code. A copy of the dashboard then serves another site once its configuration changes, and an editor can rebind a parameter in the dashboard’s settings without a developer.
Parameters are bound by their IDs, because names are not unique and can change. Bindings work best grouped by meaning, such as readings and thresholds, because a named key says what the dashboard expects. Secrets do not belong in the configuration: every browser that opens the dashboard receives it, and the dashboard already works with the viewer’s access.
From source to operators
Section titled “From source to operators”A dashboard written in code is developed in a pulled copy of the workspace, on your own computer. The local app shows the same workspace pages as the cloud app and runs the dashboard’s source, reloading it as you edit. Publishing builds and checks the dashboard and uploads it; operators in the cloud app then see the published build:
Create in Setup (pick a template, or create from a report) → Pull the workspace → Edit sources under src/dashboards/<id> → Push (build, check, and upload) → Operators open the dashboardThe steps are in Create and publish a dashboard and Develop a dashboard locally. What a dashboard receives from the app, and what it must provide, is in the dashboard host contract.
What dashboards are for
Section titled “What dashboards are for”Dashboards are operator views: status boards, setpoint panels, device-specific HMIs, and fleet overviews. They also present composed answers, such as analyses, proposals, or cost estimates, that combine narrative, tables, diagrams, charts, and interactive scenarios, with or without live data; see document dashboards.
Editing parameters, endpoints, and the rest of the workspace setup belongs in Setup, which only editors, admins, and owners can open. A dashboard that copies those editors would duplicate their checks and drift from them.
Disabling and deleting
Section titled “Disabling and deleting”A disabled dashboard leaves the sidebar but keeps its place in the catalog, its files, and its direct link, as disabled parameters and endpoints do. That makes disabling the safe way to take a dashboard out of service. Deleting removes the dashboard, and the next pull removes its local files. A dashboard that should exist twice is duplicated: each copy owns its own sources and configuration.