Overvis HMI overview

Overvis HMI is a cloud product for remote access to industrial equipment over Modbus TCP. Users organize plant connectivity and operator UI inside workspaces: each workspace holds Modbus endpoints (connections), a tree of parameters, dashboards that show live values and accept writes according to access roles, and report presets (history report shells authored in Setup).

What you get

Piece	Role for the user
Account	Email-code and passkey sign-in, optional authenticator protection, profile/email/security settings
Workspace	Named project container; a user can belong to several and switch among them
Endpoint	Named Modbus TCP connection (host, port, TCP options); enable/disable; live connection status
Parameter	Named value mapped from const storage, a formula, or Modbus registers/coils on an endpoint
Branch	Folder-like node in the parameter tree (forest of roots and children)
Dashboard	Operator UI page (built module) listed in the workspace nav; can be enabled/disabled
Report preset	History report recipe (snapshots, chart + layout, time range, flags, CSV config) authored in Setup and opened as a report page
Automation	Automation or alarm rule that runs in the cloud when its triggers fire
Edge program	Program that runs on an MC252 controller
Files	Workspace files under uploads/, listed in Setup → Files
Setup	Configuration area for dashboards, endpoints, parameters, reports, automations, files and stored data, with the activity history
API key	A personal API key for scripts and integrations, or a workspace API key for a local workspace; the browser uses your sign-in
AI assistant	Help panel in the cloud app that answers questions and can work in your workspace with your role

The cloud UI is available in English, Polish, German, Ukrainian, and Russian. This documentation set is English-only for now.

Mental model

Account
  └── Workspace(s)
        ├── Endpoints (Modbus TCP connections)
        ├── Parameters (tree under branches)
        ├── Dashboards (operator views)
        ├── Report presets (history report recipes)
        ├── Automations and alarm rules
        ├── Edge programs (run on MC252 controllers)
        └── Files (mirrored under uploads/)

• There is no separate “device” entity. Physical devices appear as endpoints plus parameters grouped under branches (and optional tags).
• Live values are always strings in the UI. Some types also expose a precise numeric form at runtime.
• Setup changes configuration; only editors, admins and owners can open it. Operator use is reading/writing live parameter values on dashboards (and related UI), subject to role gates.

Cloud app vs local pull

Cloud (browser)

Signed-in users open the cloud web app. After sign-in it opens your active workspace: the one you used last when you still have access, otherwise the first workspace in your list.

Only the cloud app has:

• The workspace switcher and the Create workspace dialog
• Account settings (profile, security, email, notifications, billing, API keys, history)
• Workspace settings for every member. Editors, admins and owners also get local development and CLI keys. Admins and owners manage members, rename the workspace, set limits, and see billing. Only the owner deletes the workspace or changes its billing account.
• The AI assistant panel

The workspace pages, Setup, and dashboards are the same in the cloud and in a local workspace.

Local workspace (CLI pull)

Editors, admins or owners open Workspace settings → General → Develop locally, copy a short-lived CLI command, and run it in an empty folder. The command creates a local web app, a setup.db database with the workspace setup, and the dashboard sources under src/dashboards/, and signs the app in with a workspace API key that reaches only that workspace.

A local app:

• Talks to the same cloud API with that API key instead of a browser session
• Opens the same workspace, Setup, and dashboard pages at the same paths
• Shows your local dashboard sources when you have them, otherwise the published dashboard
• Is bound to the one pulled workspace: it has no account settings, no switcher across workspaces, and no assistant panel

Editors, admins and owners send their local setup, file, and dashboard changes back with hmi push, which checks each entity and file for conflicting changes (see Sync push, pull, and revisions). Pull and push let an engineer edit setup and dashboard code on a laptop, while the cloud keeps accounts, live connections, and shared access.

Access roles

Every membership has one of five roles: View only, Operator, Editor, Admin, and Owner. Each role adds to the one before it. Viewers watch; operators also write live values on dashboards; editors change the setup and dashboards; admins also manage people, settings, and stored data; the one owner also controls billing and deletion. Splitting operation from setup this way lets a plant’s operators work on dashboards without the risk of changing the configuration behind them. The full matrix is in Workspace roles.

Endpoints in one paragraph

An endpoint is a Modbus TCP connection of one of three kinds: PIN (a supported Overvis device, paired by the code on its label), WireGuard (a device on the Overvis VPN, identified by its public key), or TCP (a hostname or IP reachable from the Overvis server). Each has a port (default 502), an optional description, and TCP tuning (timeouts, keepalive, queue limits, etc.). Disabled endpoints stop participating until re-enabled. The status page shows connection state (Connecting / Connected / Disconnected / Error / Unknown) and a live traffic log. Modbus parameters refer to an endpoint and add the unit ID and addresses of the device behind it. See Endpoints and Configure endpoints.

Parameters in one paragraph

A parameter belongs to a branch, has identity fields (name, mnemonic, units, tags, icon, description), a source (const, calc, or modbus-tcp), and a value type that turns the raw value into the string shown in the UI. Names, descriptions, units, mnemonics, and value-type labels can carry a text per language. Modbus sources pick an endpoint, unit id, table, and addresses. Branches form a forest; display names are not unique. In Setup you can create, rename, and delete branches, and create, edit, and delete parameters; the Branch field of a parameter moves it to another branch. Setup cannot reorder items or move a branch under another parent.

Dashboards in one paragraph

Dashboards appear in the workspace sidebar. Opening one shows its page in your theme and language, set up by its JSON configuration. In Setup → Dashboards you create, edit, delete, enable, and disable dashboards. In an empty workspace, editors, admins and owners are prompted to open Setup or pull locally; viewers and operators see only the empty-state message.

AI assistant

In the cloud app, AI in the header opens the assistant. It answers in your language from this documentation and can read and change your workspace with your own role. Changes wait for your Allow unless you auto-allow them. Local workspaces have no assistant. See AI assistant, or try it in the tutorial Use the Overvis HMI assistant.

Where to read next

Topic	Doc
Sign-in, notifications, API keys	Manage your account and access
What each role can do	Workspace roles
Balances, top-ups, and charges	Billing accounts
Create / switch / delete / pull	Manage workspaces
A first workspace, step by step	Build your first workspace
Modbus connections & status	Endpoints
Parameter tree, sources, live I/O	Parameters
Dashboards	Dashboards
Common problems	Troubleshooting
Local pull / CLI / sync	Pull and scaffold a local workspace
Integration API	API reference
Open packages (shared, workspace-ui, CLI)	shared package
Account, sign-in, and settings pages	Account pages
Workspace + Setup + local parity	Workspace pages

Dates and locales

UI timestamps use YYYY-MM-DD HH:mm:ss, independent of language. General UI timestamps use the browser’s timezone. Report timestamps use the report’s configured timezone; choosing browser uses the viewer’s timezone. UI language (translation catalog) is separate from the Notification language under Account settings → Notifications.

Choosing workspace boundaries

A workspace is the unit of access and navigation: everyone in it works with the same endpoints, parameters, and dashboards, within their role. So the useful question is who should see what together.

• One workspace per physical site gives a clear operating boundary, with the site’s own endpoints.
• One workspace per customer or line isolates access: a customer’s people never see another customer’s plant.
• A separate staging workspace lets engineers work as editors on a copy while operators stay on the production workspace.

Putting unrelated plants into one workspace puts them into one navigation tree and one member list. That is rarely what you want. A user can belong to many workspaces and switch among them, so splitting costs little.

Soft-disable pattern

Endpoints, dashboards, and parameters share a soft-disable idea: when disabled, they remain in Setup but stop participating in normal live use until re-enabled. Setup lists show a Disabled badge. Endpoint status also shows when the endpoint was disabled. Disabling one parameter does not disable others; calculated parameters that depend on a disabled input fail when evaluated.

Terminology

Overvis term	Notes
Workspace	The container for one site, line, or customer
Endpoint	A connection to a device; there is no separate device entity
Parameter	A named value; tags are a field on parameters, not separate entities
Setup	Workspace configuration; separate from Account settings
Owner	The highest workspace role, one per workspace; an Admin can do everything else, but only the owner deletes the workspace or moves its billing

FAQ (short)

Is Overvis only Modbus? Endpoints connect over Modbus TCP (PIN, WireGuard, or TCP). Parameters may also be constant or calculated without a device.

Do I need a local install to operate? No. Operators use the cloud web app. Local pull is for engineers editing setup/dashboard sources.

Where do device manuals fit? Register maps come from the device manufacturer’s documentation. For supported device models, a parameter template already holds the map.

Can one workspace talk to many PLCs? Yes — many endpoints, each with its own host/port; parameters pick which endpoint to use.