Point Writes
Writable points can be commanded from the platform back down to the connected device. A point write specifies the value to apply, the priority level at which to apply it, and an optional duration after which the write automatically releases.
Writes are persisted by the platform, dispatched to the edge node serving the source, and confirmed once the device reports back the commanded value.
Priority Levels
Each writable point has 16 priority slots, numbered 1
through 16. Many systems may write to the same point at the
same time — at different priorities. The lowest-numbered slot with a
value wins and drives the device. When that slot is released, the
next-lowest active slot takes over.
This model mirrors the BACnet priority array and Niagara’s 16-level writable point convention. Sources using protocols without a native priority array still expose the same 1–16 surface; lower-numbered slots always take precedence over higher-numbered ones.
Named Levels
Five of the sixteen slots have well-defined roles. They correspond to the conventional uses of priority writes in building automation:
| Level | Name | Typical Use |
|---|---|---|
| 1 | Emergency | Life-safety overrides |
| 5 | Utility | Demand-response and other utility-driven events |
| 8 | Manual | Operator overrides |
| 10 | Schedule | Schedule-driven values |
| 16 | Default | The point’s default value when nothing else is commanding |
The remaining slots (2–4, 6–7, 9, 11–15) are unnamed and available for custom use.
Expiration
Any write may include an expiration duration. When the elapsed time since the write was issued exceeds the duration, the platform automatically releases the slot. A write with no expiration is permanent — it stays active until explicitly released.
Write Lifecycle
A write moves through a small number of states:
Issued. The platform records the commanded value and queues the write for delivery to the edge node.
In flight. The edge node has received the write and is applying it to the device.
Confirmed. The device reports back, on its next readback cycle, that the commanded value is present at the commanded slot.
Failed. The device rejects the write at the protocol level (the point is not writable, the value is out of range, or another protocol error). The write remains in the priority array as a failed entry until it is released or superseded.
Expired. The expiration duration elapsed and the platform released the slot.
Confirmed and failed are terminal states until further action is taken on the slot. In flight is typically brief — most confirmations land within a single readback cycle.
Conflicts
A conflict is any state where the device’s reported value disagrees with what the platform commanded at a given slot. Common causes:
- A write is still propagating and the device hasn’t yet reflected it.
- Another system is writing to the same priority slot, last-write-wins at the protocol layer.
- A separate system holds a write at a higher-priority (lower-numbered) slot, so the platform’s write is real but not the effective output.
Conflicts are visible in the platform’s view of the point but are not treated as failures — they may resolve on their own as the underlying state changes.
Releases
A release clears a specific slot. Releases flow through the same path as writes: the platform updates its view, dispatches the release down to the edge node, and the device’s priority array slot is cleared. The next-lowest active slot, if any, becomes effective.
Releases can be issued explicitly, generated automatically when an expiration elapses, or implicit when a new write supersedes an entry at the same slot.
Non-Priority Protocols
Modbus, MQTT, OPC UA, and similar protocols do not maintain a priority array on the device — they store only a single current value per point. For these sources, the platform still tracks all 16 slots internally, but only the effective slot (the lowest active one) is actually delivered to the device. Confirmation is by direct value comparison rather than slot readback.