Wire sheet or custom module? When native Java makes sense in Niagara 4

The wire sheet is one of the best things about Niagara. Logic is visible, a technician can change it on site without a build or a deployment, and the sequence of operations is right there on screen for anyone commissioning the building. For most station logic, it is exactly the right tool.

But it is not the right tool for everything. Past a certain point, wire-sheet logic becomes slow to run, hard to change safely, and easy to copy. This guide covers how to recognise that point, what a custom Java module changes, and how to move without disrupting a station that is running a building.

What the wire sheet is good at

Wire-sheet logic shines when it is specific to one site and likely to be adjusted. Custom sequences for a particular air handler, interlocks between two pieces of equipment, occupancy logic that the facility team tunes each season: all of these belong on the wire sheet, where the people who run the building can see and change them.

It is also the fastest way to build something during commissioning, when requirements change daily. Nothing needs compiling, testing on separate hardware or signing before it runs.

Five signs logic has outgrown the wire sheet

1. The same logic exists in hundreds of copies. A sequence duplicated across every VAV box or every site means a bug fix is hundreds of edits — and some copies will inevitably be missed.
2. Nobody wants to touch it. Deeply nested folders of linked blocks that only their original author understood are a maintenance risk, whatever tool they were built with.
3. The station is running out of headroom. Every wire-sheet block is a full component with its own overhead. On embedded JACE hardware, large amounts of logic show up as rising CPU load and memory use in the station’s resource views.
4. You need something the palette doesn’t have. Protocol framing, precise timing, complex calculations, state machines or calls to external APIs are awkward or impossible to express as linked blocks.
5. The logic is valuable. If a control sequence is a genuine commercial asset — an OEM’s optimisation strategy, say — wire-sheet logic can be copied out of any station backup.

What a custom module changes

A Niagara module is a packaged Java archive that adds new components to the palette. A custom BComponent can encapsulate what previously took dozens of linked blocks, and it appears in Workbench like any standard component: drag it onto the wire sheet, set its properties, link its inputs and outputs.

• One implementation, many instances. Fix a bug once, release a new version, and every instance picks it up.
• Compiled execution. The logic runs as compiled Java instead of a chain of individually scheduled components, which is usually lighter on constrained hardware.
• Typed configuration. The settings a technician needs are exposed as properties with sensible types and defaults, so the site stays adjustable without anyone editing the logic itself.
• Versioning and testing. Changes go through source control and are tested before they reach a live station.
• Signed delivery. Modules can be code-signed, so a station can verify what it is running.

The honest trade-offs

Native code is not free. Before committing, weigh these:

• Changing the logic needs a developer. A technician can adjust properties, but changing the algorithm means Java skills and a release.
• There is a build and deployment cycle. Even a one-line fix is built, tested and installed, rather than edited live.
• Modules must keep pace with Niagara. New Niagara releases occasionally require modules to be rebuilt or updated, so someone needs to own that upgrade path.
• Development takes longer up front. The payback comes from reuse, performance and maintainability — not from the first instance.

Wire sheet vs module at a glance

A migration path that doesn’t disrupt the building

Moving logic from the wire sheet into a module should never be a big-bang change to a live station. The approach we use:

1. Pick the highest-value pattern first — usually the logic with the most copies or the heaviest load.
2. Specify it before coding it. Inputs, outputs, properties, alarms and edge cases, agreed with the people who run the site.
3. Build and test against a replica of the station, including load and soak tests on representative hardware.
4. Run in parallel. Where possible, the new component runs alongside the old logic with its outputs compared but not connected.
5. Cut over in a maintenance window, keeping the original logic disabled rather than deleted, so rollback takes minutes.
6. Document and hand over, so the site team knows what each property does.

When not to write a module

If the logic exists once, changes often, and the station has plenty of headroom, leave it on the wire sheet. The same goes for anything still being tuned during commissioning. A module is an investment in reuse and robustness; it pays off only where those matter.

If you are unsure which side of the line your station is on, our software development service starts with exactly that assessment.