Why a BACnet write relinquishes on its own

A writable point works out its own active level before the driver sees anything. The writable support walks in1 through in16 in order, takes the first input with valid status, and stops. If none of the sixteen is valid it uses the fallback value instead and records the active level as 17.

Seventeen is a Niagara level. It is not a BACnet priority — BACnet has sixteen. That mismatch is where the surprise lives.

Two of the sixteen are also special on the way past: an active level of 1 or 8 sets the overridden status bit on the output, which is why a point commanded at Emergency or Operator shows as overridden and one commanded at 16 does not.

The BACnet proxy hands the write to a command object carrying two numbers: the level it is writing now, and the level it wrote last time. The command then does, in this order:

• if the current level is 1 to 16, one WriteProperty at that priority;
• otherwise, if there is a value, one WriteProperty with no priority argument at all;
• otherwise, one WriteProperty of Null, also with no priority;
• and then, separately, if the previous level is non-zero and different from the current one, a second WriteProperty of Null to clear it — at the previous priority, or with no priority if the previous level was 17.

Read that last bullet again, because it is the whole answer. The clear is not conditional on anything except the level having changed.

Put those together for a point that has been commanding at 16 and whose inputs all go null. The level moves from 16 to 17, and the driver sends:

1. the fallback value, with no priority argument — the device takes it at 16;
2. a Null at priority 16, because the previous level no longer matches the current one.

Net effect at the device: relinquished. It falls to its own relinquish default, and the fallback value you carefully configured survived for the length of one round trip. Nothing timed out. Nothing was overloaded. The point simply stopped having a valid input at the level it had been using.

Choosing a different in slot does not change the shape of this. Commanding at in8 moves the value to priority 8, but the moment in8 goes null and fallback takes over you get the same pair, with the Null at 8 this time. If something upstream — a schedule, a program object, a link that nulls between cycles — is emptying that input, that is the thing to find.

The driver only treats a point as prioritized if an internal flag says the object has a priority array. For Analog Output, Binary Output and Multi-state Output on present-value that flag is always true. For Analog Value, Binary Value, Multi-state Value and the newer value types it is discovered once, by reading the priority array off the device, and then cached on the proxy in its device facets.

If that read failed — gateway busy, device down when the points were discovered, discovery run against a device that was not ready — the flag stays false. From then on the write level is forced to zero, so every write goes out with no priority argument no matter which in slot you use, and the driver stops tracking a previous level to clear. On a point that is behaving as if priority is being ignored, that cached facet is the first thing to check, because nothing about the point's appearance in the station gives it away.

There is a deliberate escape hatch. A boolean slot named ignoreFallback added to the proxy extension, or the system property niagara.bacnet.point.ignoreFallback set on the station, changes what a fall to fallback does: the driver stops writing the fallback value at all and instead issues a single Null at the level it last wrote, and only if that level was a real BACnet priority. One clean relinquish, no priority-16 write immediately undone.

That is the right behaviour for most integrations, and it is off by default. The alternative — if the intent is that the plant should hold a value rather than release — is to stop the point falling to fallback in the first place by keeping a valid input at a low priority, usually in16, so the level never reaches 17.

• The device drops to its relinquish default at the moment a schedule or program ends. That is the write-then-clear pair. Look at what is nulling the input, and consider ignoreFallback or a permanent low-priority input.
• Priority makes no difference at all, at any level. That is the cached priority-array flag. Rediscover the point against a device that is answering.
• It happens at random, unrelated to any level change. Only then is it worth treating as a comms problem — and be careful reading the values while you test, because a stale reading can look like a live one for as long as the tuning policy allows.

The companion note on writable point priority covers the sixteen levels and the fallback from the station's side, and what a discovery actually finds covers the read half. Where a gateway has to be made to behave rather than tuned around, protocol integration is that work, and station engineering is the station around it.