LiveView

LiveView is the runtime an operator sees: published views, live data, no design tooling.

https://qubiq.example.com/line1-hmi           the project's LiveView
https://qubiq.example.com/line1-hmi/login     runtime login, when identity is bound

What LiveView loads

On entry, LiveView fetches only what it needs:

Resource	Contents
Manifest	The project's structure — views, routes, settings
View resources	Each screen, by slug, on demand
Client scripts	Browser-side scripts the project defines
Gateway exports	The server-side entry points views may call

Views load lazily. A project with two hundred screens costs the same to open as one with two.

Live data

Telemetry arrives over a live connection from the realtime gateway. Sessions subscribe to the tags actually on screen, so fan-out cost tracks visible tags rather than namespace size.

Query bindings run against the project's query endpoint, which streams large result sets rather than assembling them in one piece — a table of a hundred thousand rows stays workable on a screen.

Gateway variable bindings (vars.<name>) work for operators and public visitors 1.0.8; a view reads only the variables its own project references. Historian charts read the project's designated historian connection 1.0.8 — before 1.0.8 a chart in LiveView could be refused, and fall back to a stale connection.

Widgets draw at the project's control size 1.0.8, the same as on the Designer canvas.

Docked regions Changed in 1.0.8

A view docked as the header, footer or a sidebar fits its region better:

• A region with no size set takes the docked view's design size — its width for a sidebar, its height for a header or footer — instead of a fixed default. A docked view still at the untouched 1200 × 800 keeps the old defaults.
• A region whose content does not fit scrolls, with a thin scrollbar, instead of clipping it. A collapsed icon rail is unaffected.
• A Vertical Menu in a docked sidebar fills the slot rather than claiming its own 240 px, so the right end of each row — highlight, badge, chevron — is no longer cut off in a narrower sidebar.
• A Horizontal Menu whose items do not fit scrolls sideways, one line per label.
• The toggles that open and close a region are small tabs on its edge, in the page theme.

In Layout Configuration, the routes list can be resized — drag its edge, use the arrow keys or Home/End, double-click to reset — and starts at 240 px.

Authentication

Two modes, chosen per project:

Mode	Behaviour
Public (default)	No login. Anyone who can reach the URL sees the screens.
Bound to a User Database	/{project}/login is required; runtime roles govern access and writes.

The binding is authoritative and set only through its dedicated endpoint — never through the project manifest, so an author cannot grant access by editing a resource.

Operator identity is entirely separate from engineer identity: a different user store, and a sign-in the Platform does not accept. An operator cannot reach the Designer even if their account is given every runtime role there is.

What a public screen can do Changed in 1.0.8

On a public project, a visitor who is not signed in — and an operator below the write baseline — can still run a named query that only reads: a single SELECT or WITH statement, with no SELECT INTO and no writing CTE (or, on MongoDB, no $out / $merge). Form dropdown options, an edit form's initial load and a script's SELECT therefore work on a public dashboard; before 1.0.8 they were refused. A named query that writes is still refused.

system.files.* works from browser scripts for a signed-in user; an anonymous visitor is refused, as the upload routes refuse one. A Platform user with Manage Designer who opens a public project is recognised as that user, rather than treated as anonymous and signed out of the Platform.

→ LiveView authentication

Writing tags from LiveView

Two independent server-side gates:

1. The tag must be writable.
2. The operator's level must meet the tag's write level (0–3).

Both are enforced in the server's write gate. Hiding a button is a usability choice, not a security control.

Revocation is prompt: suspending an operator or changing their roles takes effect within a short cache window, without waiting for their token to expire.

Session behaviour

Situation	Behaviour
Network drops	The WebSocket reconnects and resubscribes; the screen shows the connection state.
The platform restarts	Screens reconnect once it is back. A signed-in operator must sign in again, unless Keep sessions across restarts is on 1.0.8.
The sign-in expires	The operator is asked to sign in again; screen state is preserved where possible.
Operator suspended	Access is revoked within the revocation cache window.

While disconnected, values are marked stale rather than frozen — an operator must never be able to mistake a dead screen for a healthy one.

Kiosk deployment

QUBIQ has no kiosk mode of its own. A wall panel is a browser showing the project's LiveView URL, and locking it down is done in the browser and the operating system:

• Start the browser in its own kiosk mode at the project URL — for example Chrome or Edge with --kiosk https://<gateway>/<project>. That hides the address bar and the navigation buttons.
• Turn off the right-click menu, keyboard shortcuts and other ways out of the page with the browser's or the operating system's own policies. QUBIQ does not block them.
• Point the panel at the local gateway address so it does not depend on plant WAN routing.

On a touch screen, LiveView turns off the browser's double-tap zoom, so an operator who taps a button twice in quick succession does not leave the screen zoomed in with no way back.

Staying signed in

A panel on a public project has no sign-in to lose. On a project bound to a User Database:

• The operator's sign-in lasts 8 hours, and an open screen renews it on its own, so a panel left running stays signed in.
• A panel whose browser has been closed for more than 30 days asks for a sign-in again.
• Neither period can be changed, and the platform's session settings do not apply to LiveView.
• A platform restart signs the panel out, unless Keep sessions across restarts 1.0.8 is on — see Restarts and signing everyone out. Turn it on for unattended panels, so an update or a power cut does not leave them at the sign-in page. Sign out all ends every panel's session at once when you need to.

To take one operator's panel offline, suspend the account: access is revoked within the revocation cache window.

Showing health on a screen

A LiveView screen cannot show connection health or service status — no widget, binding or script reads them. Those live in the Platform, on the Connections page and in Services, for engineers.

What a screen can show is each value's quality. Bind a property to {{tag.<path>.quality}} and give bad and stale values a distinct appearance (see Quality propagation), so an operator can tell a dead value from a healthy one without a laptop.

Media and assets

Video streams and library images are served through QUBIQ, not fetched directly by the browser. The operator's device needs reach to the gateway only — not to the camera network or a file server.

→ Media servers

Performance on panel hardware

Symptom	Fix
Slow first load	Split large screens into embedded views; let them load on demand
Sluggish updates	Raise tag deadbands — most values do not need sub-second updates
Charts stutter	Fewer series, or a shorter window; let the historian aggregate
Video stutters	Use sub-streams for multi-camera tiles
Memory grows over a shift	Usually an unbounded table binding; page or limit the query

Differences from the Designer canvas

	Designer	LiveView
Editing	Yes	No
Data	Live	Live
Authentication	Platform user	Runtime user (or public)
Screens shown	Any view in the project	Those the runtime role permits
Chrome	Full Platform	The view only

Because both run the same components against the same data, "works in the Designer, not in LiveView" is nearly always a permission or access-policy difference, not a rendering one.

Next

→ Components · LiveView authentication