BACnet Priority Arrays – Understanding Command Conflicts

Problem

You send a command to a BACnet device but it doesn't take. Or worse, it takes sometimes but not others. Point seems "stuck" on a certain value.

Root Cause

BACnet priority array is being written at multiple levels (application logic, manual override, schedules) and the highest-priority write always wins.

Solution

Understand BACnet Priorities (1–16)

• Priority 1–7: Reserved for manual overrides and critical commands
• Priority 8–12: Application logic, schedules, and normal operations
• Priority 13–15: Rarely used, typically for special cases
• Priority 16: Lowest priority; default fallback value
• Highest numeric priority ALWAYS wins (priority 1 overrides priority 16)

Example Scenario

• Your command writes at priority 16 (normal)
• Application logic is writing at priority 8 (higher than 16)
• Result: Application logic wins, your command is ignored

How to Release a Stuck Point

1. Right-click the point in BAS UI
2. Select Command → Release All (or Release Override)
3. This clears all priority writes and releases the point to default behavior
4. Value should return to whatever the application logic specifies

Check Priority Array (Niagara)

• Double-click the point
• Look for the priority list property
• Each priority 1–16 shows who/what is writing to it
• Empty priorities aren't writing; filled priorities are active
• The highest-filled priority always controls the value

Best Practice for Your Own Programming

• Always write application logic at priority 12 (leaves room for overrides at 1–11)
• Reserve priority 8 for critical safety logic
• Never write at priority 16 (that's only for initial value)