One engineer · remote · every reply from the person who does the work
So the custom module will not load on the version you are moving to, and nobody kept the key it was signed with. The PX graphics nobody can edit are the ones operators look at all day. Nobody has inventoried what is actually installed, because the person who knew has left. That is the ordinary condition of a ten-year-old building management system.
We build the software that runs building automation, on the Niagara Framework. Custom modules and drivers, bajaux widgets, PX graphics, station engineering and Niagara 5 migration — for systems integrators, controls contractors and building owners. Pure Java and JavaScript, signed, and stamped to run on a JACE as readily as on a Supervisor.
Services
Each one scoped in writing and priced per deliverable. They are separable on purpose — a widget set does not require the station work, and an audit does not require either. New to the framework? Start with where Niagara sits in a building automation system.
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.
Read moreCustom Niagara web widgets in bajaux and BajaScript: HTML5 BMS dashboards, HVAC plant views, navigation and charts, bound to live station ORDs and BQL.
Read moreNiagara PX graphics as a reusable template set: standard HVAC plant sheets, relative-ORD binding, navigation hierarchy and a written graphics standard.
Read moreNiagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
Read moreCustom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
Read moreNiagara 5 readiness audits and migration, including JACE 8000 to JACE 9000: which third-party modules survive the new runtime and mandatory signing.
Read moreProof
The demos on this site are the real widget code, running in your browser against a simulated station that pushes live values. Click things. Break something.
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.
How we work
Scope, target Niagara version and target hardware agreed in writing before a number exists. No hourly billing.
Built against your actual point naming and tagging, so it does not need rework on handover.
Every quote names the Niagara releases the module is tested against and how long breakage caused by a point release is fixed at no charge. A module that quietly stops working after a security update is not finished work.
Bespoke work can be delivered with source, so you are not dependent on us to keep it alive.
Niagara 5
Niagara 5 moves off Java 8 (Tridium's current FAQ says Java 25), makes a valid module signature mandatory with no grace period, and does not run on JACE-8000 hardware at all. Every third-party module in an estate has to be recompiled and re-signed before it will load.
The modules that hurt are not the ones from vendors still trading. They are the bespoke ones written for a site years ago by somebody who has moved on — and they are only discoverable by looking.
| Java 8 → 21 | Recompile; SecurityManager is gone. |
|---|---|
| Signing | Mandatory, no grace period. Unsigned will not load. |
| Hardware | JACE-8000 cannot run N5. Controller swap per node. |
| Themes | N4 Zebra and Lucid are not carried forward. |
| N4 support | To 2028. No cliff in 2026. |
| Why now | The audit feeds the capital plan, not the other way round. |
Notes
Narrow Niagara questions, written from the framework rather than from memory. No pitch in them — if a note means you do not need to hire anyone, that is a good outcome. All notes →
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
A module with no Niagara 5 build can stop the migrator outright, and one that has a build can still fail to load. What breaks, and why.
Where to start
In ascending order of how much of your time they cost.
There are 34, on narrow Niagara questions, written from the framework rather than from memory. No form, no email address, no follow-up. If a note means you can do the job yourself, do the job yourself.
The widgets on the Work page are the module code itself, running in your browser against a simulated station that pushes live values. Change the theme, turn the ORD overlay on, watch it re-render. Nothing is a screenshot.
A Niagara 5 readiness audit is the usual starting point when nobody knows what is installed: an inventory of every third-party and bespoke module in the estate, and what each one needs before it will load. Fixed price, and it stands on its own if you go elsewhere afterwards. Send a module list, or say you do not have one — not having one is the normal case.
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.