-
Notifications
You must be signed in to change notification settings - Fork 2
Home
These are the design considerations:
-
Apply common practices for topic names and expectations.
MQTT provides the concepts of a topic and message but does not specify the organization of topics or a message format, this project provides both.
-
Apply a very simple communications model, the broker acts like an Ethernet switch and the clients are like Ethernet port connections.
Without the concept of BBMDs or foreign devices there is no need for forwarding messages or maintaining the original source of a broadcast request as it hops from BBMD to BBMD. There are also no messages for maintaining broadcast distribution tables or foreign device registration, so BACnet/MQTT is significantly simpler than BACnet/IP.
MQTT is a client/server, publish/subscribe protocol running over TCP/IP, or the less common variant MQTT-SN that runs over UDP. The server is called a broker, and messages are published by clients to topics. Clients subscribe to a topic to receive the messages that have been published to that topic.
In MQTT there is no restriction on what topics clients use for classifying their messages, nor is there a restriction on what topics clients may subscribe. Some broker implementations provide that type of additional access control as an added feature.
BACnet/MQTT clients are called virtual network nodes, or simply nodes, and a family of related topics is a virtual network.
BACnet/MQTT specifies a naming convention topics so that nodes have well known places to publish messages. The topic names consist of a network name, followed by slash '/', followed by a lower case decimal encoded node address. The network name is configurable so a single broker can serve more than one virtual network.
The virtual network has a broadcast address which has a special topic name, and client addresses which are decimal encoded 3-octet values using clause H.7.2 Using Device Instance as a VMAC Address.
The broadcast address topic name is "@all".
The essential core of the BACnet/MQTT is the exchange of unicast and broadcast
BACnet NPDUs, without complexity of having multple intervening special purpose
devices such as BBMDs. The EncapsulatedNPDU message is used to transfer
messages, the other messages are to maintain knowledge of the other virtual
network participants.
To "broadcast a message" means to publish a message on the topic corresponding to the broadcast address for the virtual network. To "unicast a message" means to publish a message on the topic corresponding to the specific client.
BVLPDUs are divided into two pieces, the BVLCI which is identical with all messages and the payload which varies by message.
The function is a single octet referencing the message.
The address field contains the 3-octet source address of the message. The source address is used to identify the source of the message.
The result message contains a 2-octet unsigned result code. There are currently no result codes defined.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'00' | BVLC-Result |
| Source-Virtual-Address: | 3-octets | ||
| Result Code: | 2-octets | X'0000' | Successful completion |
A poll message is broadcast to determine if a dynamically assigned network
address is in use. If there is a client that is already using the proposed
address it responds by broadcasting an Online message. When the Online
message is received by the client proposing to use the address, it randomly
picks a different address and repeats the process.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'01' | Poll |
| Source-Virtual-Address: | 3-octets |
This message is broadcast when a client is ready to process BLVPDUs and in
response to a Poll message if the address is already in use.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'02' | Online |
| Source-Virtual-Address: | 3-octets |
This message is broadcast when the client is shutting down and will no longer be processing BLVPDUs.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'03' | Offline |
| Source-Virtual-Address: | 3-octets |
This message is the "last will and testament" that is broadcast by the broker on behalf of a client that has lost its connection with the broker.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'04' | Lost Connection |
| Source-Virtual-Address: | 3-octets |
This message contains a BACnet NPDU between clients, it can be sent directly to a client or to the broadcast topic.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'05' | Encapsulated NPDU |
| Source-Virtual-Address: | 3-octets | ||
| BACnet NPDU: | Variable length |
This message is reserved for group communications. It is sent by the client to the topic name associated with the group letting the other group members know that it has joined.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'06' | Join Group |
| Source-Virtual-Address: | 3-octets |
This message is reserved for group communications. It is sent by the client to the topic name associated with the group letting the other group members know that the client has left the group.
| Field | Length | Content | Description |
|---|---|---|---|
| BVLC Function: | 1-octet | X'07' | Leave Group |
| Source-Virtual-Address: | 3-octets |