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 HVAC plant sheets, relative-ORD binding, navigation hierarchy and a written 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, including JACE 8000 to JACE 9000: which third-party modules survive the new runtime and mandatory signing.
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
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
Next step
Send one PX sheet and the view you wish it were.
A screenshot of the graphic you have now and a sentence about what it should do instead is enough to scope a widget package: how many components, which are new, which are re-skins, and what it comes to as one fixed price.