Case study · Operator interfaces
Building automation graphics are usually drawn once, per site, by hand, and then maintained by whoever is still there. This is the other way round: a component set driven by a token layer, where a plant dashboard, a building summary and a navigation rail are configurations rather than drawings — and where the same source that would run on a station runs in the three demos below.
The systems involved
| The station | A Niagara station holding the point tree: ORDs to resolve, values to subscribe to, writable set points, alarm classes and histories. Everything on screen is bound to one of those addresses. |
|---|---|
| The view layer | Niagara's HTML5 profile, which serves a PX view by creating a DOM element per WebWidget and handing it to the AMD module named by the widget's js ORD. A bajaux widget is HTML, CSS and JavaScript wrapped as a Niagara component. |
| The browsers | An operator's browser, and Workbench's embedded one — which is older, so what renders in the first does not automatically render in the second. |
The difficulty
The widget runs inside somebody else's lifecycle. It is constructed, loaded, attached and destroyed by the framework, with a subscription model it does not own, on a controller with a fraction of a laptop's memory. A component that is correct but heavy is not correct.
Two browsers, one of which is a version behind. Workbench's embedded engine is older than the one on the operator's desk, so container queries and :has() are off the table in anything meant to look right in both.
Graphics have to be editable by the engineers who inherit them, and brandable by the customer, and responsive on a phone — three requirements that usually produce three separate screens to maintain.
The work
Colour, type, spacing and state live in a token layer. Toggling the theme re-points every component without one of them being touched, which is also why a customer's palette is a configuration rather than a fork.
A plant dashboard, a building summary and a navigation rail are JSON configurations over the same components — twelve tiles each bound to its own station ORD, a writable set point, plant commands, an alarm queue, an equipment table carrying fault and warning states.
A stand-in for baja resolves station:|slot:/… ORDs against an in-browser model of an air handling unit and implements the subscriber contract the widgets use. The widget source is not modified to run here — if it needed to be, running here would prove nothing.
Now
The three demos below are the deliverable, running in your browser against a simulated station. Move a set point and the model responds; toggle the theme and the whole set re-points; collapse the rail and it becomes an icon rail with flyouts so a tight PX viewport still gives the graphics full width. The station is simulated and nothing here is a client site — that part is stated on every demo page too, not just this one.
| Demos running on this site | 3, each the unmodified widget source |
|---|---|
| Tiles on the plant view | 12, each bound to its own station ORD |
| Themes | Light and dark, from one token layer |
| Native code | None — pure Java plus JavaScript, so one build runs on an ARM JACE and an x86 Supervisor |
| Module signing | Every module signed; stamped to the oldest station version it must support |
The deliverable, running
Not screenshots and not videos. Each one is the actual widget source that would run on a station, loaded by a minimal AMD loader against a simulated station that resolves ORDs and pushes changing values. Interact with them.
What is real and what is not. The widget code, the config files, the ORD strings and the rendering are exactly what a station would run. The station is a simulator: point values are generated by a small physical model in your browser rather than read from real plant, because publishing a live connection to somebody's building would be a poor idea. Nothing here is a client site.
Supply and return air temperature, fan power, zone CO₂, a fan-speed dial, a demand chart, a writable zone set point, plant commands and the alarm queue. Twelve tiles, each bound to its own station ORD — and the values are moving because a simulated station is pushing them. Move the set point and the plant responds.
The same discipline at building level, light theme: KPI tiles for demand, chilled water and LTHW, plant monitoring, and an equipment table carrying fault and warning states. Toggle the theme — every component re-points from the token layer without one of them being touched.
Site, building and floor navigation. Collapse it and it becomes an icon rail with flyout menus, so a tight PX viewport or a phone still gives the graphics the full width. Click through the sections.
Under the hood
The widget's own source runs here unmodified. If it needed rewriting to run in a page like this, running here would prove nothing.
Niagara's HTML5 profile serves a PX view by creating a DOM element per
WebWidget and handing it to the AMD module named by the widget's
js ORD. The demo does exactly that, with the widget's
rc/*.js and rc/*.css untouched.
A stand-in for baja resolves station:|slot:/… ORDs against
an in-browser model of an air handling unit — supply and return temperature, fan
speed, valve position, zone CO₂ — integrated on a tick, so values move the way
plant moves rather than jittering randomly.
The simulator implements the subscriber contract the widgets use, so a changing point pushes into the widget through the same path a station would use. Writes work too: move a set point and the model responds.
Stills
For anyone who would rather not run JavaScript, and for print.
The stack
| Framework | Niagara 4 and 5, Baja API, ux module profile, module signing and version stamping |
|---|---|
| Front end | bajaux, BajaScript, AMD modules, PX graphics and standard sheet sets, ORD binding, BQL history queries |
| Design layer | CSS custom properties as a token system, light and dark themes, responsive down to a phone |
| Targets | JACE controllers on ARM, Supervisor and PC stations on x86, Workbench's embedded browser |
Ours, all of it: the component set, the configurations, the simulated station and the harness that loads them. The framework, its AMD loader and its HTML5 profile are the vendor's, and we are not affiliated with them. The plant behaviour in the demos is a small model running in your browser, not a feed from a real building, and no screen on this page is a customer's.
Check it
Every link here opens the thing itself — a repository, a running demo, a note with the method in it.
Next step
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.