Service
Workbench tooling and bulk engineering
The repetitive work that quietly eats project hours — renaming four thousand points, applying tags by hand, auditing a station before a migration. Tools your engineers run themselves, inside Workbench.
- Bulk rename
- Retagging
- Station audit
- Provisioning
- BQL
- Repeatable
The economics
Bulk engineering is the clearest return in the whole Niagara toolchain, because the work it replaces is measured in engineer-days and the tool is written once. A rename that takes two engineers a week across an estate is a rule set and an afternoon. The point is not only the time: a scripted change is uniform, and a hand-edited one is uniform right up until somebody's concentration lapses on row 1,900.
The tools worth building
Bulk rename and retag
Pattern-driven renaming and tagging across a station or a Niagara Network, with a dry-run that shows every proposed change before anything is written, and a CSV of what actually changed afterwards.
Station audit
A report on what is actually in a station: points without histories, histories without consumers, alarms nobody has acknowledged in a year, duplicate schedules, orphaned components, poll load by device.
Module inventory
Every third-party module across an estate, with its vendor, version, signature state and stamped Niagara version — the document you need before scoping any migration.
Mass configuration
Applying history extensions, alarm extensions or display names to thousands of points from a rule set or a spreadsheet, rather than through the property sheet.
Provisioning helpers
Repeatable jobs across a Niagara Network: pushing a module version, running a batch job, collecting backups, verifying that every station is on the version you think it is.
Export and reporting
Scheduled extracts from BQL queries to CSV, a share or an API, for the monthly report somebody is currently assembling by hand.
Every bulk tool ships with a dry run. A tool that writes four thousand changes to a live station without showing you the diff first is a liability, not a saving. Preview, then commit, then a record of what changed.
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 Workbench view or tool | Installed as a module, run by your engineers from Workbench — not a script only the author can operate. |
| A dry-run report | Every proposed change, previewable and exportable, before anything is written. |
| A change record | CSV of what was actually written, so the job is auditable after the fact. |
| A short operating note | One page. What it does, what it will not touch, and how to reverse it. |
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.
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
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.
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
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
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
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
Next step
Tell us what the repetitive job is, and how many times a year it happens.
Bulk tooling pays for itself or it does not, and that is arithmetic rather than opinion. If the tool costs more than the engineer-days it saves, you will be told so.