Building Automation System MQTT: How MQTT Fits Next to BACnet and KNX

A building automation system MQTT layer lets you take data that is locked inside BACnet controllers, KNX lines and Modbus meters and publish it to one place where dashboards, analytics and alerting tools can use it. This guide explains where MQTT belongs in a building management system (BMS), what it should and should not replace, and how to design topics, gateways and security so that dozens of buildings can share a single broker.

Why Buildings Need Another Protocol at All

Most commercial buildings already run a mature field protocol. BACnet dominates HVAC and central plant, KNX is common for lighting, blinds and room control in Europe, and Modbus RTU or TCP shows up in energy meters, chillers and variable speed drives. These protocols are good at what they were designed for: deterministic control on a local network, with object models that HVAC engineers understand.

What they are poor at is leaving the building. BACnet/IP relies on UDP broadcasts and assumes a flat, trusted LAN. KNX/IP routing uses multicast. Neither crosses a firewall gracefully, neither was designed for thousands of remote subscribers, and opening them to the internet is a well-known security mistake. Facility teams that want a portfolio view of energy use, comfort complaints or equipment faults end up with one front-end per site, each with its own login and export format.

MQTT solves exactly that gap. It is a lightweight publish/subscribe protocol where every device and application makes an outbound TCP or TLS connection to a central MQTT broker. Gateways in each building translate local points into topics, and anything that needs the data subscribes, without knowing where the gateway is or how many sites exist.

Where MQTT Sits in a Building Automation System

Think of a building in three layers:

1. Field level – sensors, actuators, VAV boxes, KNX push buttons, meters. Communication is BACnet MS/TP, KNX TP, Modbus RTU, DALI, or proprietary buses.
2. Automation level – controllers and supervisory stations that run control loops, schedules and interlocks. This is still BACnet/IP, KNX/IP or Modbus TCP.
3. Integration level – the place where data is normalized and shared with the rest of the organization. This is where MQTT belongs.

The important rule is that control loops stay local. A supply air temperature PID loop must keep running if the internet connection drops, so it lives in the controller, not in the cloud. MQTT carries telemetry upward and, carefully, setpoint changes or schedule overrides downward. In practice the building automation system MQTT layer is a northbound interface, not a replacement for the field network.

Protocol roles compared

Gateways: Turning Points into Topics

Every building needs at least one gateway. It reads points from the field protocol and publishes them as MQTT messages. You have three realistic options:

• Built-in MQTT in the controller or supervisor. Many recent BMS controllers and building operating systems can publish MQTT directly. Check whether they support TLS and username/password authentication before you rely on them.
• A small Linux gateway. A Raspberry Pi class device or an industrial PC running a script or Node-RED flow. Our tutorials on BACnet to MQTT and KNX to MQTT show complete open-source bridges.
• A commercial protocol gateway. Useful when you need certified BACnet behavior or have hundreds of points per device.

Whatever you choose, the gateway should poll or subscribe locally (BACnet COV subscriptions, KNX group telegrams), apply deadbands so you do not flood the broker with noise, and publish JSON with a timestamp, value, unit and quality flag.

{
  "ts": "2026-10-16T08:15:02Z",
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "source": "bacnet:1201/analogInput:3"
}

Including the original object reference in source makes troubleshooting far easier when somebody asks why a dashboard value differs from the BMS front-end.

Designing Topics for Multi-Site Buildings

Topic design is the decision you will live with longest. A hierarchy modeled on physical location works well for buildings because people think in those terms:

<org>/<site>/<building>/<floor>/<zone>/<equipment>/<point>
acme/ist01/tower-a/f12/zone-east/ahu-2/supply-air-temp
acme/ist01/tower-a/f12/zone-east/ahu-2/filter-dp
acme/ank02/hq/f03/meeting-301/occupancy/present

This mirrors the ISA-95 style used in factories (enterprise, site, area, line, cell), which matters because ConnectMQ recognizes ISA-95 and Unified Namespace topic structures and can show devices grouped by those levels in its devices view. Facility managers can then browse a portfolio by site and floor instead of searching through flat topic lists.

A few practical rules:

• Use lowercase, hyphens instead of spaces, and no personal names in topics.
• Keep the point name last so wildcards stay useful: acme/+/+/+/+/+/supply-air-temp returns every supply temperature in the portfolio.
• Publish slow-changing metadata (units, setpoints, equipment model) as retained messages so new subscribers immediately know the current state.
• Separate commands from telemetry, for example .../ahu-2/cmd/setpoint versus .../ahu-2/supply-air-temp, and let only authorized clients publish to command topics.

If you already run industrial sites, the same thinking appears in our article on Sparkplug B and the Unified Namespace.

Writing Back to the Building Safely

Reading data is low risk. Writing setpoints from the cloud is not. Before any MQTT message can change a value in a BACnet or KNX device, put guard rails in the gateway:

1. Maintain an explicit allow-list of writable points. Never expose a generic "write any object" topic.
2. Validate ranges in the gateway (for example, a zone setpoint between 18 and 26 degrees Celsius).
3. For BACnet, write at a defined priority and relinquish it when the override ends, so local schedules take over again.
4. Echo the accepted value back on a state topic and log who requested it.
5. Use QoS 1 for commands and make the handler idempotent, because a QoS 1 message can arrive twice. Our guide to MQTT QoS levels explains why.

Centralizing Many Buildings in One Broker

Once every gateway publishes outbound, centralizing a portfolio becomes a hosting decision. You can run a broker in your own data center, but then you own patching, certificates, monitoring and capacity planning for a system that facilities teams expect to run around the clock.

A fully managed MQTT service removes that work. With ConnectMQ, each building gateway connects to the same broker over TLS on port 8883 with its own generated credentials, and the portal gives you a live topic explorer to inspect what each site publishes. Threshold alert rules can flag conditions such as a supply air temperature that stays out of range, and the alerts log keeps a history of when they fired. Dashboards, Node-RED flows, Telegraf collectors or Python services that write to your database connect as ordinary MQTT clients and subscribe with wildcards.

Sizing checklist

1. Count gateways per site plus every consuming application; each is one connection.
2. Estimate messages per second after deadbands, not raw polling rates.
3. Check the largest message you need (a full equipment snapshot can be larger than a single point).
4. Decide whether you need QoS 2 or shared subscriptions for load-balanced consumers.
5. Plan for isolation: a portfolio with strict tenant separation may justify a dedicated cluster.

Small pilots fit the free Serverless plan (up to 25 connections, QoS 0 and 1, 256 KB messages). Larger portfolios move to the paid Serverless tier (up to 1,000 connections, QoS 2, shared subscriptions) or a Dedicated cluster.

Security Considerations Specific to Buildings

Building networks are frequently flat, old and shared with contractors. MQTT helps because gateways only need outbound connections, so you never open inbound firewall ports for BACnet or KNX. Beyond that:

• Always use TLS (port 8883, or 8084 for secure WebSocket dashboards).
• Give each gateway its own credentials so a compromised device can be revoked without touching others. ConnectMQ binds client IDs to issued credentials and blocks IPs after repeated failed logins.
• Keep the gateway on a separate VLAN from the field network, with only the ports it needs.
• Never publish personal data such as badge IDs on topics that many applications can read.

The broader checklist in MQTT security best practices applies to buildings as much as to factories.

A Realistic Rollout Plan

Start with one building and a small set of high-value points: supply and return temperatures, filter differential pressure, main energy meter, and a few zone temperatures. Publish them to the public MQTT test broker only if the data is non-sensitive and you just want to validate payloads; move to a private broker as soon as real addresses or occupancy data are involved. Add alerting next, then dashboards, then a second site. By the third building you will know whether your topic scheme scales. For more use cases see our IoT automation guide, and for specific applications read HVAC monitoring with IoT sensors.

Connect Your Buildings to ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card needed. You get a username, password and client ID for your first gateway in minutes, and the topic explorer shows your building data the moment it arrives. When the portfolio grows, upgrade the plan without changing your topic design.

Frequently Asked Questions

Does MQTT replace BACnet in a building automation system?

No. BACnet and KNX remain the control networks inside the building. MQTT is the integration layer that carries selected points to dashboards, analytics and other sites.

Can I control HVAC equipment over MQTT?

Yes, through a gateway that writes to the controller, but restrict it to an allow-list of points, validate ranges and keep control loops local so the building keeps working if the connection drops.

What QoS should building telemetry use?

QoS 0 is fine for frequent readings where the next value arrives soon. Use QoS 1 for alarms and commands, and make command handlers idempotent.

How many connections does one building need?

Usually one per gateway plus one per consuming application. A typical pilot building with a single gateway and a dashboard needs only a handful of connections.