Service
Custom Niagara modules and drivers
When the driver you need does not exist, or the stock one does not do the thing the job actually requires. rt, wb and ux modules written against the Baja API, signed, and stamped to install across a mixed estate.
- Baja API
- rt / wb / ux
- Pure Java
- Signed modules
- Source on request
What this covers
Drivers for unsupported equipment
Plant, meters and controllers with a documented protocol but no Niagara driver — a serial or IP device, a vendor REST or MQTT API, a proprietary register map. Modelled as a proper network / device / point tree so it behaves like any other driver under Workbench, with discovery, ping monitoring and status propagation.
Station services
Components that live under Services and do work on a schedule or on
a change of value: exports, reconciliation, derived points, watchdogs,
bulk alarm shaping. Configured from Workbench like any stock service.
Integrations outward
Pushing station data to something that is not Niagara — a data lake, an analytics platform, a CMMS, a customer API — with buffering and retry, so a network outage does not silently lose a day of readings.
Extending what is already there
A subclass of an existing component, an extra slot on a point, a new action on a device. Often the cheapest route: reuse the stock driver, add the one behaviour the specification demands.
How the module is built
The constraints below are not preferences. They are what makes a module still work in three years, on hardware you have not bought yet.
| Constraint | Why it is held |
|---|---|
| No native code | Pure Java plus JS and CSS resources. A module with a native library has to be built per architecture, and will not load on a QNX/ARM JACE at all. One build runs on the controller and on an x86 Supervisor. |
| Stamped to the oldest version it must support | A module's declared dependency is a minimum, not a pin. Stamped to the oldest version in your estate it installs there and on everything above it; stamped to a newer one it is refused outright by the older stations. Stamping to your floor means one build covers a mixed estate. |
| Signed | Every module ships signed. Niagara 4 defaults to
moduleVerificationMode=medium, which requires a trusted certificate;
hardened sites run high, which requires a CA-issued one. Niagara 5
makes a valid signature mandatory with no grace period. |
| Java 21 clean | New work compiles clean under Java 21 and does not depend on
SecurityManager, which Niagara 5 removes. The same source keeps
building for Niagara 4. |
| Small | A JACE is an ARM controller with a fraction of a laptop's memory. Few modules, small jars, no framework hauled in for one utility method. |
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 written specification | Agreed before a price exists. Point model, protocol behaviour, failure behaviour, target Niagara version, target hardware. |
| The signed module | Built, signed and stamped to your floor version, with the palette entries and Workbench views the spec calls for. |
| An installation note | Which station, which service container, what to set, and how to verify it is working — written for the engineer who commissions it, not for a developer. |
| Source on request | Bespoke work can be delivered with source, so the module does not die if this practice does. |
Also
Other services
bajaux widgets
Custom Niagara web widgets built with bajaux and BajaScript: HTML5 dashboards, navigation, equipment views and charts, bound to live station ORDs and BQL.
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.
Which Niagara version to stamp a module for
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.
- Module development
- Mixed estates
- Build tooling
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
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
Getting data out of a Niagara station
REST, MQTT, a relational history database, file export or an HTTP client. Which suits which consumer, and what each one costs you to run.
- Integration
- Histories
- MQTT
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.