A brief Description

Here is a brief explanation of how BACnet MSTP works. This will be somewhere between an “ELI5” and something approaching a Coles notes. FOr a technical description, I would suggest picking up the BACnet Specification, or at least checking  the BACnet Website.

A BACnet MSTP (BCMSTP from now on) consists of at minimum a Coordinator, a Master and a pair of wires connecting them.

A Coordinator, as the name implies, coordinates all activity on the MSTP trunk. It keeps track of all communication statistics, as well as correcting any disruptions in the communication. Typically the coordinator also manages any communication with external devices or a larger IT network. Coordinators are normally larger devices running bona fide operating system.  An example of a coordinator would be a Johnson Controls NAE , which runs Windows XP Embedded (no I am  being serious) or Tridium JACE, which run RIM’s QNX OS.

A Master is any device on the BNMSTP network that can talk and share information. In the context of Building Automation, a Master is a device that has sensor inputs and outputs for controlling equipment. The Master encodes real world conditions such as temperature, humidity, current draw, pressure and shares that information with other Masters on the trunk. The Master also has outputs for controlling mechanical or electrical equipment, such as fans, heaters or boilers. Masters can typically be loaded with software for controlling this equipment on its own through programming.  Masters are often smaller 16 or 32 bit microcontroller devices. Some examples of Masters would be the Johnson Controls FEC, or the Reliable Controls Mach Pro

The BACnet MSTP Trunk should look something like this, where Node and Master are interchangeable for our purposes. For the time being, ignore the Server, we’ll get to that later.d


The Communication Process

Unlike the chaotic and haphazard communication of its UDP cousin, MSTP communication is quite an orderly affair.  Communication happens in a predictable, almost deterministic way.

There are some ground rules for MSTP to keep in mind

1)Each master or node on the network has an address between 1 and 254. The Coordinator (also known as a Supervisor) has address 0.

2)Communication packets on the MSTP bus are defined as frames. There are 7 defined frame types which are described below.

Frame Types

Frame # Frame Type Description
0 Token Pass Pass the token to another master
1 Poll for Master Sends out Probes looking for a new master not yet identified
2 Reply to Poll for Master Responds to frame type 1.
3 Test Request Diagnostic Use
4 Test Response Diagnostic Use
5 Data Expecting Reply This frame contains data the requires a response from the destination. Used to request status information
6 Data Not Expecting Reply This frame contains data that does not require a response. Used to respond to requests in frame type 5.
7 Reply Postponed Used to respond to frame type 5 if the master is too busy

Each master on the network keeps a few specific pieces of information recorded.

MyAddress = the masters address.

NextMaster = the next masters address in the bus, defaults to 0 on startup.

MaxAddress = the highest address number allowed on this network. This is set in programming. Lets assume its 64 for this example.

Communication Flow

A simplified exchange would look something like this.

In the beginning all devices come on line. The network is unmapped, and none of the masters are aware of each other yet. The coordinator begins sending out polls for a master starting at address 1 until a master responds.

The coordinator continues sending out polls to incrementing addresses until a response is received. This tells the coordinator who the next master in the network is.

The token is passed to the next address. Since this master does not know who the next master is, it starts polling for the next master. This process continues from one master to the next as the network is mapped.

Eventually the token is passed to the last master on the network. This master will start polling for the next master up until the Max Master is reached. This signifies to the master that it is the last in line and it passes the token back to Address 0, the coordinator.  Now that the network is mapped, the masters can start sharing information about devices on the network

In order to request some piece of information, one master sends a Data Expecting Reply frame to another. Encoded in the packet is the specific instance number of the point the master wants to know about and what aspect of that point (ie present value, units, name etc). The host master sends back the response in a Data Not Expecting Reply frame. We’ll discuss the technical specifics of how data is encoded in a later post.

This is a pretty quick and dirty explanation of how BACnet MSTP works, but it should shed enough light to make the process a little more clear. I hope to expand on the technical details a bit more in the future.



Daedalus is a device I built in 2010 as my final project to complete my Bachelors degree at BCIT. It is a BACnet MSTP device that allowed me to communicate with an MSTP trunk and pull information from devices on that trunk very quickly.

During that time I was working as a controls technician, working on building automation systems. The tool set I had to troubleshoot and monitor devices on an MSTP trunk were well designed but significantly flawed. These tools would interrogate an MSTP host for every input/output point it had, as well as any software points programmed. On medium to larger hosts, this could take minutes to update and get new readings. This caused significant problems when I was just looking for a single point, or trying to tune a PID loop and needed fast results.

The goal of Daedalus would be to overcome this flaw and allow me to directly interrogate a single or small group of points much faster. Daedalus would physically attach to the RS485 communication lines of an MSTP trunk and communicate as if it were a host on that trunk. Daedalus had a Bluetooth link that would communicate to a user interface running on  a laptop.

Unfortunately I don’t have as much detailed information on this project as I would like, as it was nearly 10 years ago, but I’ll share what details I have.

Details – Daedalus

The software behind Daedalus is a preemptive multitasking real time kernel, which runs on an HCS12 microprocessor. The kernel, written in C/C++ was designed by David Quarbach, to whom all credit is due. On top of this kernel are several drivers to communicate both with the BACnet MSTP trunk, and to a Bluetooth transmitter. There is also a CLI for interfacing with the device directly over serial.

The limited BACnet stack Daedalus uses was written by me, and implements the minimum functions in order to maintain communication on an MSTP trunk, and poll other devices for status information of their inputs or outputs.

Daedalus Version 1

Daedalus went through several evolutionary phases, some rougher than others.

A short lived Version 2

This was one of the last iterations of the hardware design. The final version included a modular plug to plug into the MSTP trunk.

Version 3 – Final

As you can see, many of these components are modular packages from Sparkfun. However the HCS12 chip itself had to be landed on breakout board from Dangerous Prototypes, which is an excellent company to do business with. This was the first time I had to work with landing an SMT chip, and that was an experience. Not having any reflow tools, I had to do my work with a hot air station.

Dont worry, I cleaned up the solder job after the initial landing

 Details – User Interface

The user interface was written in C/C++ and provided basic control over Daedalus. The UI, which was based on ncurses, allowed the user to start/stop the information gathering process, specify the target to monitor, as well as collect diagnostic information on the MSTP trunk itself

I grew up watching Tron, and this is what I was told the future would look like


Daedalus was a great success for me. Not only was I able to monitor devices on an MSTP trunk much faster than with my existing tool set, but it taught me a great deal about embedded RTOS systems, and the BACnet protocol itself. I was able to use Daedalus in my work for a while after the project was complete, and it was a great help.

So why the name? Well that’s my Wife’s fault. According to Greek mythology, Daedalus built the Labyrinth of Crete, which imprisoned the Minotaur. He has several other accomplishments to his name and is considered one of the first Engineers in Greek mythos. I’ve always had a romantic attraction to his stories, having wanted to be an engineer all my life. So when I needed a name for this project, my wife who has a deep love for all things mythology, made the suggestion. Since then, most of my projects carry a name of a greek or roman mythological figure.

What is BACnet?

What exactly is BACnet?

Simply put, BACnet is a communication protocol that has become very popular in the Building Controls industry. It is a protocol that building control equipment use to communicate with each other in order to encode real world measurement values (ie temperature, pressure, humidity) and relay commands. It is a method of encoding and sharing information, which I suppose you could say about all communication protocols.

I’ve always enjoyed working with BACnet since I was first introduced to it in 2004-ish in my previous career as a controls technician. At that time I was coming from a world of proprietary technology and found it refreshing to be exposed to an open and license free communication standard. I also found BACnet very readable and understandable with some basic understanding of electronics and some standard tools. We’ll get more into that later.

What do I mean by the standard being open and public? Well the BACnet specification is openly published and anyone can buy a copy and read it for themselves. Its a very readable document, and with it anyone can write some software or build some hardware to use the BACnet protocol without having to pay licenses or royalties.

This is my copy of the BACnet standard I got in 2004 or so. Its well used, dogeared and missing a cover. Long story

BACnet is maintained by the American Society of Heating Refrigeration and Air-Conditioning Engineers, and I will leave it to ASHRAE to explain their history and development of the BACnet Protocol.

There are two main flavours of BACnet I focus on, and that is BACnet IP and BACnet MSTP.

BACnet IP, as its name implies, uses an IP network to communicate and UDP as the transport layer. Why UDP? Well, UDP (analogues to mailing a letter)  has very little overhead and can be implemented on pretty simple hardware. TCP (analogues to making a phone call) on the other hand has more overhead to maintain connections and could be taxing on older, smaller devices. Keep in mind we’re talking about small 8bit or 16bit microcontrollers implementing these stacks back in the day before 32bit micros became cheap and plentiful.

BACnet MSTP (master slave token passing) uses RS-485 and is limited to smaller network sized. This is still popular on smaller devices or in applications with smaller network runs. Its very easy to develop and troubleshoot.

The first time I got really under the hood with BACnet was in university when I built a piece of BACnet MSTP diagnostic equipment. This was a really interesting project involving hardware design and writing a preemptive multitasking kernel on a 32 bit microprocessor. This was Project Daedalus, and also involved writing my own (limited) BACnet MSTP stack. I’ll write up more about Daedalus at a later date.

Working on Daedalus really gave me an appreciation for what I could do with BACnet and how easy it was to develop. Since working on Daedalus, I’ve started a new project, Icarus, which is the direct decedent of Daedalus but for BACnet IP.  More on that later.

This work has also opened my eyes to the security ramifications of BACnet, and just how easy it is to exploit and possible cause significant damage. We all remember how Mr.Robot was able to bring down Steel Mountain using an Raspberry Pi and access to a thermostat.

I’ll discuss the feasibility of this attack in a later instalment. Spoiler alert, its pretty realistic.

So that’s my quick and dirty run down of BACnet. In upcoming posts, I’ll go into further detail on my own work exploring BACnet and various projects that I hope will shed more light on this protocol and its ubiquitous use in the industry. Enjoy.