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.

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.

→ 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 — a restart ends every sign-in.
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.
• Every platform restart signs the panel out, and nothing turns that off. Plan for an update or a power cut to leave the panel at its sign-in page.

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