What Is the BACnet Present_Value Property?
Present_Value is the property you read from a BACnet object to get its current value, and it is the single most-accessed property in any integration. But it behaves differently on an input than on an output, and misunderstanding that difference is behind a lot of confusion about why a written value did not stick. This reference explains what Present_Value holds on each kind of object, why writing it on an output goes through the priority array, and how to read it so the number you record is actually trustworthy.
BACnet Present_Value Property in one line: The Present_Value property holds an object's current value - the measured reading of an Analog Input, the run state of a Binary Input, or the commanded output of an Analog Output. On input objects it reflects the sensor or process and is read-only to clients. On commandable output and value objects, Present_Value is not written directly; a client writes a value at a priority into the priority array, and Present_Value is the result of whichever priority currently wins.
Present_Value on Input Objects
On an Analog Input, Binary Input, or Multi-state Input object, Present_Value carries the value the device is sensing right now: a temperature in the configured units, a discrete on-or-off status, an enumerated state. This is the read-only face of the physical world, and it is what a supervisory client polls or subscribes to when it wants the current reading. A client cannot command an input's Present_Value, because the value comes from a sensor, not from a command - trying to write it is a category error the device will reject.
Present_Value on an input is meaningful only in the context of its companion properties. The Units property tells the client what engineering unit an analog value is in, so a reading of 21.5 is degrees Celsius or something else depending on Units. The Status_Flags and Reliability properties, covered in the status flags reference, tell the client whether the value is valid or in fault. A reading pulled without those companions is a number with no guarantee behind it.
Some input objects support the Out_Of_Service property, which decouples Present_Value from the physical sensor for testing. When an input is placed out of service, a client can write its Present_Value to simulate a reading, which is useful for commissioning and loop checks but dangerous if left set, because the object then reports a fictional value while the real sensor is ignored. Confirming Out_Of_Service is false is part of trusting an input's reading, and it is a common cause of a point that stubbornly reports a fixed number regardless of the process.
Present_Value on Commandable Output Objects
On a commandable object - typically Analog Output, Binary Output, Multi-state Output, and commandable value objects - Present_Value is not a value a client sets directly. Instead the object holds a priority array, a stack of sixteen command slots, and Present_Value is the value from the highest-priority slot that currently holds a command. When a client writes to the object, it writes a value at a chosen priority level into that array, and the object recomputes Present_Value from whichever slot now wins. This indirection is what lets multiple control sources command the same output without overwriting each other blindly.
The practical consequence is that a write can appear to do nothing. If a client writes a value at priority 10 but a higher-priority slot, say priority 8, already holds a command, Present_Value continues to reflect priority 8 and the write at 10 is stored but not effective. The value is not lost - it becomes effective the moment the higher slot is relinquished - but to an operator who does not know the priority array is in play, the output simply ignored the command. The full mechanics are covered in the priority array reference.
When every priority slot is empty, Present_Value falls back to the Relinquish_Default property, the object's designed resting value. So a commandable output is never without a Present_Value: it is either the winning command or the relinquish default. Understanding this chain - array slots, then relinquish default - is what lets an integrator predict what an output will do when a control source releases it, rather than being surprised by where it lands.
Frequently Asked Questions
Why does writing Present_Value on a BACnet output not always work?
Because on a commandable object you do not write Present_Value directly - you write a value at a priority level into the object's priority array. Present_Value reflects whichever priority slot currently wins. If a higher-priority slot already holds a command, your lower-priority write is stored but does not change Present_Value until the higher command is relinquished. The write is not lost; it is simply outranked.
Can a client write the Present_Value of a BACnet input?
Not while the input is in service. An input's Present_Value comes from the physical sensor and is read-only to clients. The exception is when the input's Out_Of_Service property is set true, which decouples the value from the sensor so a client can write a simulated Present_Value for testing. Leaving an input out of service is a common cause of a point stuck at a fixed value, so it should be cleared after commissioning.
What does Present_Value fall back to when no command is active?
On a commandable output object, when every slot in the priority array is empty, Present_Value takes the value of the Relinquish_Default property. That is the object's designed resting state - the position or setpoint it holds when no control source is commanding it. So a commandable output always has a Present_Value: either the highest active command, or the relinquish default when all commands have been released.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.