Services
What we build, and what you get for it
Six services, all of them the software layer of a building automation system. Each quoted as a fixed price against a written specification, with the deliverables listed before the work starts.
Custom modules & drivers
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 morebajaux widgets
Custom Niagara web widgets in bajaux and BajaScript: HTML5 BMS dashboards, HVAC plant views, navigation and charts, bound to live station ORDs and BQL.
Read morePX graphics
Niagara PX graphics as a reusable template set: standard HVAC plant sheets, relative-ORD binding, navigation hierarchy and a written graphics standard.
Read moreStation engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
Read moreWorkbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
Read moreNiagara 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.
Read moreStart here
Not sure which of those a job needs?
The six above are named in Niagara vocabulary, which is the right language once there is a station and the wrong one when there is a building. If the problem is still described in BMS terms — the graphics are unusable, that chiller will not come into the head end, nobody knows what is installed — start one level up.
Building automation software on Niagara explains where the framework sits in a BMS, what the software layer of a project actually consists of, and which of these six each kind of problem turns into. It also maps the vocabulary both ways, so a quote is not lost in the gap between "trend log" and "history extension".
Engagement
How a piece of work runs
A conversation
Niagara version, target hardware, what exists today and what has to be true at the end. Usually half an hour.
A written specification
Scope, behaviour, failure behaviour, deliverables and what is explicitly out of scope. You keep it whether or not you proceed.
A fixed price
Against that specification. If the scope changes, the specification changes first and the price changes with it.
Build and review
Delivered in reviewable pieces rather than as one drop at the end, so a misunderstanding costs days instead of the project.
Handover
The signed module or the commissioned station, an installation note written for the commissioning engineer, and source where it is in scope.
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.