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. In practice that means one of four things: a legacy field bus from a system that predates Niagara and is still running the building, a serial or IP protocol with a published specification, a vendor REST or MQTT API, or a proprietary register map supplied by the manufacturer. 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 outward: MQTT topics with a payload decoder for structured payloads, LoRaWAN sensors arriving through a network server, cloud-side schemas built to match what the consumer expects — with buffering and retry, so a network outage does not silently lose a day of readings. Scoping one starts with the broker's actual topic tree, which our free read-only tools will print for you.
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. |
| Checked against Java 25 | New work is scanned against a Java 25 JDK — the runtime Tridium's current
Niagara 5 FAQ names — 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. |
After the job
Support afterwards is part of the offer
A module we wrote is ours to answer for: how it behaves on a station you are commissioning, a change inside the original scope, and a rebuild, re-stamp and re-sign when you move Niagara version. How support works.
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.
Operator graphics
Niagara operator screens built once and reused: standard PX plant sheets bound by relative ORD, bajaux web widgets and dashboards, and a written standard.
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 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.
Web, apps & DevOps
Web and app builds with the DevOps around them: front end, backend, the database under it, and the build, deploy and monitoring work that keeps it up.
Website design
Remote website design services for small firms: a few real pages, fixed price, and a measured handover — HTTPS, broken links, Lighthouse, page weight.
Spreadsheets & internal tools
An audit of the spreadsheet a team runs on — every rule it encodes, and which ones contradict each other — then one bounded slice of it as a web app.
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 four verification-mode values, what each demands of your certificate, and the permissions that force a signature check even in low mode.
- Module signing
- Certificates
- Deployment
What happens to third-party modules moving from N4 to N5
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.
- Migration
- Estate management
- Module development
What Java 25 does to Niagara's module permission model
Niagara's module permission model is built on Java's Security Manager. On a Java 25 JVM it cannot be installed, so the checks stop happening.
- Module development
- Station security
- Migration
What a static Niagara 5 module scan actually finds
Reading a module's bytecode against Java 25 gives a per-module answer. What it finds, what it cannot tell you, and the false alarms it avoids.
- Migration
- Module development
- Estate management
Bringing LoRaWAN and MQTT data into a Niagara station
Where abstractMqttDriver and jsonToolkit stop, and what LoRaWAN decoding, topic design, and store-and-forward buffering add on top.
- Integration
- LoRaWAN
- MQTT
How to build and load a custom Niagara 4 module
What a Niagara module actually is on disk, the two ways to build one, and the three Software Manager refusals that actually mean something.
- Module development
- Build tooling
- 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
BACnet MS/TP on a JACE
Baud, MAC address, Max Master and Max Info Frames. Four settings on one Link component decide whether an RS-485 trunk works, crawls or drops the token.
- BACnet
- MS/TP
- Commissioning
The certificate on a new JACE
Every station starts with a self-signed certificate it generated itself. What that is good for, what it is not, and what breaks on the day it expires.
- TLS
- Certificates
- Commissioning
What actually blocks an AX to N4 migration
A station cannot migrate until every module it uses has been refactored for Niagara 4 — and licences, users and permissions all change shape on the way.
- Migration
- Estate management
- Module development
What the Niagara MQTT driver will and will not do
It is licensed, it is capped below your licence, it is a client only, and its Discover button never contacts the broker.
- Integration
- MQTT
- Drivers
Commissioning a JACE-8000 without locking yourself out
The factory address, the passphrase with no recovery path, and the account you are made to delete — the Niagara 4 steps that strand a new controller.
- JACE
- Commissioning
- Deployment
What a BACnet discovery sweep actually tells you
Who-Is stops at the subnet, I-Am carries no device name, and an object list from a device that cannot segment has to be read one index at a time.
- BACnet
- Discovery
- Commissioning
Reading an unfamiliar MQTT broker in a building
A subscriber cannot list topics, the retain flag is how you tell a stored value from a live one, and a duplicate client ID disconnects someone else.
- MQTT
- Integration
- Commissioning
Reading a LoRaWAN payload decoder before you trust it
Eight things found by executing vendors' published JavaScript codecs, and what each one does to a Niagara point once the data lands.
- LoRaWAN
- Integration
- Commissioning
Next step
Send the protocol document and the point list.
A day of reading them is usually enough to say whether this is a driver, a stock feature you have not found, or a job that should not be a module at all. That answer costs nothing.