Questions we get asked before a first project

In the supervisory layer, above the field controllers and below whatever the client reports on. It is the vendor-neutral layer that talks BACnet, Modbus and the rest, normalises the points into one tree, and serves the graphics operators look at. We build the software in that layer: drivers, modules, graphics and station work. There is a longer explanation, with a BMS-to-Niagara vocabulary map, on the building automation page.

Both. Most production work is on Niagara 4, because that is what is installed. New code is written so the same source also builds for Niagara 5 when you need it. Modules are stamped to the oldest Niagara version you have to support, not to the newest one available, so one build covers a mixed estate.

Yes. Everything is pure Java plus JavaScript and CSS resources, with no native code, so one build runs on an ARM JACE and on an x86 Supervisor without a separate compile. Modules are kept small deliberately, because a JACE has a fraction of a laptop's processor and memory.

Yes. Niagara 4 ships with niagara.moduleVerificationMode=medium, which requires a certificate the host trusts, and hardened sites run high, which requires a CA-issued one. Niagara 5 makes a valid signature mandatory with no grace period. Tell us which mode your hosts run and the signing arrangement is matched to it before delivery, not after.

For bespoke work, yes, on request and in scope. The reason is self-interested as much as generous: the single most expensive problem in this market is a module whose author has disappeared and whose source nobody holds, and we would rather not add to the pile.

Fixed price per deliverable, quoted against a written specification. No hourly billing. The specification comes first and is yours whether or not you proceed; if scope changes, the specification changes first and the price follows it.

A PX sheet is a graphic your own engineers can open and edit in Workbench. A bajaux widget is HTML, CSS and JavaScript wrapped as a Niagara component, which drops into a PX sheet like any other widget. Use PX where engineers must be able to edit without a developer; use bajaux where a view has to be responsive, carry a brand, or do something no stock widget does. Most sites want both.

If the source exists, yes — porting, re-signing and a regression pass are routine. If the source is gone and the vendor is not coming back, the honest answer is usually to rebuild the function rather than reverse-engineer a jar, and that gets said plainly at quoting time rather than discovered halfway through.

A machine-generated inventory of every third-party module across the estate — vendor, version, signature state and stamped Niagara version — with a verdict per module of rebuild, port, replace or at-risk, the reasoning behind each verdict, and a sequencing plan covering what must happen before any controller is swapped.

Probably, and there is a free way to find out, but nobody can honestly say certainly yet. What can be measured today is whether a module's bytecode survives the move off Java 8: the jars are readable, a Java 25 JDK is runnable, and every removed API leaves a fingerprint in the class that calls it. Run that across a well-built module and the usual result is no blockers at all — most findings sit in bundled third-party libraries rather than in the module's own code, so the work is a recompile, a library bump and a re-sign rather than a rewrite. What that cannot tell you is anything about Niagara 5 itself. There is no Niagara 5 build to test against, so any readiness statement — ours or a vendor's — is static analysis against Java 25, not a test on a Niagara 5 build, and a module that scans clean can still need work against the new SDK. Send a module list and the scan comes back free, with that distinction written on it rather than glossed over.

Yes. Check the stock abstractMqttDriver and jsonToolkit first — a plain MQTT client and structured-payload parsing have been in the box since 4.8, and a lot of projects need nothing past that. Custom work starts where those stop: a LoRaWAN network server feeding into Niagara, a payload decoder for a shape jsonToolkit cannot unpack on its own, topic and schema design, and store-and-forward so a dropped link does not lose readings. Send a payload sample from the network server or a screenshot of the current topic tree and it is a day's reading to say what stock covers and what does not.

No. Niagara 4 is supported to 2028. Niagara 5 is expected to reach general availability around the end of 2026. Dates published around licence transfer are commercial deadlines for a discount rather than a point at which anything stops running. Plan for the migration; do not let anyone panic you into it. Confirm current dates with your distributor.

No, and deliberately so. The widget code, the config files and the ORD strings are exactly what a station would run, but the station behind them is a simulator running in your browser. Publishing a live connection into somebody's building would be a poor idea.

BMS systems integrators and controls contractors who need a module or a widget set they do not have time to write, distributors whose customers are asking for something outside the stock catalogue, and building owners with an estate and a migration to scope. Work is remote.

Yes, and for module vendors and distributors that is the normal shape. The deliverable carries your module name, your vendor string and your certificate; the specification and the installation note are written to be handed to your customer with your logo on them; and there is no requirement to disclose who wrote it. A mutual NDA before the first technical conversation is fine and is signed, not negotiated.

That is the work this practice was set up to do. A catalogue port is priced per module rather than as one lump, so it can be staged: the two that are most at risk first, the rest once the pattern is proven on those. Each module comes back recompiled for the Niagara 5 runtime, re-signed to your certificate, with a dependency audit, a regression pass against your own test station, and a readiness statement you can publish to your customers.

Only to get you off it. AX is end of life, so the honest answer is that new modules and new graphics should not be written against it. What is worth doing on an AX site is the inventory: what is actually running on the station, which of it has a Niagara 4 equivalent, which of it was bespoke and has no source, and what the building automation estate has to look like on the other side. That inventory is the same piece of work as a Niagara 5 readiness audit, one framework generation earlier.

No. This is an independent development practice. Niagara, Niagara Framework, JACE, Workbench and Tridium are trademarks of Tridium, Inc., used here only to describe what the work is compatible with.

A widget or a Workbench tool is quoted at two to four weeks from signed specification to delivery. A driver depends almost entirely on the protocol document: a published specification with a clean register map is weeks, a proprietary one that has to be observed on the wire is longer, and which of those you have is established before a price exists. A readiness audit is the fastest thing here — it is mostly tooling — and a station build is governed by site access rather than by code. Any date quoted is in the specification, and so is what happens if it slips.

Because the risk is smaller than it looks and it is deliberately front-loaded. The specification comes before the price and is yours to keep — if it is wrong, you have lost a conversation. Work is delivered in reviewable pieces rather than as one drop at the end, so a misunderstanding costs days. Bespoke work comes with source, so the module outlives this practice. And what cannot be shown in logos is shown in code: the demos on this site are the real widget source, and the notes are the engineering reasoning in public. Judge it on those rather than on a client list.

You hold the source, the build instructions and the specification, so another developer can pick it up — that is the reason source is in scope rather than an upsell. The signing arrangement is documented at handover, including what has to happen to re-sign the module under a different certificate. The failure mode this whole practice exists because of is a module whose author has vanished and whose source nobody holds, and it would be absurd to reproduce it.