BACnet URI Design

[ektrah]

• URI for BACnet Device, Object, and Object Property

The BACnet Binding Template currently uses the BACnet URI scheme as specified in Annex Q.8 of the BACnet specification. However, it makes two modifications:

1. The use of name identifiers in the URIs is restricted and only numeric identifiers should be used. This restriction only applies to the use of BACnet URIs in TDs, not to BACnet URIs in general.

2. It defines a syntax for the query component of BACnet URIs that is not defined in the BACnet specification.

I think the former is fine as it only imposes a restriction compared to the original specification (and only in a TD).

The latter, however, is an extension of the original specification. This will cause problems once the BACnet specification defines a syntax for the query component. (As I understand it, the question here is not if, but when.)

To avoid these problems, either a different (new) URI scheme should be used that is separate from the BACnet specification, or preferably no extensions should be made to the BACnet URI scheme compared to the original specification.

---

• URI for BACnet/SC Hub

The BACnet Binding Template currently defines a URI Scheme that identifies a BACnet device and, within this context, a BACnet object and BACnet object properties (e.g., bacnet://5/0,1/85).

The address of the BACnet device is not globally unique, but is assumed to be in the context of an unspecified BACnet network that the TD consumer knows how to connect to.

For BACnet/SC it may be necessary to be more explicit and specify the address of a BACnet/SC hub. This is a WebSockets address such as wss://bacnet.example.com:443/hub.

It must therefore be possible in a TD to address both a BACnet Device, Object and Object Property (bacnet://5/0,1/85), as well as a BACnet/SC Hub (wss://bacnet.example.com:443/hub).