Why is my BACnet point stuck, and how do I release an override?

Q: Why is my BACnet point stuck, and how do I release an override?

Because a value written to a commandable BACnet point is held at the priority it was written at until something explicitly releases it. It does not time out, and it survives the tool that wrote it being closed or disconnected. To release it you write NULL to Present_Value at the same priority level that is holding the point. Then control falls to the next-highest occupied priority, or to Relinquish_Default if the array is empty.

Short answer

Because a value written to a commandable BACnet point is held at the priority it was written at until something explicitly releases it. It does not time out, and it survives the tool that wrote it being closed or disconnected. To release it you write NULL to Present_Value at the same priority level that is holding the point. Then control falls to the next-highest occupied priority, or to Relinquish_Default if the array is empty.

How the priority array works

Commandable BACnet objects — typically Analog Outputs and Values, Binary Outputs and Values, and Multi-state Outputs and Values — do not have a single present value. They have a priority array of 16 slots. Slot 1 is the highest priority, slot 16 the lowest. The object's actual Present_Value is whatever sits in the lowest-numbered occupied slot.

When every slot is empty, the point falls back to its Relinquish_Default property. That is the value the object reverts to when nobody is commanding it at all.

Priority	Conventional use
1	Manual Life Safety
2	Automatic Life Safety
5	Critical Equipment Control
6	Minimum On/Off
8	Manual Operator — a person with a tool
16	Lowest; often where the normal control program writes

Only 1, 2, 5, 6 and 8 are assigned meanings by the standard. The rest are available, and every vendor uses them slightly differently — which is exactly why you should agree a priority level in writing before letting an integrator command anything.

Why the point is stuck

Someone wrote a value at a priority and never released it. The usual suspects:

A technician overrode a point at priority 8 to test something and went home.
An integration or analytics platform commands a point on a schedule and stopped running, leaving its last command in place.
A graphics page has an override control that writes but has no obvious release button.
Someone wrote at a higher priority than the control program, so the program keeps writing to slot 16 and nothing happens. The program looks broken; it is being outranked.

Reading the priority array tells you immediately which slot is occupied, and therefore who to blame. A point being held at priority 8 is a person; at 16, it is probably the control program doing its job.

How to release it

Write NULL to Present_Value at the priority that is holding the point. Writing a normal value at a lower priority will not help — the higher slot still wins. Writing NULL at the wrong priority clears an empty slot and changes nothing.

After releasing, re-read the point. Control should drop to the next occupied slot or to Relinquish_Default.

The rule that keeps you out of trouble

Release every point you take command of before you leave site. A commanded point does not expire. A damper you drove to 100% to prove an actuator works will still be at 100% next February unless somebody clears it, and the control program will have no way to tell you it is being overruled.

If you are writing from Easy BACnet: the point detail screen shows which priority currently commands the point and what it falls back to, and the Release to Auto button writes NULL at the priority you select. Every write and release in a session is recorded in the session write log so you can check nothing was left behind.