What UnconfirmedPrivateTransfer Is
UnconfirmedPrivateTransfer is a remote-device-management service in BACnet, defined in Clause 16.3 of ANSI/ASHRAE 135-2024. A client uses it to invoke a proprietary, non-standard service on one or more remote devices with no acknowledgment expected. It is an unconfirmed service, so it can be broadcast to reach many devices at once. The standard defines the wrapper, not the operation inside it; the behavior is whatever the vendor assigns to a given service number.
Every request carries a vendor identification code (assigned to the vendor by ASHRAE) and a service number, which together identify the proprietary operation unambiguously. Any additional parameters, and their meaning, are entirely vendor-defined. It is the fire-and-forget counterpart to ConfirmedPrivateTransfer.
How It Works
The client sends a vendor ID, a service number, and optional service parameters, then expects nothing back. Any action a receiver takes is a local matter. Because there is no acknowledgment, the service suits proprietary notifications or broadcast-style distribution where the sender does not need to know each receiver acted. A device that does not recognize the vendor ID and service number ignores the request.
Where You’ll See It
- Proprietary broadcasts. A vendor’s device distributes a device-specific value or event to a group of its own devices in one unconfirmed message.
- Vendor tooling. A manufacturer’s tool triggers a device-specific routine where no per-device confirmation is required.
- Interoperability boundary. A third-party client generally cannot use these services meaningfully, because the meaning of the service number and parameters is documented only by the vendor.
UnconfirmedPrivateTransfer Error Codes
UnconfirmedPrivateTransfer is an unconfirmed service, so it has no acknowledgment and returns no application-layer error. A request that produces no visible effect is not a service error; it is an addressing or support problem. The usual causes:
- The receiving device does not implement the requested vendor ID and service number, so it ignores the request.
- A broadcast never reached the target because of a subnet or BACnet BBMD path problem.
- The sender and receiver are on different networks with no router between them.
Profiles That Require It
No standardized device profile in Annex L requires UnconfirmedPrivateTransfer. It is optional, specialty functionality that a vendor adds for its own devices and tools, so support is declared in a device’s PICS (Protocol Implementation Conformance Statement) rather than mandated by a profile.
What Chipkin Provides
The CAS BACnet Stack supports UnconfirmedPrivateTransfer in both directions, giving an integrator a hook to define and receive proprietary services. Talk to us about adding BACnet client or server support to your device.