BACnet - What is the State Zero of BACnet Multi-State Variables
In the BACnet protocol, certain object types have strict requirements for their data values to ensure interoperability between different manufacturers' equipment. One common area of confusion is the Present_Value property of Multistate Objects (Input, Output, and Value).
According to the official BACnet standard, a Multistate Object represents a state that must correspond to a positive integer. This guide explains why a value of zero is technically invalid and how this affects gateway performance during system startup.
The "No Zero" Rule for Multistate Objects
The restriction against zero is not an arbitrary choice by developers; it is a fundamental requirement defined in the ASHRAE/ANSI BACnet Specification.
"The Present_Value property shall always have a value greater than zero."
— BACnet Spec (e.g., Paragraph 12.20.4 Present_Value of the 2008 Specification)
Key reasons for this requirement:
- State Mapping: Multistate objects map to a list of strings (State_Text). These lists are 1-indexed. State 1 corresponds to the first string, State 2 to the second, and so on. There is no "State 0" in the string list.
- Error Prevention: By mandating a value greater than zero, the protocol ensures that a device is actively reporting a defined operational state.
Impact on Gateways and System Initialization
Protocol gateways, such as those converting Modbus to BACnet, often face a challenge during the boot-up sequence. By default, internal memory in many microprocessors initializes all data points to zero.
This creates a temporary "Invalid State" scenario:
- Power On: The gateway boots and initializes all internal BACnet objects.
- Initial Reporting: Before the gateway has successfully polled the "Non-BACnet" side (e.g., a Modbus slave or PLC), the Multistate Object may briefly contain a zero.
- BACnet Error: If a BACnet Explorer or workstation polls the device at this exact moment, it may report a "Value Out of Range" error or show an invalid status because 0 is not a permissible state.
- Normalization: Once the first successful data update occurs from the field device, the value changes to 1 or higher, and the object becomes valid.
Best Practices for Integrators
- Initialization Delay: If your BMS allows it, set a small delay or "COV increment" threshold to allow gateways to fetch real field data before they start reporting to the head-end.
- Check State_Text: Always ensure that the number of states defined in your State_Text property matches the maximum value expected in the Present_Value.
- Relinquish Default: In Commandable objects, ensure the Relinquish_Default is set to a valid state (1 or higher) so the object doesn't revert to an invalid 0 when commands are withdrawn.
FAQ – Multistate Object Properties
1) What happens if a device sends a 0 via BACnet?
Most compliant BACnet clients (like a BMS) will reject the packet or flag the point as "In-Alarm" or "Fault," as it violates the protocol's range constraints.
2) Does this rule apply to Analog Values?
No. Analog Input/Output/Value objects can absolutely be zero. The "greater than zero" rule is specific to Multistate objects because they are linked to enumerated string lists.
3) Can I use a Multistate Object for an On/Off state?
While possible (State 1 = Off, State 2 = On), it is usually better practice to use a Binary Object for two-state values. Multistate objects are intended for 3 or more states (e.g., Low/Med/High).
Troubleshooting BACnet Objects?
Chipkin offers industry-standard tools to discover, test, and verify BACnet object properties. Ensure your Multistate Objects are compliant with our diagnostic software:
