Why doesn't my BACnet value change when I write to it?

Updated 11 October 2026

First, re-read the point

Easy BACnet re-reads the point after every write, so the value on screen is what the device reports, not what you sent. Compare it with what you wrote and look at Commanded At. Then pick the case below.

Case 1 — the value did not change

A commandable point has a 16-slot priority array and follows the highest-priority slot that is not NULL (1 is highest). If something holds slot 5 and you write at slot 8, your value is stored but the point keeps following slot 5. Commanded At shows the winning priority and its value.

Two things to check:

• Which slot is winning? By the standard, 1 and 2 are manual and automatic life safety, 5 is critical equipment control, and 6 is minimum on/off (a fan's minimum run time holding a Binary Output, for example). If one of those holds the point there is usually a reason; leave it until you know what it is. Anything else above 8 may be a head-end, a sequence, or an override another tech left behind.
• Did your write carry a priority? A WriteProperty with no priority lands at 16, the lowest, so almost anything outranks it. Easy BACnet always sends one (8 by default); some other tools and scripts do not.

Usually the right fix is to release the slot that should not be held (write NULL at that priority) so the point goes back to its program, rather than writing at a higher priority and stacking another override on top. See BACnet priority and stuck overrides.

Case 2 — the value changed, the equipment did not

The controller shows your value but the fan did not start or the valve did not move. The command got through; look past the BACnet side:

• The point is Overridden. The Overridden status flag means something local is forcing the output, typically a hand/off/auto switch on the controller or the starter. Nothing written over the network moves it.
• The point is Out Of Service. The object is disconnected from its hardware, so Present_Value changes but drives nothing.
• The equipment has a fault. A tripped overload, a compressor on lockout, a failed actuator, a VFD in fault. The command is right; the mechanical or electrical side is not.

Check the point's status flags. Overridden and Out Of Service are for the controls side; a healthy point driving dead equipment is for the mechanical or electrical side.

Case 3 — the value changed, then went back

The controller's program is writing the same point. Often it is a non-commandable Analog Value that the program sets every scan, so the last write wins and the program writes last. Or the sequence commands it at a priority at or above yours. Either way you cannot hold it from outside, and on a live system you should not try. The program needs changing, or the sequence needs a proper override point, which is a job for the controls contractor.

If the write was refused instead

If the device answered with an error rather than accepting the write, see what does BACnet Write Access Denied mean? Input points and read-only objects fall there.