The chiller is usually the largest single electrical load in the building, and the plant’s sequences, energy metering and fault detection all depend on the values it reports. If those values are wrong, late or unreadable, everything built on them is guesswork. Agreeing what “BACnet-ready” means before the chiller arrives costs nothing. Finding out on site can cost weeks.

1. Get the PICS and the object list before delivery

Every BACnet device should come with a Protocol Implementation Conformance Statement (PICS), which lists the BACnet services and object types it supports. The object list matters just as much: it shows which values the chiller actually exposes, their object types and instance numbers, and which of them can be written to. A listing by the BACnet Testing Laboratories (BTL) gives extra assurance that the device was tested against the standard.

Compare the object list with the points your sequence of operation needs. A gap found at this stage can still be closed by the chiller supplier.

2. Find out what has to be bought or enabled

On many chillers the BACnet/IP interface is an option: a communication card, a gateway or a software licence. Make it a named line in the chiller order, and make the chiller supplier responsible for configuring it.

3. Agree the network details

Each device needs a device instance that is unique across the whole BACnet network, not only within the plant room. Agree it at the same time as the IP address and the UDP port (47808 by default). If the chiller sits on a different IP subnet from the WebCTRL server, BACnet broadcasts will not cross the router without a BACnet Broadcast Management Device (BBMD) or foreign-device registration.

Duplicate device instances are one of the most common reasons a device appears on the network and then disappears.

4. Test every read against the chiller’s own display

For each agreed point (leaving and entering water temperatures, run status, alarms, power or current, setpoint) compare the BACnet value with the chiller’s own panel. Check the units, the scaling and how quickly the value updates. Some interfaces refresh their values only every few seconds or minutes, which is fine for monitoring but not for control.

5. Test every write, including the release

Write the setpoint and the enable command from the building automation system, at the priority agreed with the supplier, and confirm that the chiller responds. Then release the command and watch what the chiller does: return to its own default, or hold the last value it was given.

A chiller that ignores writes at the expected priority, or keeps a value after the building automation system stops writing, needs a change to the sequence or to the interface before handover.

6. Check how alarms are reported and reset

Find out whether alarms appear as individual points, as a single alarm code or through BACnet alarm reporting, and how each is reset. Operators need to know what an alarm means and whether they are allowed to reset it from WebCTRL.

7. Trend a full operating cycle

Trend the key values through a start, a change of load and a stop. Look for values that freeze, gaps in the record and timestamps that drift. Faults that never show up in a quick spot check often appear here.

8. Sign off a tested points list

The result of all this is a points list that records each object, its test result and the date, signed by the chiller supplier and the controls contractor. That document is what “BACnet-ready” should have meant from the start.

Put it in the specification

We have written these checks into our own acceptance procedure for new chillers on WebCTRL sites. If you are specifying or buying a chiller, put them in the specification: they cost nothing at tender and save weeks on site.

Planning a chiller replacement? Talk to one of our engineers, or see how we integrate chiller plants.