Service
Integration audit: what talks to what, and where it breaks
Every estate has a diagram of what is supposed to talk to what. What is actually talking to what is a different, unwritten document, and the only way to produce it is to read the station rather than the drawing. This is the paid step that produces that document — a fixed scope, agreed in writing before anything starts, and a report you keep whether or not you use it for anything else.
- Fixed scope
- Written map
- BACnet
- Modbus
- MQTT
- No obligation
What a station will not tell you about its own integrations
None of the following is visible from an as-built drawing or a vendor data sheet. Each one is a question a station can answer, if something asks it directly.
The component space, not the diagram
A wire sheet drawn at commissioning is a claim about the integration, not a record of it. Devices get added, points get renamed, a driver gets reconfigured after a fault call, and the diagram is never updated to match. The component space is queried directly — by BQL, not read off a PDF — so what comes back is what the station is actually doing today.
Driver trees against reality
A device or point tree can be internally consistent and still be wrong: disabled points nobody noticed, devices discovered once and never re-polled, point objects that exist because a template created them rather than because anything reads them. The tree is walked device by device against what is actually on the wire, not trusted on sight.
Poll scheduling and busy time
One poll thread per network means the whole cycle is hostage to the slowest device on it, and a station under 95% busy time will say so nowhere except the diagnostic that measures it. Covered in more depth in why a Modbus network sits at 95% busy time and why a station polls too slowly.
Discovery versus actually bound
A BACnet Who-Is sweep tells you what answered, not what a station is using. Plenty of discovered devices sit unbound, and plenty of bound points were never re-checked after the device they point at was replaced. See what a BACnet discovery sweep actually tells you.
Register maps and byte order
A Modbus register map is a claim until it is read against the device with the byte and word order the driver actually applies. Wrong in one direction and a value is merely odd; wrong in the other and it is plausible, which is worse. Detailed in why a Modbus point reads the wrong register.
History and alarm routing gaps
A history extension with no consumer, an alarm class with no recipient, a schedule nobody has looked at since it was copied from another AHU — each is invisible until somebody checks the routing rather than the configuration screen. See history capacity on a JACE and why an alarm never reached anyone.
How this differs from the free scan and the free tools
| Tier | What it covers | What it does not cover |
|---|---|---|
| Niagara 5 module scan — free | Every third-party module's bytecode, class-file version and signing state, against what a Java 25 JDK does with it. | Whether the integration behind those modules works, or how it is wired to anything else. |
| bacnet-sweep, mqtt-tap, decoder-check — free | One protocol, one question, answered from a laptop in minutes: what answered a discovery sweep, what a broker's topic tree actually carries, whether a vendor's own decoder runs against a real payload. | Anything that needs reading a live station rather than the network in front of it — poll load, routing, the component space itself. |
| Integration audit — paid, fixed scope | The whole integration, read against the actual station, written up as one document: what talks to what, where it breaks, and what fixing it would take. | The fix itself. The audit reads the system as it stands; changing a live station is scoped and priced separately, once the findings are known. |
What the audit produces
A scope, agreed before anything is read
What is in and out, named as a deliverable, at a fixed price. No reading of the station happens before this is agreed in writing.
The station read as it stands
Component space, driver and point trees, poll load, discovery against binding, register maps and routing — checked against what is running, not against what a document says should be running.
One written map, handed over
What talks to what, where it breaks, and a plain verdict on what fixing each finding would take. Ranked, so the worst problem is not buried on page four.
The document is yours either way. There is no obligation to proceed, and the report is written to be usable by whoever does the next piece of work — including a different contractor. That is deliberate: an audit that only makes sense in the hands of whoever wrote it is not a document, it is a sales pitch with a cover page.
What this is not. The audit does not change anything on a live station, and it is not a substitute for commissioning or for a build. If a finding needs a fix — a driver rebuilt, a register map corrected, points rebound — that work is quoted separately once the scope is known, against the same written-specification, fixed-price terms as everything else on this site. Nothing here should be read as a statement about any particular estate's device count or deployment status; each audit answers only for the estate it was run against.
Where this sits
Before it — free
The N5 module scan and the three MIT tools answer one narrow question each, at no cost and no obligation, and most of what they need is something you already have on disk.
This — paid, fixed scope
The whole integration, read once, written up once. Qualifies the job hard before anyone commits to a build: some audits conclude there is nothing to build.
After it — a separate decision
If the map shows work worth doing, the build or the protocol integration itself is scoped and priced from the findings — a decision made after the audit, not assumed by it.
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 |
|---|---|
| The written map | What talks to what, right now: devices found against devices configured, points existing against points bound, protocol document against what the driver actually applies — set out side by side rather than assumed to agree. |
| Where it breaks | Each finding checked against the running station — poll load, discovery against binding, register byte order, history and alarm routing — not inferred from a drawing or a data sheet. |
| A plain verdict per finding | Leave alone, reconfigure, or a build. The audit itself is fixed price regardless of what it finds; the fix, if there is one, is quoted separately. |
| A document you keep either way | No obligation to proceed, and written to be usable by a different contractor if that is where the job goes next. |
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.
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.
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.
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.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
What a Niagara station's oBIX server actually exposes
The mount point, the three verbs, the twelve lobby branches, the five that appear in no listing, and where the open alarms actually are.
- Integration
- Agents
- Station security
Next step
Send whatever already exists — a backup, a device list, or nothing yet.
The first thing that comes back is the scope itself: what the audit will and will not cover, and a fixed price against it, before any reading of the station begins. Not having anything ready yet is the normal starting point and is most of the reason the audit exists.