A commandable BACnet point isn't last-write-wins like a Modbus register. Present_Value comes from a 16-level priority array, and a write at priority 12 does nothing visible while a schedule or controller is holding priority 6 — not because the write failed, but because it lost. Here's how the array actually works, and how BACManager's property browser and Gateway write at the right level instead of guessing.
Windows 10/11 · BACnet/IP & MS/TP · 14-day trial
Every commandable object (Analog Output, Binary Output, Multi-State Output, and commandable Value objects) carries a Priority_Array property alongside Present_Value: 16 slots, numbered 1 to 16. Present_Value is simply whichever occupied slot has the lowest number — the highest priority. Empty slots are skipped. If every slot is empty, Present_Value falls back to Relinquish_Default.
| Priority | Conventional use (BACnet standard example) |
|---|---|
| 1–2 | Manual / Automatic Life Safety |
| 3–5 | Automatic Critical Equipment / Safety |
| 6 | Minimum On/Off (unoccupied protection, etc.) |
| 8 | Manual Operator — the usual slot for a human override |
| 9–10 | Available (vendor / site-specific) |
| 11 | Available |
| 12–15 | Available / Local scheduling |
| 16 | Available (lowest active priority) |
These are the example uses given in the BACnet standard, not a hard rule — individual devices and site standards can assign priorities differently. Priority 8 (Manual Operator) is the closest thing to a universal convention for a human override, which is why it's BACManager's default.
This is almost always a priority problem, not a communication problem. You write a setpoint at priority 12. A schedule object is already commanding that same point at priority 10. Your write is accepted, stored, and completely invisible — Present_Value keeps reporting the schedule's value, because 10 outranks 12. Nothing is broken. The write succeeded exactly as BACnet defines it; it just isn't the value in charge right now. The fix isn't to write harder or retry — it's to write at a priority that actually wins, or to relinquish whatever is holding the slot above yours.
Puts your value in the slot you chose. It stays there — competing with whatever else targets that same slot — until something explicitly relinquishes it.
Clears your slot back to empty. Present_Value then falls through to the next-highest occupied slot, or to Relinquish_Default if the whole array is now empty. This is how you hand a point back after a manual override.
Writing priority 16 "just to be safe" and leaving it there. It never gets in anyone's way, which also means it's silently doing nothing the moment any other priority is active — indistinguishable from a write that never landed.
Both places BACManager writes to a commandable point make the priority explicit instead of hiding it.
Writing a value from the object browser lets you pick the priority slot directly, and shows the full Priority_Array so you can see what's already occupying a higher one before you write.
Mapping a BACnet object as a Gateway write endpoint has a Priority field (default 8, Manual Operator) — a PLC writing to the shared Modbus map forwards as a proper WriteProperty at that priority, not a blind overwrite.
Releasing a priority slot is the same write dialog with a Relinquish option — no separate tool, no manually constructing a NULL application-tagged value.
Download the free trial and browse a real Priority_Array on your own devices — no credit card, no cloud.
Windows 10/11 · $149 one-time
We use Google Analytics cookies to see how the site is used. You can accept or decline — declining keeps analytics off.