Your gateway into the IoT (Internet of Things) world for a Smart Building starts with BACnet and MQTT (Message Queuing Telemetry Transport) tech. In the simplest explanation, they enable you to communicate with your building and enable smart systems easily from any Internet connected device – laptop, smartphone, voice assistant. Part 1, covers the basics you need to know about how integrating BACnet with MQTT can make your building ‘smart’.
(ASHRAE/ISO) BACnet is a data communication protocol for ‘Building Automation and Control Networks’ developed to enable building automation communication with control systems such as lighting, HVAC (heating, ventilation and air conditioning), fire detection, access, lift monitoring and associated devices manufactured by a variety of international vendors. It became a standardised protocol in 1995 and then received international status in 2003.
BACnet has a ‘client-server’ based architecture, wherein the ‘client’ machine requests a service from a ‘server’ machine that would then perform the requests and report results to the client. Its standardised model gives it the ability for communicating with a multitude of control systems/devices and the capability to be expanded upon for accommodating future BMSs/BEMSs (Building Management System)/ (Building Energy Management System).
The BACnet model publishes environmental ‘CoV’ (Change of Value) changes to interested parties that subscribe to them (- e.g. akin to the function of MQTT), but the historical (if not for some part current) concern is the fear of flooding the local (BMS/BEMS) network with traffic that on the whole (/over time) might no longer be listened to – this would be more likely true of a CAN v2.0A bus (backbone) network (with its slower bandwidth/throughput speed of 125 kbps).
The complex hierarchical structure of a BACnet can make it difficult to integrate with devices due to the low-level of the interaction and still requires a knowledge of the target device in order to effectively instigate the desired/correct change – both in terms of the manufacturer’s base-build hardware/config and the selected configuration/conventions that the commissioning engineer has applied. Also, typically the products/controllers/devices only connect locally to the BMS.
MQTT is an IoT, machine-to-machine connectivity protocol developed as a ‘publish/subscribe messaging’ transport and has OASIS Standard membership. It is very lightweight and can function with weak network broadband, hence it is ideal for use on lower-power devices i.e. mobile phones.
Its publish/subscribe architecture is an alternative model to the traditional client-server one BACnet uses. MQTT acts as a message broker, filtering all messages from the publisher and distributing them appropriately to all the subscribers, post office meets subscribed-to social-feed.
Thus, MQTT can continually publish notifications about the device(s) it is publishing for e.g. a luminaire, and an interested user(s) on their mobile device can choose whether to subscribe to e.g. light ‘on’ status, so that their mobile device is not drowned with undesired notifications. It also has Quality of Service (QoS) dimensions, meaning you can easily choose which messages you want confirmation of successful delivery on, e.g. confirmation of light turned off.
An MQTT network can be integrated with a BACnet by layering an ‘environmental-change’ publisher on top of a BACnet/IP installation. This can be done by installing MQTT software i.e. attaching an BACnet to MQTT converter (pre-programmed microchip to a BACnet device) or having a software layer publish a more human-like interpretation of the observed low-level change, adding an MQTT ‘broker’ server and MQTT clients (i.e. computer, smartphone). This way, publishers and subscribers will only need the port and IP/hostname of the broker to connect.
Once the physical parts are setup, a developer would first align the parameters of MQTT and BACnet.
Then the MQTT ‘topics’, deemed to be of interest to potential (MQTT) clients, (to be published/subscribed) would need to be defined.
Finally, they would determine the list of BACnet objects (/object-properties) that the converter would read from in order to publish the various notifications.
One benefit of adding MQTT to BACnet is that physical MQTT converter products can simply be added onto most pre-existing BMS equipment and act as an overarching layer in the encompassed controller’s pipeline of day-to-day operations. Meaning it makes a highly cost-effective option opposed to ripping out and replacing equipment with brand new bleeding-edge industrial IoT and smart-enabled devices. Therefore, it can provide building management a bespoke ‘utility-belt’ to fit the many different shapes, sizes and building-materials of today’s assorted structures – irrespective of their architectural making.
Another key benefit is that it empowers you to author and own the change-set/change-management ‘topics’ (of interest) glossary. Subsequently embellishing the ability to fine-tune which ‘topics’ you want to publish and subscribe to a depth that suits your own multifaceted needs.
Cloud- based orchestration with MQTT’s ability to use the encrypted TLS/SSL protocol, outshines BACnet – which has its own security provisions that have been slower and difficult to gain universal adoption.
There are additionally other options to publish/subscribe per type-based and content-based filtering (that BACnet does not have).
Leveraging MQTT can break-up complex hierarchical structures in BMSs to non-hierarchical (‘bigger-picture’) architecture by including smart and independent device controllers (to add to the sweeping ‘paintbrush’ of estate-wide monitoring and reporting needs that generally help efficiency and profitability of operations).
The ‘plug n play’ functionally may well be the best multipurpose feature especially since its embracing of integration-technologies that have less of an initial steep implementation climb.
Ultimately, scalability is more optimal with MQTT rather than using BACnet alone.