Hey folks! Phil Zito here and welcome back! In this post, we are going to be discussing how MQTT works in building automation. It's pretty easy to know how it works in IoT, but how does it work in building automation?
So MQTT came out of the SCADA world. They were looking for a lightweight protocol that would be able to essentially take a message from some sort of low power, low requirement device and share that with a lot of devices. Now, you might be saying to yourself, Phil, why in the world would we need MQTT when we have BACnet? What would be the point of this, because the end of the day, BACnet has read property, it even has read property multiple, and it has write property, and write property multiple. Why would we want to use MQTT?
Well, there's several reasons we're starting to see a lot of sensor providers use MQTT out in the market. First off, whenever we think of a sensor, if I said to you “BACnet MSTP temperature sensor,” what would be the first thing that came to mind? Usually that is expensive, and most of the time, that's true. If we have a temperature sensor that is BACnet MSTP or BACnet IP, it's usually quite expensive, and the way we communicate to those, we're limited to MSTP or IP. So, we have to use some form of physical medium to connect to the sensor.
Now the IoT space, Internet of Things space, has gone in a separate direction. MQTT is one of the leading protocols for IoT sensor, publishing, as well as subscription. Now you may not know what those terms are, but by the end of this post, you're going to definitely know what these terms are. We're going to go through the terminology of a client, a broker, we're going to talk through those. We're going to talk about the publish/subscribe framework. We're going to talk about different encryption and security methods that followed just normal standards.
So MQTT, right, we have this protocol that comes out of the SCADA world, out of the industrial world, enters into the IoT space and the reason it entered into the IoT space was, these IoT devices are typically low-powered devices. Think of like a contact sensor, something that's not streaming data, it's sending data based on an event. That event may be a change in temperature, that event may be a change in status, but it's an event driven protocol. So, when we think back to change of value, COV trending, we're all familiar with event driven protocols: change of values and event driven. We set a threshold of either a Boolean state change or a numeric state change, and once that threshold is met, then the subscribe to COV sends.
So, I know some of you may be like, okay, Phil, we have COV, we have read property and write property multiple in BACnet, why would we be using MQTT? Trust me, I promise you, we'll get there, and we'll also talk about how to implement MQTT, alongside existing BACnet traditional building automation systems. But the thing is, MQTT is a very lightweight protocol. I mean, if I were to go into an MQTT stack, so I’ll go to MQTT C# Example:
So, as you're looking at this example, I know that for some of you who don't know how to read code, you're going to be like, okay, what the heck am I looking at. The reason this is lightweight, is we initiate the client, we pass through a client ID, and then you can start initializing the broker address. Then, you can go and basically connect the client.
When you connect the client, you could do all sorts of like sending stuff, etc. You could just connect client, you can subscribe to, grabbing a topic, you can also publish a topic, right? And this is it. That's all that has to happen for us to be able to, as a manufacturer, implement an MQTT client.
You could do this even lighter weight with other coding languages. So, this is super lightweight. No, if I were to bring up another BACnet Explorer C# library. This is implementing read/write.
There's a lot of stuff and a lot of supporting libraries under the stuff that you're not even seeing. It is a much heavier protocol. Now, granted, it does give us a lot of capabilities that we don't have otherwise. For example, when we look at that C# BACnet protocol, what you're not seeing is the ability to implement a device object, the ability to implement objects to have a graphical user interface overlay with a programming tool that enables us to make programming changes to these devices.
There are master devices and slave devices. Most of our sensors that we pick up with BACnet are slave devices, but they have a ton of capabilities built into them. Where MQTT starts to shine is that it is very lightweight, and it's typically focused on one or two objects. Usually one object, in the case of like a temperature sensor, it would publish that temperature sensor value to a broker, which would then distribute that data to all of these clients. That'll become very important a little bit later in the post, when we start to talk about how we map in devices that are MQTT devices.
The important thing is that all the heavy lifting exists in the MQTT broker. But Phil, we can make programming changes, and we can do things that are programmatic in a broker. Yes, you're absolutely right. There's overlay stuff like, I think, HiveMQ allows you to have a broker appliance, and you can use things like Node-RED JS to do programming of the broker. You can also host brokers in AWS and do programming in that environment as well. You can have a soft broker, or you can have a physical hard broker.
At the end of the day, the actual device itself is very lightweight and can use LoRaWAN, can use stuff like ZiggBee, and I think EnOcean supports MQTT, but I could be wrong. Usually not Wi-Fi, that's usually more energy intensive, and doesn't fit the kind of profile that we're looking for but could if you needed to use Wi-Fi. So, you have a bunch of wireless distribution methods.
Okay, so imagine this scenario, you have a customer, and they want to put sensors, maybe for environmental purposes, throughout their building. Putting a bunch of wireless sensors is infeasible. If I just look up wireless BACnet temperature sensor, let’s see how much that is going to cost me: $139, $109, $99, and these are just things I'm finding on Google. What people traditionally are going to come up to is going to be things like the ACI sensors, etc. They're going to be BACnet, they're going to be easy to pull in, but they're typically going to be in the area of $100, so expensive.
Let’s look up MQTT temperature sensor. I can find these as low as $29. I can find some as low as $7, granted, that's more of a do-it-yourself which I wouldn't recommend in a production environment, but you can find them relatively inexpensive. Just to show you what I'm talking about here.
This is kind of what's going on, right you have a sensor, you have some sort of broker, and then you have some sort of client that is going to receive from that sensor. The Node-RED allows you to set it up. Now this is all like do-it-yourself automation stuff here, but that's where the market is going and that is why to NOT do it yourself, but this lightweight kind of single purpose sensors.
That's why you see people who are advocating MQTT as a solution for low-cost, high-density sensors. You better believe these are coming down the pipe, post COVID, and with all of these utility costs increasing, people are going to want to get really dialed in on their environmental variables so that they can:
- Show a perception of good environmental quality to their tenants.
- Measure the environmental quality of their building and make appropriate energy-based sequencing decisions.
- So that they can be in compliance in certain municipalities, which are going to require IAQ measurements down the road.
It's a lot cheaper to do it with these kinds of sensors than it is to implement it with traditional BACnet sensors.
Additionally, MQTT provides not only the ability to have lightweight communication, but it also can go over unreliable, specific networks, things like cellular networks, and has the ability to store, reconnect, and resend. So, kind of like what we can do with our trend buffers, but a lot of points are not going to store that historical data in the sensor. It's going to rely on the actual field device, like the supervisory device, to store all that. So, we see that the broker enables us a lightweight, low-cost way of storing data that is significantly less expensive than a supervisory device.
Additionally, it has security built into it. Not a terribly important thing, in my opinion, to be totally honest, but it's something that is becoming more important to specific customers, where they want to know what is connecting to their network, and they want to be aware of it.
Okay, so at this point, a lot of you are like, alright, Phil, how do we connect this to our building automation network? How do we get this to work with like, whatever we're trying to do?
So, the first thing we want to do is we want to get some form of MQTT driver or device. We want to have a way to go and actually pull that MQTT data into our building automation system. Now, traditionally, an easy way to do this was with Node-RED. So, Node-RED is a software that basically takes the programmatic aspects of programming and extrapolates them into visual programming.
So, you can just use drag and drop blocks, and then it enables you to run this kind of code environment that sits on top and allows you to run it on your computer, on a device, in the cloud, etc. The nice thing about it, is that you'll see there's a library of flows that you can pull from.
Flows are basically what Node-RED calls like design patterns. So, we could go in here, we could type in an MQTT flow, and we would be able to grab an MQTT flow, take that MQTT flow, and then we could write it to an API.
This one is Controlling Indoor Air Quality and Ventilation Using ZiggBee Devices. So, right here, they're talking about taking a sensor, a “ziggbee2MQTT” base topic, and they are going to then publish the IAQ, as well as some other things like garage door status, backdoor entry light, bathroom vents, etc, and then they are going to report that as well as communicate it to the Allen Bradley PLC, and then that's going to enable them to control the HVAC system.
So, this is what you could do, like once you learn this, you can go and start to see patterns that are previously developed. You would develop this in Node-RED, you would push it out via an API, or with Node-RED, you could use the Node-RED BACnet flows.
So, you could actually grab MQTT data, and you could execute a BACnet write. You could stand up a BACnet client, with your Node-RED as a client, or as a device, most likely a device, and then give it its device ID, give it its IP address, discover it, and then execute write commands or read commands from that MQTT data. So, the MQTT data would then be typed into something that could be used as a BACnet read, and you would be able to then read that into your building automation system.
So, these are some of the ways that I see a lot of people doing MQTT implementations into their building automation systems.
What I want you all to take out of this, is there's a whole world of protocols and sensors that are available to you. You can go, using libraries like Node-RED, you can look up flows. That's the nice thing about open-source software. If you were to type simply, HVAC, I get results for climate control, Raspberry Pi HVAC, and I get some dashboarding though.
That's like another nice thing, right? Let's say you wanted to create an on-demand dashboard, you could do that. You could pull MQTT data, you could pull the data from the utility, and you could pull that into Node-RED. Then you can push all of this out as an HTML file onto a web browser, and you could display the data. This is stuff I used to do in my previous life, but it's a lot of fun. So, at the end of the day, MQTT is another way of delivering data.
Now, I haven't covered the publish/subscribe, but I’ll cover it real quick. So, how MQTT works in a nutshell, is you have an MQTT client, and that client will publish to a topic. This is a key value structure very similar to JSON, so, the topic temperature. Then it will publish a value to that topic that goes to the MQTT broker, and at the broker, the broker will have clients that are subscribed to the topic. So, this temperature sensor is publishing to topic temperature, and it's publishing a value, and then these clients will subscribe to this topic. So anytime this threshold is hit, and this device publishes, they will get a published value sent to them by the MQTT broker. So that's essentially how MQTT works.
Now the nice thing about MQTT is that it allows you to do things like OAuth and TLS. OAuth being an authentication service, similar to LDAP, where you can basically stand up your own authentication server using IDs. You can basically authenticate anything that connects to your network. Additionally, you can use TLS, which is Transport Layer Security, which is basically what we use now since SSL is compromised. You can use TLS and you can use certificating to not only encrypt your data, but also to non-repudiate your data, or make sure that the data came from the right person, eliminate man in the middle attacks, all that fun stuff.
So, MQTT adds a lot of capabilities. It is something that if you are trying to do wide scale data monitoring of sensors, I really encourage you to explore. It is very, very easy to work through. I think anyone with about two to three months of programming could probably create their own MQTT device using the MQTT library.
You could grab an Arduino board off Amazon if you wanted to look at some example code. I mean, literally, there's like only nine functions to write for an MQTT client on an Arduino device, and that's if you're using something heavy, like C#. You could use a scripting language like Python and be even lighter than that. So just be aware of that.
You could implement your own MQTT device at home if you wanted to play around with it. At the end of the day, from a production perspective, MQTT, what you're going to do is you're going to find sensors and find a broker software or implement your own broker. You could implement your own broker actually, in a Node-RED appliance that you run on the same server as your BAS server.
So like, maybe your BAS server is Port 443, maybe your Node-RED is like 4343, and so that's your port for that. You would implement a broker and that broker then could subscribe to a bunch of topics from a bunch of different sensors, then could publish those to like an API or a BACnet endpoint or an HTTP endpoint, in Node-RED, that you could then pull into your building automation system. You could pull it into like digital signage, you could pull it into just a simple web page. There's a variety of things you can do.
So, I hope this has been helpful. I know it was a little geeky. I'm always cautious about going down this rabbit hole of whether I get like super geeky on this because I don't want to lose my audience. But you tell me if it’s too in depth or not in depth enough.
So, thanks a ton, and take care.
