Protocol integration, and the data that comes out the other side

The document, read before the site reads it

Protocol documents fail in a small number of repeatable ways, and every one of them is cheaper to find on a desk than on a roof. A function-code table the worked example contradicts. An address column that is one-based in one section and zero-based in the next. A float area published in two word orders when the head end has one byte-order setting for the whole device. A totaliser whose rollover is documented nowhere, which is the one that turns into a billing dispute. We check yours row by row and send the arithmetic rather than the opinion — the generic version is in Modbus register addressing.

A bus that is not drowning

Most integrations that "go slow" are not slow: they are queued. One poll thread per port means the cycle is hostage to the worst device on it, so moving points to a slow tuning policy only relocates the queue unless the offender has the port to itself. Read-property-multiple is off by default on a good many gateways that support it. Write throttling defaults to none, and every reconnection re-sends every write at once. We work through it in that order — separate, then batch, then throttle — and judge each change on device status, not on whether the values still look plausible while a stale-time window hides the truth.

When there is no BMS in the middle

Not every job has a head end, and not every head end is worth one. A gateway, an MQTT broker with topics somebody else can subscribe to, a time-series database and a dashboard is a complete system for plenty of buildings, and it is a great deal less to own. We build that stack — broker, historian, dashboards — on your infrastructure or on ours, handed over as configuration files rather than as clicks somebody has to remember, so the same system can be stood up twice.

The data after the point

A reading on a screen is not the deliverable; the deliverable is usually a number somebody bills against, reports on, or raises a work order from. That means histories that survive a gap rather than averaging over it, exports whose totals reconcile, and the integration nobody quoted for: the bridge into the ERP, the CMMS or the billing platform, in whichever direction it has to run.

A read of one protocol document — free

Send the register map, the BACnet object list or the API reference for one device. You get back what contradicts what, which rows will read a real number off the wrong address, and what to ask the manufacturer. If it is clean, you get that answer, which is worth knowing too.

Typically two working days. No obligation either way.

A point tree, built rather than typed

The points already made, with the right address format, byte order and scaling, plus the histories and alarms behind them. For a large estate this is a generator and a spreadsheet rather than a fortnight of clicking, and the generator is yours afterwards.

Fixed price per point count and protocol.

A network that behaves

For an integration that already exists and is unreliable: the traffic measured, the queue found, the changes made one at a time with the evidence for each, and a written note of what was changed and why, so the next engineer does not undo it.

Fixed price per site, against a written scope.

The data layer, handed over

Broker, time-series database, dashboards and the exports that reconcile — standing up on your own servers, with the configuration in files you keep. No licence to us, and nothing that stops working if we do.

Fixed price against a written specification.