Questions we get asked before a first project

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.

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. What else comes with the job, and who owns each part of it, is set out on what you own when the job ends.

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, the notes are the engineering reasoning in public, and this site's own build and test gates are written out with the two defects they caught here. 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. The whole package - runbook, credential inventory, replay test, portable export - is written out on what you own when the job ends, including the response time.

Yes, and six of the eleven deliverables here need no building automation system to be useful: a site, the workbook a team runs on, web and deployment work, a protocol read, a device integration and a written audit. The published evidence for that half is a connected-device platform — radio devices, a provisioning path, telemetry, an operator dashboard and an internal operations app — four defects fixed in a vendor's payload decoder, and the data-engineering and platform-specification rows under also built. Building automation is one of the disciplines here, not the practice.

The thing itself, and the pipeline that keeps it up — which is where a small site usually fails in public: a redirect nobody added, a certificate nobody was watching, an asset still fetched over http, a link that has answered 404 since the last rebuild. Web app builds and the pipeline lists the deliverables. This site is the sample rather than the claim: how this site is built publishes the gate transcript every release has to pass, and release-diff is one of the tools out of it, given away.

That is a job of its own here. The workbook in question is usually undocumented software rather than a spreadsheet: years of rules in formulas, written by somebody who has left, which nobody will replace because nobody knows what it does. So the first step is reading it rather than redesigning it, and workbook-scan is that step given away as a free, read-only tool — it reports the formulas, the links and the hidden sheets without sending the file anywhere. What a rebuild is scoped as is on the workbook the team runs on.

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.

Fourteen, and one more thing that is not a program. bacnet-sweep broadcasts a BACnet/IP Who-Is, lists the devices that answer, and dumps a device's object list to a table or CSV. mqtt-tap subscribes to an MQTT broker and prints its topic tree with counts, payload types, last values and which retained topics stopped updating. decoder-check runs a device vendor's LoRaWAN payload decoder in a sandbox and reports what a station would actually get back from it. Nine more read a Niagara installation rather than a network: modbus-address-scan prints the register a Modbus point really asks for in each address format, ede-check reads an EDE point file against the parser Niagara ships and reports what it would silently default, module-sign-scan prints which of the four module verification modes refuses which signature state, and bacnet-priority-scan prints which BACnet object types the station writes through the priority array and which it probes first. alarm-route-scan prints what the alarm queue does to a duplicate and why the copy it drops is still reported as delivered, alarm-recipient-scan prints what a recipient does with an alarm when the far end is down, and schedule-scan prints how far ahead a control schedule can see and when it reports no next change at all. poll-scheduler-scan prints what a poll rate is a budget for and the bucket size at which the poll thread stops sleeping, and tuning-stale-scan prints why a device that stopped talking leaves its points reading ok by default. And one that is not about a control system at all: workbook-scan opens an Excel workbook as the zip of XML it is and reports what the sheet encodes - formulas saved holding an error, links into files that may be gone, a saved query to one person's mapped drive, approximate VLOOKUPs. And one is not about a building at all: release-diff reads the same list of paths on two hosts - staging and production - and reports every field that moved, failing on anything that moved and was not declared, because what gets an outsourced developer dropped is not bad code but a silent change nobody wrote down. All fourteen are read-only, one file each, with nothing to install, and free with no licence or registration — all fourteen are here. The BACnet sweep and the MQTT tap have never been run against real hardware or a real broker: each was proved against a protocol fixture on loopback, and each page says what that covers and what it does not, and the nine scanners report one installation's answer and name the version they read. The one that is not a program is the Niagara 5 module scan, which we run rather than give away because it needs a Java 25 JDK.

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.

Yes, and that is how the platform work has gone: a branch, a pull request, your review and your pipeline, in a codebase other people are still committing to. The platform integration case study is written from the commit history rather than from memory, and says which parts were ours and which were not. Working under your name instead of ours is normal too, and the terms are under working together below.

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.

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, and a note on which of the two names to use: BAS or BMS.

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.

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.

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.

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.