BACnet to MQTT Integration: Architecture and Considerations

The appeal is obvious. On one side a protocol designed for building controllers on a trusted network; on the other a publish and subscribe broker that any modern application can consume without knowing anything about buildings. A gateway in between translates, and suddenly the data is available to analytics, dashboards and maintenance systems without any of them touching the plant. The pattern is sound. What determines whether the result is usable in two years is a set of decisions that look like implementation detail and are actually data modelling.

The message up front: the topic structure is a public interface and changing it later breaks every consumer, so design it before anything is built. Put the metadata in the payload rather than relying on the topic to carry meaning. Decide explicitly what happens to messages while a consumer is away and while the broker is unreachable, because the default answer is that they are lost. And keep the bridge one-directional unless you have deliberately decided otherwise, because a broker that can write into the building is a very different risk from one that cannot.

1. Why bridge at all

• Isolation. Consumers never speak the control protocol and never reach the controls network, which is the strongest form of the read-only argument in securing read-only BACnet data access.
• Fan-out. One connection to the building serves many consumers. Each additional analytics tool, dashboard or maintenance integration subscribes to the broker rather than adding load to a trunk, which matters for the reasons in BACnet polling schedules.
• Loose coupling. Replace the head end and consumers do not notice, provided the topic structure survives. That independence is the same argument made in what is a BMS data historian.
• Ordinary tooling. Developers and data teams can work with a broker without controls knowledge, which is usually the practical reason the question comes up.

The cost is a component in the middle that has to be run, secured, monitored and kept current, and which becomes a single point of failure for everything downstream.

2. Topic structure, which is the decision that lasts

A topic hierarchy is an interface. Consumers subscribe to patterns within it, and once several systems depend on a shape, changing it is a coordinated migration rather than a configuration change. Design it as deliberately as you would a database schema.

Principles that hold up:

• Hierarchical, from broad to specific, so that consumers can subscribe at the level they care about: everything on a site, everything of one measurement type, or one individual point.
• Stable identifiers in the path, not names. A topic containing a point name breaks when somebody renames the point, which is the same failure described in BMS point-to-asset mapping. Use the structural identity.
• No volatile attributes in the path. Anything that can change without the underlying thing changing, a floor reference after a refurbishment, an owner, a status, belongs in the payload.
• Separate data from events from commands at the top of the hierarchy, so that a consumer of readings cannot accidentally subscribe to alarms, and so that command topics can be permissioned separately or not exist at all.
• Consistent depth. A hierarchy where some branches are deeper than others makes wildcard subscriptions unreliable and is the most common structural mistake.
• Version it. A version element near the root costs nothing and makes a future change additive rather than breaking, because both shapes can run in parallel during a migration.

3. What goes in the payload

A self-describing payload costs a little bandwidth and removes an entire category of integration bug, because no consumer has to hold assumptions about what a given topic means.

4. Delivery, retention and the gap

This is where the pattern most often disappoints, because publish and subscribe is by default a live-only arrangement: a consumer that is not connected simply does not receive what was published while it was away.

• Decide the delivery guarantee deliberately. Brokers offer different levels of assurance, trading throughput against certainty, and the right choice differs between a dashboard value and an alarm. Choosing one level for everything is the usual shortcut.
• Understand what a retained message does. It gives a newly connected consumer the last known value for a topic, which solves the cold-start problem and nothing else. It is not history.
• Plan for consumer absence. Durable sessions, where supported, queue messages for a disconnected consumer. Without them, a consumer restart means a gap nobody records.
• Plan for broker absence. If the bridge cannot publish, it must buffer and forward rather than discard, which is the mechanism in store-and-forward buffering for BMS gateways. Without it, a broker restart costs you the data from that window permanently.
• Handle out-of-order arrival downstream. Buffered messages arrive late with old event times, so any store consuming the broker has to accept them, which is the requirement discussed in the historian article.

The honest summary: a broker is a transport, not a store. If you need history, something downstream has to be persisting it, and the bridge has to buffer when that path is interrupted.

5. Keep it one-directional unless you decided otherwise

Most bridges support publishing data outward and accepting commands inward. The second is a substantially larger decision than it appears during commissioning, because it means a message on a broker can change the building.

• Default to outward only, and state it in the design document rather than leaving it implied by the absence of a command topic.
• Where writes are genuinely required, separate the command topics completely, permission them separately, and apply the write-priority discipline in BACnet objects, device instances and addressing, including an explicit release.
• Log every command with origin, time and outcome. A write arriving over a broker with no audit trail is the worst combination available.
• Verify the claim the same way as any other, with the priority array inspection in the acceptance test checklist.

6. Running it

• The bridge is now critical infrastructure. Everything downstream depends on it, so it needs monitoring, patching, an owner and a recovery plan, like any other production component.
• Monitor both sides. Reads from the building and publishes to the broker, separately, because a bridge can be healthy on one side and stalled on the other. This is the heartbeat argument in BMS ingestion monitoring.
• Secure the broker properly: authentication per client, authorisation per topic, encryption in transit, and no shared credentials across consumers. A broker with one password shared by four systems cannot be audited or revoked selectively.
• Document the topic structure as an interface specification, versioned, with an owner, because that is what it is.
• Watch for consumer sprawl. The ease of subscribing is the point, and it also means nobody knows who is consuming what by year two unless somebody keeps a register.

The idea to walk away with

The bridge itself is the easy part. What determines whether this is still working in three years is the topic structure, which is an interface that consumers will couple to, and the honesty of the payload, which decides whether a consumer can interpret a message without private knowledge.

Get both right at the start, decide deliberately what happens during the gaps rather than discovering the default, and keep the bridge one-directional unless somebody has explicitly accepted the alternative.

Final thoughts

If a bridge already exists and you are inheriting it, the two questions worth asking first are what the topic structure is and whether it is documented anywhere other than in the gateway's configuration. An undocumented topic hierarchy with several consumers attached is effectively frozen, because nobody can establish what a change would break.

Writing that specification down retrospectively is unglamorous and it is the thing that makes every later change possible.

Related reading: Store-and-forward buffering, Securing read-only BACnet access, BACnet objects and addressing, What is a BMS data historian, IoT and BMS integration, BACnet acceptance test checklist.