Service
bajaux web widgets and dashboards
Browser-native web widgets that live in your PX views and in your station's web UI. Bound to real ORDs and BQL history, responsive by construction, and themed so the graphics look like your company rather than like 2011.
- bajaux
- BajaScript
- HTML5
- Live ORD binding
- BQL history
- Light + dark
Why bajaux rather than more PX widgets
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.
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 |
|---|---|
| A widget set, not a page | Components with defined props and states, so the next twenty views are configuration rather than another quote. |
| Design tokens | A documented token layer — the one this site is built on — so themes and client brands are a re-point, not a rewrite. |
| Bound to your points | Built against your actual point naming and tagging, so it does not need rework on handover. |
| Palette entries | Dropped into a module palette so your engineers can place them in PX without involving anyone. |
Also
Other services
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.
PX graphics
Niagara PX graphics as a reusable template set: standard sheets per plant type, relative-ORD binding, navigation hierarchy and a graphics standard.
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and 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.
Niagara 5 migration
Niagara 5 readiness audits and migration: which third-party modules survive the new runtime and mandatory signing, and porting your modules so they load.
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
Next step
Tell us the version, the hardware, and what it has to do.
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.