HVAC Digital Twin for Energy Optimization: AHUs and Chillers over MQTT

An HVAC digital twin is a live software model of your air handling units, chillers and pumps, fed by real sensor data so you can see how the plant behaves and where it wastes energy. In this article you will design one end to end: pulling points from BACnet controllers, publishing them over MQTT, structuring the topic tree, and running analytics that find simultaneous heating and cooling, low chiller delta-T and drifting setpoints. Everything uses open tools and a standard MQTT broker.

Why HVAC Is a Natural Fit for a Digital Twin

Heating, ventilation and air conditioning is typically one of the largest energy consumers in commercial buildings, and much of the waste is invisible. A valve that leaks, an economizer damper stuck closed or a chiller running with a poor temperature difference rarely triggers an alarm in the building management system (BMS). The building stays comfortable while the energy meter quietly climbs.

A digital twin makes these problems visible by combining three things:

1. Live data from every relevant point: temperatures, pressures, valve and damper positions, fan speeds and power.
2. A model of how each asset should behave: design delta-T, expected fan power at a given speed, the sequence of operations.
3. Comparison logic that flags the gap between expected and actual behaviour.

The twin does not replace the BMS. The BMS keeps controlling the plant; the twin observes, analyses and advises. If you are new to the concept, start with our pillar guide to digital twin technology.

Reference Architecture

BACnet/IP controllers (AHU, chiller, VAV, meters)
        |
        |  BACnet ReadProperty / COV
        v
BACnet-to-MQTT gateway (edge PC, industrial gateway or Node-RED)
        |
        |  MQTT over TLS, port 8883
        v
Cloud MQTT broker (ConnectMQ)
        |
        +--> Python analytics service (subscriber) -> publishes KPIs and faults
        +--> Dashboards and 3D views (WebSocket, port 8084)
        +--> Time-series database via Telegraf or a custom subscriber

The gateway is the only component that speaks BACnet. Everything above it speaks MQTT, which decouples analytics, dashboards and storage from the building network. Several commercial gateways and open-source options can poll BACnet objects and publish them as MQTT messages; Node-RED with a BACnet contribution node is a popular choice for pilots.

Keep the gateway read-only at first. Writing setpoints back to the BMS is possible, but it should come later, after the twin's recommendations have earned trust and with proper change control.

Points to Collect

You do not need every point in the BMS. Start with the ones that drive energy and comfort:

A practical polling interval for most of these points is one minute. Fast-changing values such as fan power can use change-of-value (COV) subscriptions on the BACnet side, with a deadband so the gateway does not flood the broker.

Topic Design for an HVAC Digital Twin

A consistent topic hierarchy is what lets the twin, dashboards and analytics find data without configuration per point. An ISA-95-style structure works well for buildings too: enterprise, site, area, asset.

acme/hq-building/plant/chiller-1/telemetry
acme/hq-building/plant/chwp-1/telemetry
acme/hq-building/floor-3/ahu-3/telemetry
acme/hq-building/floor-3/ahu-3/faults
acme/hq-building/floor-3/ahu-3/kpi

Group related points of one asset into a single JSON message, published at the polling interval:

{
  "ts": "2026-10-16T09:42:00Z",
  "sat": 13.1,
  "rat": 23.4,
  "mat": 17.9,
  "oat": 9.6,
  "clg_valve": 42,
  "htg_valve": 18,
  "oa_damper": 20,
  "fan_speed": 78,
  "fan_kw": 11.2,
  "filter_dp": 185
}

Chillers follow the same pattern with fields such as chws and chwr (chilled water supply and return temperature), flow_lps (flow in litres per second), kw and status, which the analytics below rely on.

Using one message per asset rather than one message per point keeps timestamps aligned, which matters when your rules compare several values at the same instant. ConnectMQ recognises ISA-95 style topic hierarchies, so the portal's devices view groups assets by level. Our article on ISA-95 digital twins explains the naming model in depth.

Analytics That Find Energy Waste

The twin's value comes from simple, explainable rules. The Python service below subscribes to every AHU and chiller in the building, applies three classic checks and publishes results back to MQTT, where dashboards and alert rules can pick them up.

import json
import time
import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PORT = 8883
SITE = "acme/hq-building"

DESIGN_CHW_DELTA_T = 5.5      # degrees C, from the chiller design data
VALVE_OVERLAP_PCT = 10        # both valves open more than this = waste
ECON_OAT_MAX = 15.0           # free cooling expected below this outdoor temp


def check_ahu(asset, d):
    faults = []
    if d["clg_valve"] > VALVE_OVERLAP_PCT and d["htg_valve"] > VALVE_OVERLAP_PCT:
        faults.append("simultaneous_heating_cooling")
    if d["oat"] < ECON_OAT_MAX and d["clg_valve"] > 20 and d["oa_damper"] < 30:
        faults.append("economizer_not_used")
    if d["filter_dp"] > 250:
        faults.append("filter_loaded")
    return {"faults": faults, "fan_kw": d["fan_kw"]}


def check_chiller(asset, d):
    delta_t = d["chwr"] - d["chws"]
    tons = d["flow_lps"] * 4.19 * delta_t / 3.517     # kW thermal to refrigeration tons
    kw_per_ton = d["kw"] / tons if tons > 1 else None
    faults = []
    if d["status"] == "on" and delta_t < 0.6 * DESIGN_CHW_DELTA_T:
        faults.append("low_delta_t")
    return {"delta_t": round(delta_t, 2),
            "kw_per_ton": round(kw_per_ton, 3) if kw_per_ton else None,
            "faults": faults}


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{SITE}/+/+/telemetry", qos=1)


def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    area, asset = parts[2], parts[3]
    data = json.loads(msg.payload)

    if asset.startswith("ahu"):
        result = check_ahu(asset, data)
    elif asset.startswith("chiller"):
        result = check_chiller(asset, data)
    else:
        return

    base = f"{SITE}/{area}/{asset}"
    client.publish(f"{base}/kpi", json.dumps(result), qos=1, retain=True)
    if result["faults"]:
        client.publish(f"{base}/faults", json.dumps({"ts": time.time(), "faults": result["faults"]}), qos=1)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()   # system CA store trusts the broker's Let's Encrypt certificate
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

The three checks target well-known HVAC energy problems:

1. Simultaneous heating and cooling. When both valves in an AHU are open, the unit is fighting itself. Causes range from a leaking valve to a poorly tuned control loop.
2. Economizer not used. If it is cool outside and the unit is still running mechanical cooling with the outdoor air damper near minimum, free cooling is being left on the table.
3. Low chilled water delta-T. A chilled water loop running well below its design temperature difference forces more pumping and often extra chillers online. It is one of the most common and costly plant inefficiencies.

Every threshold here is a starting point. Tune them per asset using design documents and a few weeks of observed data. The digital twin for energy article goes further into baselines and measuring savings.

Alerts and Visualisation

Because results are plain MQTT messages, any subscriber can consume them. In the ConnectMQ portal you can create threshold alert rules on numeric values, for example kw_per_ton or a supply air temperature, and review triggered alerts in the alerts log. The fault messages themselves are best routed by your own tooling: Node-RED can turn them into emails or tickets, and a Grafana dashboard backed by a time-series database can show trends.

For visualisation, a browser connects over Secure WebSocket on port 8084 (path /mqtt) and subscribes to the kpi and telemetry topics. A 2D floor plan with coloured AHUs is often more useful to facility teams than a photorealistic model. If you want to see what a live 3D twin looks like, ConnectMQ's digital twin web demo animates a factory with machines, tanks, pumps and conveyors updated over WSS, and the same pattern applies to a plant room.

Rollout Checklist

1. Inventory: export the BMS point list and pick the points in the table above for one AHU and one chiller.
2. Gateway: install a BACnet-to-MQTT gateway on the building network, read-only, publishing over TLS.
3. Topics: agree on the hierarchy and JSON field names before connecting the second asset.
4. Broker: create a private broker with credentials per gateway and per analytics service.
5. Validate: compare twin values against the BMS front end for a day; fix scaling and units.
6. Rules: enable the three checks, review findings weekly with the facility team, tune thresholds.
7. Scale: add the remaining AHUs, pumps and zones, then consider predictive use cases such as filter and bearing wear.

For the maintenance side, see digital twin predictive maintenance, and for the wider building picture, the building digital twin guide.

Security Considerations

Building networks are often old, flat and poorly segmented, so the gateway is a sensitive point. Place it in its own network segment, allow only outbound connections to the broker on port 8883, never expose BACnet to the internet, and give each gateway its own credentials. A hosted MQTT broker removes the need to open inbound ports on the building network entirely, because all connections are outbound from the site. Never publish real building data on a public test broker; use it only with synthetic values while prototyping.

Build Your HVAC Digital Twin on ConnectMQ

ConnectMQ is a cloud MQTT broker that carries the live data your HVAC twin depends on: MQTT 3.1.1 and 5.0, TLS, WebSockets for dashboards, ISA-95-aware device views and threshold alerts in the portal. Your gateways, analytics and dashboards connect as standard MQTT clients. Create a free Serverless broker at app.connectmq.com, no credit card required, and stream your first AHU today.

Frequently Asked Questions

What is an HVAC digital twin?

It is a live model of HVAC equipment such as air handling units and chillers, continuously updated with real sensor data and compared against expected behaviour to find faults and energy waste.

Do I need to replace my BMS to build an HVAC digital twin?

No. The twin reads data from the existing BMS through a BACnet-to-MQTT gateway and leaves control with the BMS. It adds analysis, not a new control system.

Why use MQTT instead of reading BACnet directly?

BACnet is designed for local building networks. MQTT carries data securely to the cloud over outbound connections and lets many consumers, such as analytics, dashboards and storage, share the same stream.

How quickly can an HVAC digital twin show results?

Simple rules like simultaneous heating and cooling or low chiller delta-T can surface issues within the first weeks of data, but savings depend on the building and on acting on the findings.