AI HVAC Optimization: Smarter Setpoints and Schedules with MQTT Data

AI HVAC optimization uses data from a building's heating, ventilation and air conditioning system to learn how each zone actually behaves, then chooses start times, setpoints and schedules that keep occupants comfortable with less energy. In this use case you will see which data to collect over MQTT, how to learn a zone's thermal response from that data, how to compute an optimal start time, and how to send recommendations back to the building safely.

Where Conventional HVAC Control Leaves Energy on the Table

Most building automation systems run on fixed schedules and fixed setpoints configured at commissioning. The air handler starts at 06:00 every weekday because someone once decided that was early enough, regardless of whether the night was mild or cold. Setpoints stay at the same value through a half-empty Friday afternoon. Simultaneous heating and cooling in neighbouring zones goes unnoticed for months.

None of this is a failure of the controllers, which do their job of holding a setpoint well. The gap is at the supervisory level: deciding what the setpoints and schedules should be, given the weather, the occupancy and the building's thermal behaviour. That is where data-driven models help, and it is why AI HVAC optimization usually sits above the existing building automation system rather than replacing it.

Data to Collect for AI HVAC Optimization

Building automation systems usually speak BACnet or Modbus. A gateway reads the relevant points and publishes them to an MQTT broker under a consistent hierarchy, so the optimization service never has to know vendor point names:

connectmq/hq/floor3/zone-east/temperature     {"ts":..., "value": 23.8, "unit":"degC"}
connectmq/hq/floor3/zone-east/setpoint        {"ts":..., "value": 22.0, "unit":"degC"}
connectmq/hq/floor3/ahu2/supply_temp          {"ts":..., "value": 14.2, "unit":"degC"}
connectmq/hq/weather/outdoor_temp             {"ts":..., "value": 31.5, "unit":"degC"}
connectmq/hq/floor3/zone-east/recommendation  {"ts":..., "start_at":"06:40", "reason":"..."}

If you are choosing between building protocols at the gateway, BACnet vs Modbus compares them.

Three Optimization Opportunities

1. Optimal start and stop. Start conditioning each zone just early enough to reach the comfort band when occupancy begins, and stop early when the building's thermal mass will hold the temperature until people leave.
2. Setpoint optimization. Relax setpoints within the comfort band when zones are unoccupied or lightly occupied, and pre-cool or pre-heat during low-demand or low-price hours.
3. Fault and waste detection. Find zones that heat and cool simultaneously, valves that never close, or sensors that drift. These are often the fastest savings.

Optimal start is the best first project: it is easy to explain, its savings are measurable, and its failure mode (a zone that is slightly warm at opening) is mild.

Learning a Zone's Thermal Response

Many buildings behave reasonably like a first-order thermal system over short horizons. The change in zone temperature per time step depends on the difference to outdoor temperature (heat gain through the envelope) and on the HVAC cooling or heating delivered:

T[k+1] - T[k] = a * (T_out[k] - T[k]) + b * u[k] + c

Here u is the HVAC output (for example cooling on or off, or valve position), and c captures average internal and solar gains. Fitting a, b and c per zone with linear regression on a few weeks of data gives a gray-box model: simple enough to trust, and data-driven enough to reflect each zone's real behaviour. More advanced projects use gradient boosting or neural models with occupancy and solar features, but the gray-box model is a strong, explainable starting point.

Example: Optimal Start from MQTT Data

The script below fits the thermal model for one zone, then searches for the latest cooling start time that still brings the zone into the comfort band by occupancy. It uses simulated history so it runs anywhere, and publishes the recommendation to the public MQTT test broker. In a real deployment, the history would come from your historian subscriber and the weather forecast from a weather service.

import json
import random
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt
from sklearn.linear_model import LinearRegression

STEP_MIN = 5
COMFORT_MAX = 24.0
OCCUPANCY_START = "08:00"

# --- 1. Simulated history (replace with historian data) --------------------
rng = np.random.default_rng(1)
true_a, true_b, true_c = 0.004, -0.06, 0.004
T, rows = 25.0, []
for k in range(14 * 24 * 12):  # two weeks at 5-minute steps
    hour = (k * STEP_MIN / 60) % 24
    t_out = 24 + 7 * np.sin((hour - 9) / 24 * 2 * np.pi)
    u = 1.0 if 7 <= hour < 18 else 0.0
    T_next = T + true_a * (t_out - T) + true_b * u + true_c + rng.normal(0, 0.03)
    rows.append((T, t_out, u, T_next - T))
    T = T_next

data = np.array(rows)
X = np.column_stack([data[:, 1] - data[:, 0], data[:, 2]])
model = LinearRegression().fit(X, data[:, 3])
a, b = model.coef_
c = model.intercept_
print(f"learned a={a:.4f} b={b:.4f} c={c:.4f}")

# --- 2. Optimal start search ----------------------------------------------
def simulate(start_index, T0, t_out_forecast, occ_index):
    T = T0
    for k in range(occ_index):
        u = 1.0 if k >= start_index else 0.0
        T = T + a * (t_out_forecast[k] - T) + b * u + c
    return T

T_now = 25.2                                     # zone temperature at 05:00
steps_until_occ = (8 - 5) * 60 // STEP_MIN       # 05:00 -> 08:00
t_out_fc = [22 + 0.08 * k for k in range(steps_until_occ)]  # warming morning forecast

best = 0
for start in range(steps_until_occ, -1, -1):     # latest start first
    if simulate(start, T_now, t_out_fc, steps_until_occ) <= COMFORT_MAX - 0.3:  # small safety margin
        best = start
        break
start_minutes = 5 * 60 + best * STEP_MIN
start_at = f"{start_minutes // 60:02d}:{start_minutes % 60:02d}"
print("recommended cooling start:", start_at)

# --- 3. Publish the recommendation ----------------------------------------
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/hq/floor3/zone-east"
rec = {
    "ts": int(time.time() * 1000),
    "start_at": start_at,
    "occupancy_start": OCCUPANCY_START,
    "comfort_max": COMFORT_MAX,
    "model": {"a": round(a, 5), "b": round(b, 5), "c": round(c, 5)},
    "reason": "latest start meeting comfort band with forecast outdoor temperature",
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="hvac-opt-" + uuid.uuid4().hex[:8])
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
client.publish(f"{BASE}/recommendation", json.dumps(rec), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print("published to", f"{BASE}/recommendation")

Install with pip install paho-mqtt numpy scikit-learn. The fitted coefficients come out close to the simulated values, and the recommendation is noticeably later than a fixed early start would be. In a real building, compare the recommended time with the fixed schedule for several weeks before letting it act; the difference in AHU runtime is your expected saving.

Applying Recommendations Safely

Sending setpoints to real equipment needs more care than publishing a chart. A practical progression:

1. Advisory mode. Publish recommendations only; facility staff review them on a dashboard alongside actual outcomes.
2. Bounded automation. A gateway or BMS integration accepts recommendations only within hard limits, such as start no earlier than 05:00, setpoints only between 21 and 25 degC, and ignores messages older than a few minutes. MQTT 5 message expiry is useful here, so stale commands are discarded by the broker.
3. Fallback. If recommendations stop arriving, the BMS returns to its normal schedule automatically.
4. Human override. Local overrides always win, and every override is recorded as an event so the model can learn from it.

These limits belong in the equipment-side integration, not only in the AI service, so that a bug in the model cannot push equipment outside safe ranges. The safe AI control of IoT devices article covers these guardrails in depth.

Measuring Results

Savings claims are easy to make and hard to prove. Compare like with like: weekdays with similar outdoor temperature and occupancy, before and after, or alternate days between the old and the new schedule. Track comfort as carefully as energy, using minutes outside the comfort band per zone. Publish both as topics so they appear next to the operational data. An energy load forecasting model helps here as a baseline: the gap between forecast demand under the old strategy and measured demand under the new one is a fair estimate of the effect.

Running the Data Layer on ConnectMQ

ConnectMQ provides the managed MQTT broker that carries BMS points, weather data, recommendations and results between your gateway and your optimization service. The live topic explorer shows recommendations next to the zone temperatures they affect, and threshold alert rules can flag zones that leave the comfort band. The models themselves run in your own clients, for example a Python service or a Node-RED flow. For the bigger picture of AI with connected devices, see the AI and IoT guide, and for forecasting techniques you can reuse, IoT time series forecasting.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Connect your BMS gateway with the generated YOUR_USERNAME, YOUR_PASSWORD and YOUR_CLIENT_ID, collect a few weeks of zone data, and run the optimal start example on your own building. When you add more buildings, a cloud MQTT broker plan scales the connection count without changing your topics.

Frequently Asked Questions

What is AI HVAC optimization?

AI HVAC optimization uses building data and models to choose better HVAC start times, setpoints and schedules than fixed configurations, reducing energy use while keeping zones within the comfort band.

Does AI HVAC optimization replace the building management system?

No. It usually acts as a supervisory layer that recommends or sends setpoints and schedules, while the existing BMS controllers continue to run the equipment and enforce local safety.

How much data is needed to start?

A few weeks of zone temperature, HVAC status and outdoor temperature at 5–15 minute intervals is enough to fit a simple thermal model for optimal start. Seasonal effects need longer history.

How do I keep automated setpoint changes safe?

Enforce hard limits and message age checks at the equipment-side integration, fall back to the normal schedule when recommendations stop, and let local overrides always take precedence.