Note
Getting data out of a Niagara station
Six separate third-party products exist to push station data somewhere else, which tells you how often this comes up — and that the stock answers are not well known.
- Integration
- Histories
- MQTT
Answer four questions first
Most bad integrations are a good mechanism chosen for the wrong shape of problem. Before picking one, settle: who consumes it (a person, a dashboard, a data team, another control system), push or pull, live values or history, and how often. Those four answers usually eliminate three of the five options immediately.
The five routes
| Route | Suits | Costs you |
|---|---|---|
| REST / oBIX | Another system that wants to ask for values, on its own schedule. Standardised, so the consumer may already speak it. | Verbose, and every consumer is one more thing authenticating against the station. Poor fit for high-frequency polling. |
| MQTT | Push to a broker, and from there to anything. The natural fit for cloud platforms and for many consumers of the same data. | A broker to run and secure, and a topic and payload design that you will live with far longer than you expect. |
| History to a database | Reporting and analytics over long periods. A data team that already has SQL tooling wants this and nothing else. | A database to own, and a real decision about retention on both sides so the same trend is not stored twice forever. |
| File / CSV export | One-off extracts, hand-offs, and the finance or operations person who wants a spreadsheet and is right to. | Nothing is live, and files quietly become an interface that somebody starts depending on. |
| Outbound HTTP | Events rather than data: an alarm into a chat channel, a condition into a ticketing system, a webhook into somebody's API. | Retry, failure and back-pressure behaviour are yours to design. A station that blocks on a slow endpoint is a control problem, not an IT one. |
Events are not telemetry. The most common mistake is pushing every point change into a channel built for notifications. Route state changes worth a human's attention over HTTP; route data over MQTT or into a database.
What to decide before the first message
- Naming and topic structure. Whatever you emit first is what the consumer builds against, and changing it later is a coordinated release across two systems. Derive it from tags rather than point names — see renaming and tagging in bulk.
- Units and timestamps. Send the unit and send time as UTC. Ambiguity here is discovered months later, in a report, by someone who cannot tell whether the building really used that much.
- Change-of-value, not polling. Publishing on change with a heartbeat gives the consumer both liveness and a fraction of the traffic. A timer loop is easier to write and worse at everything else.
- What happens when the far end is down. Queue, drop, or block — pick deliberately. The default is usually the one you would not have chosen.
On the controller specifically
If the station doing the publishing is a controller rather than a Supervisor, the budget from what runs on a JACE applies to the integration too. Aggregating at a Supervisor and publishing once is usually better than every controller holding its own connection to a broker or a cloud endpoint.
Related
Where this comes up in the work
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.
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
More notes
Other things worth writing down
Which Niagara version to stamp a module for
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
- Module development
- Mixed estates
- Build tooling
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
Pure Java, or it will not run on a JACE
A controller is an ARM host with a fraction of a server's memory. Native libraries, JNI and heavyweight dependencies do not survive the move from a PC.
- JACE
- Controllers
- Module development
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.