Service
Operator graphics and dashboards
Screens an operator can actually use, built as a set rather than as eighty copies. Standard PX sheets for the plant that recurs, bajaux web widgets where a view has to be responsive or do something stock widgets cannot, and one written convention so the next engineer inherits a standard.
- PX templates
- Relative ORDs
- bajaux
- BajaScript
- BQL history
- Graphics standard
One purchase, two ways to build it
A PX page built from stock widgets is quick and it is fine. It stops being fine when the client wants the view on a phone, when a tile needs behaviour no stock widget has, or when the graphics have to carry a brand. At that point you are either drawing the same screen four times at four sizes, or you are writing a widget.
bajaux widgets are ordinary HTML, CSS and JavaScript wrapped in a Niagara component. They drop into a PX view like any other widget, they render in the browser and inside Workbench, and one responsive component set covers desktop, tablet and phone rather than three layouts to maintain in parallel.
| Reach for a standard PX sheet when | Reach for a bajaux widget when |
|---|---|
| Your own engineers have to be able to open it in Workbench and change it without a developer. | The view has to work on a phone as well as a desk, and you are not willing to draw it three times. |
| The plant recurs: forty AHUs that want one sheet bound relatively, not forty sheets. | A tile needs behaviour no stock widget has — a chart from a BQL rollup, a commissioning mode, a control that validates before it writes. |
| The estate is being brought back to one convention after years of copied sheets. | The graphics carry a brand, or a client's, and a re-point of a token layer has to be enough to change it. |
Most estates want both, and that is the normal answer rather than a compromise. A bajaux widget drops into a PX sheet like any other widget, so the two are not alternatives so much as two layers of the same screen: standard sheets carry the plant your engineers maintain, and widgets carry the parts of the view that stock widgets cannot express. Pricing one job across both is simpler than pricing two.
The duplication problem
A site with forty AHUs typically has forty AHU sheets. They started as one sheet, copied. Then a set point moved on unit twelve, a label was fixed on unit nineteen, and someone added an override on the four units in the east block. Now a change to "the AHU page" is forty edits, and nobody is confident they all match.
A standard sheet solves this the way Niagara intends: one PX file per plant type, bound with relative ORDs, pointed at a different equipment node each time it is opened. Forty units, one sheet. A change is one edit and it lands everywhere at once.
Standard sheets: what is in scope
| Item | What it means in practice |
|---|---|
| A sheet per plant type | The HVAC plant that actually recurs: AHU, FCU, VAV, chiller, boiler, LTHW/CHW circuit, meter, zone, plant overview. Drawn once, to a consistent layout, with the same control affordances in the same place on every one. |
| Relative binding | Sheets bind relative to the equipment node they are opened against, so one file serves every instance of that plant type. |
| Navigation | A nav tree and landing pages — site, building, floor, plant — so an operator reaches any unit in three clicks and never needs the Workbench tree. |
| Alarm and status conventions | One colour and shape language for healthy, running, warning, fault and stale, used identically on every sheet. Defined in writing so it survives the next engineer. |
| A written graphics standard | The document your team applies on the next project: naming, layer structure, the token palette, what gets a standard sheet and what does not. |
| Retrofit of an existing estate | Auditing what is there, identifying the real variants behind the eighty sheets, and collapsing them onto the standard set — normally the larger half of the work. |
Widgets: what gets built
Plant and equipment views
AHU, chiller, boiler and zone views with live values, writable set points, command toggles and the alarm queue on one screen, each tile bound to its own ORD.
Summary dashboards
KPI tiles, plant status, equipment tables with fault and warning states — the view a facilities manager opens, rather than the one an engineer debugs from.
Charts from history
Trends driven by BQL rollups against your history database, not static artwork:
bql:history:HistoryRollup.rollup(history:RollupInterval 'hourly').
Navigation
Site, building and floor navigation that collapses to an icon rail with flyouts, so a tight PX viewport or a phone still gets the graphics at full width.
Commissioning affordances
A mode that surfaces the full ORD path under each tile, so the engineer commissioning the job can see exactly what every value is bound to without opening Workbench.
A themed component set
Tokens, not one-off CSS: colours, type, spacing and states defined once and re-pointed for light, dark or a client's brand without touching a component.
On browser support. Workbench embeds its own browser engine, and it lags the
one on your desk — current releases predate CSS :has() and container
queries. Widgets meant to be viewed inside Workbench are written to that floor
rather than to whatever Chrome shipped last month, which is the usual reason a widget
looks right in a browser and broken in a PX editor.
Deliverables
What you actually receive
Fixed price per deliverable, quoted against a written specification. No hourly billing, and no price before the scope is in writing.
| Deliverable | Detail |
|---|---|
| The standard sheet set | PX files, relatively bound, in a module or a shared folder, ready to point at any equipment node. |
| A widget set, not a page | Components with defined props and states, so the next twenty views are configuration rather than another quote. |
| Navigation | Landing and nav pages wired to the sheet set, collapsing to an icon rail where the viewport is tight. |
| Design tokens and a written standard | The token layer this site is built on, plus the conventions in writing — naming, layer structure, alarm and status language — so a theme is a re-point and the standard outlives the project. |
| A migration list | If retrofitting: which existing sheets map to which standard, and which genuinely need to stay bespoke. |
Also
Other services
Niagara 5 migration
Niagara 5 readiness audits and migration, including JACE 8000 to JACE 9000: which third-party modules survive the new runtime and mandatory signing.
Custom modules & drivers
Bespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
Station engineering
JACE controller and Niagara station setup end to end: platform commissioning, TLS, users, roles, BACnet and Modbus, tagging, histories, alarms, backups.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
IoT & LoRaWAN
Custom IoT and LoRaWAN builds: decoders that survive a station, a self-hosted ChirpStack server, MQTT, and the points or dashboards the readings become.
Integration audit
A fixed-scope paid audit of an existing Niagara integration: what talks to what, where it breaks, and what fixing it would take.
Protocols & data
Field protocol integration and the data behind it: BACnet, Modbus, M-Bus and MQTT, into a building system, a database or a dashboard.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
Pure Java, or it will not run on a JACE
A controller is an ARM host with a fraction of a server's memory. Native libraries, JNI and heavyweight dependencies do not survive the move from a PC.
- JACE
- Controllers
- Module development
One PX sheet for every AHU
The Px editor binds absolutely by default, which is why a graphic works for AHU-01 and nothing else. Relativised, one sheet serves the whole plant.
- PX graphics
- Standard sheets
- Reuse
Why an alarm never reached anybody
Detection, class and recipient are three separate objects in a Niagara station. An alarm goes missing wherever the chain between them is not linked.
- Alarms
- Station engineering
- Commissioning
Niagara schedules: special events and master copies
Special event priority is list order, a partly-filled special event falls back to the weekly schedule, and an imported schedule cannot be edited locally.
- Scheduling
- Station engineering
- Commissioning
A navigation tree that builds itself
Hierarchies generate the nav tree from tags and NEQL queries instead of hand-placed nodes — and the cache hides your edits until you rebuild it.
- Hierarchies
- Tagging
- Station engineering
Why a writable point ignores the value you set
Sixteen priority inputs, two of them reserved for right-click actions, a fallback underneath, and a BACnet scheme wired to none of it.
- Station engineering
- BACnet
- Commissioning
3D floorplan graphics, and what can actually bind to them
A 3D render is artwork made outside Niagara. What format it arrives in, what can bind to it, and why plan view wins for 200 zone temperatures.
- PX graphics
- JACE
- Workbench
What a PX page actually weighs, and the switch that halves it
A PX view ships about 2.3 MB of framework JavaScript before your graphic. Gzip is off by default, and /module/* bypasses the filter that would do it.
- PX graphics
- JACE
- Performance
Next step
Send one sheet and the plant list.
One of the duplicated sheets and the equipment schedule is enough to count what the estate actually needs: how many sheet types, which views want a widget instead, and what the set comes to as one fixed price rather than two quotes.