Service
Station engineering and new controller setup
Standing up a new station or a new controller, properly, from platform commissioning to a handover pack. The station is the BMS head end for everything under it, so the boring half done right — naming, tagging, security, histories and backups — is the half that decides whether the site is maintainable in year three.
- Platform commissioning
- TLS / certificates
- BACnet & Modbus
- Tagging
- Histories
- Backups
New station, end to end
Platform commissioning
Distribution files and the correct Niagara version for the hardware, platform daemon, licence and certificate install, host ID registration, system passphrase recorded, TLS enabled on the platform and Fox ports.
Security before anything is connected
Default credentials gone, a real user and role model with least privilege, password policy, an authentication scheme that is not the default, and the platform listening only where it should.
Drivers and discovery
BACnet/IP and MS/TP, Modbus TCP and RTU, or whatever the field devices speak. Discovery, device and point creation, poll rates set deliberately rather than left at default — a JACE can be brought to its knees by an over-eager poll scheme long before it runs out of points.
Naming and tagging
A naming convention applied uniformly, and Haystack or Niagara tags applied as the points are created rather than retro-fitted later. This is the single decision that determines whether analytics, standard PX sheets and bulk engineering are cheap or impossible on this site.
Histories, alarms, schedules
History extensions with intervals chosen to fit the flash on the device, alarm classes and routing that a human can actually act on, schedules and calendars modelled once and referenced rather than copied.
Supervisor connection
Station added to the Supervisor, Niagara Network wiring, history and alarm federation, provisioning jobs, and a verified restore — a backup nobody has restored is not a backup.
Handover pack
Point schedule, network diagram, credential and passphrase handover, backup procedure, and a note of every decision a future engineer would otherwise have to reverse-engineer from the station.
Also available on its own
Controller replacement
Moving a station onto new hardware: station copy, licence and certificate transfer, driver revalidation, third-party module check, and a rollback plan.
Health review
An existing station reviewed against the list above — security posture, poll load, history sizing, alarm noise, backup state — with findings ranked by what will bite first.
Tagging retrofit
Applying a consistent tag model across a station that was built without one, scripted rather than clicked, so analytics and standard graphics become possible.
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 |
|---|---|
| A commissioned station | Licensed, secured, backed up and documented, with TLS on and defaults gone. |
| A point schedule | Every point, its ORD, its tags, its history and alarm configuration, as a document you keep. |
| A verified backup and restore | Proven by performing the restore, not by the backup job reporting success. |
| The handover pack | Credentials, passphrase, diagrams, conventions and decisions, written down. |
Also
Other services
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.
bajaux 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.
PX graphics
Niagara PX graphics as a reusable template set: standard HVAC plant sheets, relative-ORD binding, navigation hierarchy and a written graphics standard.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
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.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
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
JACE-8000 to JACE-9000: what the licence transfer does and does not do
The JACE 8000 to 9000 licence transfer, step by step: what it requires, what it does not include, and which parts cannot be undone.
- JACE
- Migration
- Licensing
Bringing LoRaWAN and MQTT data into a Niagara station
Where abstractMqttDriver and jsonToolkit stop, and what LoRaWAN decoding, topic design, and store-and-forward buffering add on top.
- Integration
- LoRaWAN
- MQTT
Renaming and tagging points in bulk
Point names arrive from the field device and there is no standard. What to use to select, rename and tag in bulk — and what a rename quietly breaks.
- Bulk engineering
- Tagging
- Workbench
Getting data out of a Niagara station
REST, MQTT, a relational history database, file export or an HTTP client. Which suits which consumer, and what each one costs you to run.
- Integration
- Histories
- MQTT
Scheduled station backups, and the gap
A Supervisor can back up every station in its Niagara Network on a schedule. The station it does not cover that way is its own.
- Backups
- Provisioning
- Supervisor
Why a station polls too slowly
Slow, Normal and Fast are three numbers you choose, and one default tuning policy applied to every point is the usual reason a station feels sluggish.
- Station engineering
- Performance
- BACnet
BACnet MS/TP on a JACE
Baud, MAC address, Max Master and Max Info Frames. Four settings on one Link component decide whether an RS-485 trunk works, crawls or drops the token.
- BACnet
- MS/TP
- Commissioning
The certificate on a new JACE
Every station starts with a self-signed certificate it generated itself. What that is good for, what it is not, and what breaks on the day it expires.
- TLS
- Certificates
- Commissioning
Tags, dictionaries and the licence you need
Tagging is how a station describes itself to software that did not engineer it. Three kinds of tag, one namespace, and a licence feature that gates it.
- Tagging
- Data modelling
- Haystack
History capacity on a JACE
The default capacity is 500 records, the default name collides, and one setting decides whether a full history overwrites data or stops collecting.
- Histories
- JACE
- Station engineering
Why a Modbus point reads the wrong register
Modbus decimal addressing is zero-based, vendor documentation is not, and the Address Format property decides which of the two you are typing.
- Modbus
- Integration
- Station engineering
Why an alarm never reached anybody
Detection, class and recipient are three separate objects in a Niagara station. An alarm goes missing wherever the chain between them is not linked.
- Alarms
- Station engineering
- Commissioning
Niagara schedules: special events and master copies
Special event priority is list order, a partly-filled special event falls back to the weekly schedule, and an imported schedule cannot be edited locally.
- Scheduling
- Station engineering
- Commissioning
A navigation tree that builds itself
Hierarchies generate the nav tree from tags and NEQL queries instead of hand-placed nodes — and the cache hides your edits until you rebuild it.
- Hierarchies
- Tagging
- Station engineering
Templates: build the AHU once, deploy it fifty times
Component, application and station templates do different jobs — and only one of them supports bulk deployment from a spreadsheet and upgrade in place.
- Templates
- Bulk engineering
- Station engineering
Doing one thing to fifty stations at once
Provisioning runs platform tasks across a whole NiagaraNetwork from one Supervisor connection — and the obvious backup action is the wrong one.
- Provisioning
- Estate management
- Supervisor
Roles, categories and the grid between them
Niagara permissions are a grid of category against level — which is why a user can log in successfully and still be told they have no access.
- Station security
- Permissions
- Commissioning
Why a writable point ignores the value you set
Sixteen priority inputs, two of them reserved for right-click actions, a fallback underneath, and a BACnet scheme wired to none of it.
- Station engineering
- BACnet
- Commissioning
What the Niagara MQTT driver will and will not do
It is licensed, it is capped below your licence, it is a client only, and its Discover button never contacts the broker.
- Integration
- MQTT
- Drivers
Platform or station: two connections, two sets of logins
Two processes, two Java VMs, two logins and two file trees — and most “it works in Workbench but not the browser” starts here.
- Platform
- Station engineering
- Workbench
A JACE-8000 has no onboard I/O: using the Nrio driver
Remote IO-R modules on RS-485, one network per port, and the conversion list Workbench will happily let you get wrong.
- JACE
- Drivers
- Commissioning
Conversion links: what a mismatched wire really does
Link a boolean to a numeric and Niagara inserts a converter with its own properties. Here is what each one assumes on your behalf.
- Station engineering
- Wire sheet
- Workbench
Authentication schemes: each Niagara user picks one
A station can run several login mechanisms at once, and the choice is made per user, not per station. What each scheme is actually for.
- Station security
- Permissions
- Station engineering
Next step
Send the equipment schedule and the controller list.
Station work is priced from what is being connected and how many points it carries, so those two documents are usually enough for a fixed price rather than a range.