Custom driver development is sometimes the only way to get a device into a Niagara station, and sometimes it is an expensive way to solve a problem an existing driver already handles. The decision is worth making deliberately, because a custom module is a long-lived commitment: it must be maintained across Niagara versions for as long as the station runs.
First, Exhaust the Cheaper Options
Does a standard driver already cover it?
Many devices marketed with a proprietary protocol also speak BACnet, Modbus TCP or Modbus RTU, sometimes only after a setting is changed or a licence enabled. Ask the manufacturer directly what open protocols the firmware supports. This one question resolves a meaningful share of “we need a custom driver” requests.
Would a protocol gateway do?
A hardware gateway that converts a proprietary or serial protocol to BACnet or Modbus is often cheaper than software development, and it is somebody else’s product to maintain. The trade-offs are real — another device to power and troubleshoot, added latency, and mapping constrained by what the gateway exposes — but for a small number of points it frequently wins.
Is there a vendor or third-party module?
Check the manufacturer and the Niagara ecosystem before commissioning new work. A supported module with an update path usually beats a bespoke one, even when it is not a perfect fit.
When Custom Development Is the Right Answer
- The protocol is genuinely proprietary and no gateway exists — common with specialist plant, medical, industrial and legacy equipment.
- A driver exists but cannot express what you need: missing point types, no write support, no alarm mapping, or unusable performance at your point count.
- You need behaviour inside the station, not just data: custom logic, calculations, scheduling behaviour, or components engineers place on a wiresheet.
- You are an OEM and the integration is part of your product, so it must be branded, licensed, signed and supportable across customers.
- The point count or polling profile makes gateway-based integration impractical.
What Custom Driver Work Actually Involves
The protocol implementation is rarely the hard part. The work that determines quality is everything around it: modelling the device as Niagara components so engineers can use it naturally, connection management and reconnection, sensible failure behaviour when a device goes offline, alarm and history integration, and configuration that a commissioning engineer can understand without reading source code.
Then there is the lifecycle. A module targets specific Niagara versions, must be signed to run on modern stations, and needs retesting when the station is upgraded. Ask any developer — internal or external — what happens at the next Niagara upgrade, and make the answer part of the agreement rather than a later discovery.
Questions to Settle Before Work Starts
- Which Niagara versions must it support, today and over the expected life of the station?
- Who owns the source code, and what happens to it if the relationship ends?
- How is it licensed and signed, and on how many stations may it run?
- What is the test evidence — against real hardware, or only a simulator?
- What does support cover, and what does a Niagara upgrade cost you later?
The Short Version
Ask the manufacturer about open protocols first, price a gateway second, and commission custom development when the requirement is genuinely beyond both — then treat it as a product with an owner and a lifecycle, not a one-off deliverable.
Related service: Custom Niagara module and driver development