Web-Based HMI: Build Operator Dashboards That Run in Any Browser
Traditional HMIs are a box on the wall: a dedicated panel, a proprietary runtime, and a licensing model per screen. Web-based HMIs replace the runtime with a browser. The dashboard is an HTML page; the PLC connection happens over WebSocket or HTTP; and any device with a browser (a kiosk monitor, a tablet, a phone, a laptop on the plant network) becomes an operator screen.
This guide explains how web HMIs work, the architecture that makes them cheap to deploy, and where they beat (and lose to) desktop HMI software.
How a Web HMI Connects to a PLC
There are two common patterns:
1. Gateway / server pattern
A gateway process talks to the PLCs over their native protocols (Modbus TCP, S7, EtherNet/IP, OPC UA) and exposes the data to browsers over WebSocket or HTTP. The browser page subscribes to variable changes and renders them in gauges, charts, and indicators. This is how most SCADA-style web HMIs work: the server does the protocol work, the browser just renders.
2. Direct WebSocket pattern
The PLC (or an edge runtime on the PLC) exposes variables over a WebSocket interface directly. The HMI page connects straight to it, no separate gateway process. This is the pattern behind single-file HMIs that export as one HTML document and connect to the PLC on load.
The direct pattern is the key to the cheapest possible deployment: the dashboard is a static file. No server-side application, no runtime to license, no installation on the operator machine.
WebSocket vs Polling
Web-based HMIs differ in how they get fresh values:
- Polling: the page asks "what's the current value?" every N seconds. Simple, works anywhere, but wasteful: most requests return unchanged data, and updates are delayed by up to one poll interval.
- WebSocket push: the server pushes a message the moment a value changes. Sub-second latency, no polling traffic, and the connection stays open for bidirectional control (buttons and setpoints flow back over the same socket).
For operator screens, push wins. A pump trip should flip the indicator immediately, not whenever the next poll happens to land. WebSocket is universally supported in modern browsers and works fine on plant LANs.
The Single-File Export Pattern
The most maintainable web HMI pattern for small systems: build once, export as one HTML file, deploy anywhere.
The exported file bundles the layout, the widgets, and the connection logic. You copy it to:
- A Raspberry Pi serving it on port 80 for wall-mounted kiosks,
- An ESP32 hosting the page over Wi-Fi for a machine-local screen,
- Any web server (nginx, a VPS, a NAS) for remote visibility,
- A USB stick, because there is no install step. Open the file and it connects.
No runtime, no dependencies, no browser plugins. The file is the product.
Deployment Targets Compared
| Target | Best for | Trade-offs |
|---|---|---|
| Raspberry Pi 5 | Wall-mounted kiosks, multi-screen plant floors | Needs a small agent to serve files; add a watchdog for kiosk resilience |
| ESP32 | Machine-local screens, retrofit panels, low-power | Tiny footprint; fine for one machine's dashboard |
| VPS / cloud | Remote monitoring, multi-site visibility | Never expose the PLC itself; expose only the read-only HMI |
| Local file | Engineering laptops, ad-hoc troubleshooting | Most portable; requires network access to the PLC |
When a Web HMI Beats Desktop HMI Software
- Cost. No per-screen runtime licenses. One file, any number of viewers.
- Maintenance. Update the file, redeploy once. Every browser gets the new version.
- Flexibility. Kiosk, tablet, phone, and desktop all render the same page.
- Retrofit. If the plant already has browsers and a network, you skip the HMI panel purchase entirely.
Where Desktop HMI Still Wins
- Hard-real-time control. A browser tab is not a safety-rated operator station. Critical e-stops and interlocks belong in hardwired or certified systems.
- Offline reliability. If the network drops, a desktop HMI keeps running. A web page needs its connection.
- Compliance. FDA 21 CFR Part 11 and similar requirements are easier to satisfy with a controlled, auditable client.
The practical answer: web HMIs are ideal for visibility and monitoring: dashboards operators watch, data they need at a glance, screens on the floor and in the office. Keep hardwired safety and interlocks out of the browser.
Building One Without a Web Dev Team
The barrier to web HMIs used to be HTML, CSS, and JavaScript, plus a WebSocket protocol you had to write by hand. That is gone. Modern HMI builders are drag-and-drop: pick a gauge, bind it to a PLC variable, arrange the screen, and export.
Voltrus HMI is exactly that workflow: a desktop designer where you build screens with gauges, charts, buttons, and indicators, bind them to PLC variables over a live WebSocket connection, then export a single HTML file. Deploy it to an ESP32 over Wi-Fi, a Raspberry Pi 5 via a small agent, or any web server, with kiosk mode, PIN-based roles, and multi-language screens included.
Build a Web HMI Today
Voltrus HMI is a drag-and-drop HMI designer that exports single-file dashboards for any browser. One-time purchase, no runtime licenses.
Explore Voltrus HMI →