// the most misunderstood part of BACnet

Your write isn't gone.
It's outranked.

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.

Download free trial See pricing

Windows 10/11 · BACnet/IP & MS/TP · 14-day trial

// the 16 slots

One value, sixteen competing writers

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.

PriorityConventional use (BACnet standard example)
1–2Manual / Automatic Life Safety
3–5Automatic Critical Equipment / Safety
6Minimum On/Off (unoccupied protection, etc.)
8Manual Operator — the usual slot for a human override
9–10Available (vendor / site-specific)
11Available
12–15Available / Local scheduling
16Available (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.

// the actual failure mode

"I wrote it and nothing happened"

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.

// releasing, not overwriting

Relinquish is a write, not a delete

✎ Write a value

Puts your value in the slot you chose. It stays there — competing with whatever else targets that same slot — until something explicitly relinquishes it.

⌦ Relinquish (write NULL)

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.

⚠ The common mistake

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.

// where BACManager fits

Write at a priority, on purpose

Both places BACManager writes to a commandable point make the priority explicit instead of hiding it.

📂

Property browser

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.

🔌

Gateway write-forward

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.

Relinquish from the same UI

Releasing a priority slot is the same write dialog with a Relinquish option — no separate tool, no manually constructing a NULL application-tagged value.

// questions

Priority array — FAQ

Why doesn't my BACnet write take effect?+
On a commandable object, Present_Value is the value in the highest-priority occupied slot of a 16-level priority array, not simply the last thing written. If a controller, schedule or safety input is already holding a higher-priority slot (a lower number, 1 being highest), your write at a lower priority is stored but has no visible effect until that higher slot is relinquished.
What priority level should I use for a manual override?+
Priority 8 is the conventional slot for "Manual Operator" in the BACnet standard's example priority assignments, and most controllers reserve it for exactly this kind of manual override. Using it keeps your write out of the way of life-safety (1-2), automatic critical (3-5) and scheduling priorities that other logic relies on.
How do I release a priority-array write?+
Write a NULL to the priority slot you used, not a new value. This relinquishes that slot, and Present_Value falls back to the next-highest occupied slot, or to Relinquish_Default if every slot is empty. Leaving your value in place at that priority means it keeps competing with the next thing that also writes there.
Does every BACnet object have a priority array?+
No, only commandable objects: Analog Output, Binary Output, Multi-State Output, and the writable Value variants (AV, BV, MSV) when a device implements them as commandable. Plain inputs and most read-only points expose a single Present_Value with no array behind it.
Can BACManager's Gateway write to a BACnet device from a PLC?+
Yes. The Gateway maps a BACnet object as a write-forward endpoint with an explicit priority (default 8, Manual Operator) — a PLC writes to the shared Modbus map like any other point, and BACManager forwards it as a proper BACnet WriteProperty at that priority, not a blind overwrite.

Stop guessing which slot is winning

Download the free trial and browse a real Priority_Array on your own devices — no credit card, no cloud.

Download free trial See pricing

Windows 10/11 · $149 one-time