Case Study: Building a Smart HVAC Control System with IoT

The Problem: Legacy HVAC, Modern Expectations

The maintenance team had to physically walk to each unit to adjust temperatures, read error codes, or troubleshoot failures. Energy bills were climbing, and tenants were complaining about inconsistent temperatures between zones.

The client wanted remote monitoring and control. They wanted to see real-time data on a dashboard. They wanted alerts when a unit started drawing abnormal current or when a filter got clogged. And they wanted all of this without ripping out the existing HVAC infrastructure — that would have cost six figures and required weeks of downtime.

The Technical Challenge

Here's the thing about commercial HVAC systems: they don't speak modern IoT protocols natively. Most units communicate over RS485 using Modbus RTU — a serial protocol that's been around since 1979. It's reliable, but it's not exactly cloud-friendly.

So our approach was straightforward: build a bridge between the legacy RS485 bus and modern MQTT over Wi-Fi or Ethernet. We'd create a smart gateway that could poll the HVAC controllers, parse the Modbus registers, and translate everything into clean MQTT topics. Then we'd build a cloud dashboard that facility managers could access from their phones or laptops.

Hardware Selection: Why We Chose ESP32

We evaluated a few options for the gateway hardware. The Raspberry Pi was overkill — too much power draw, too fragile for a mechanical room environment. We looked at the nRF52 series, but the lack of built-in Wi-Fi meant adding an external radio, which complicated the BOM.

We settled on the ESP32-WROOM-32E for the main gateway. Here's why:

• Dual-core Xtensa LX6 processor running at 240 MHz — plenty of headroom for Modbus polling, MQTT stack, and OTA updates
• Built-in Wi-Fi and Bluetooth — no external radio needed
• Multiple UARTs — we needed two: one for the RS485 transceiver, one for debug logging
• Plenty of GPIO for status LEDs, a reset button, and a physical mode switch
• Price — under $5 in single-unit quantities, which matters when you're deploying 40+ gateways

For the RS485 side, we used the MAX3485 transceiver. It runs at 3.3V, which matches the ESP32's logic levels, and supports data rates up to 10 Mbps — though Modbus RTU typically runs at 9600 or 19200 baud, so we had plenty of headroom.

Firmware Architecture: Zephyr RTOS

We built the gateway firmware on Zephyr RTOS rather than bare-metal or Arduino. Zephyr gave us a proper threading model, which we needed because the gateway does several things simultaneously:

1. Poll Modbus registers from up to 10 HVAC units on a single RS485 bus (using a custom polling scheduler)

2. Publish telemetry to the MQTT broker every 5 seconds

3. Process commands from the cloud (setpoint changes, mode changes, fan speed)

4. Handle OTA firmware updates without bricking the device

5. Log locally to a small flash partition for debugging

The Modbus master implementation was the trickiest part. We used the `libmodbus` library ported to Zephyr, but we had to write a custom RTU driver because Zephyr's UART API handles interrupts differently than Linux. Our firmware engineer spent about two weeks on this alone, but the result was rock-solid — we achieved a 99.98% successful poll rate across all units over a 30-day test period.

PCB Design: Keeping It Compact and Reliable

We designed a custom PCB for the gateway rather than using off-the-shelf dev boards. The final board measured 80mm x 50mm — small enough to fit inside a standard DIN-rail enclosure.

Key design decisions:

• Isolated RS485 — we used a digital isolator (ISO7721) between the ESP32 and the MAX3485. This prevents ground loops, which are common in commercial buildings where HVAC units might be on different electrical phases.
• TVS protection on the RS485 lines — surge protection is non-negotiable when you're wiring into a bus that runs through mechanical rooms with high-voltage equipment nearby.
• Wide input voltage range — the gateway accepts 9-24V DC, so it can be powered from the HVAC unit's own transformer or a separate PSU.
• Board-to-board connector for the ESP32 module — this lets us swap the radio module if needed without replacing the whole board.

We routed the board in KiCad. Two layers was sufficient — the design wasn't that dense, and keeping it two-layer reduced manufacturing cost significantly. At 100-unit volume, we got the boards fabricated and assembled for about $12 each including components.

The RS485 Bus: Real-World Considerations

Here's something that bit us during initial testing: RS485 termination. The client's existing bus had no termination resistors, which caused signal reflections at 19200 baud — we were getting intermittent CRC errors on about 3% of polls.

The fix wasn't just adding a 120-ohm termination resistor at each end of the bus. We also had to check the bias resistors. Many commercial HVAC controllers use a two-wire RS485 setup without proper biasing, which can cause undefined states when the bus is idle. We added 560-ohm bias resistors to pull the lines to known states.

After those changes, our error rate dropped to essentially zero.

MQTT and Cloud Architecture

We chose MQTT for the IoT layer because it's lightweight, supports persistent sessions, and handles reconnection gracefully — critical when a gateway might lose Wi-Fi connectivity for a few minutes during network maintenance.

The topic structure we used:

```

facility/{building_id}/gateway/{gateway_id}/telemetry

facility/{building_id}/gateway/{gateway_id}/status

facility/{building_id}/unit/{unit_id}/command

```

Telemetry messages were JSON payloads containing:

• Temperature readings from up to 4 sensors per unit
• Current draw (from the HVAC unit's VFD or contactor)
• Fan status
• Error codes
• Setpoint values
• Timestamp

We used a Mosquitto broker on a small VPS, with TLS encryption and username/password authentication. For the dashboard, we built a simple Node-RED flow that subscribes to the telemetry topics and pushes data to InfluxDB. Grafana handled the visualization.

The whole cloud stack costs about $30/month to run — a fraction of what commercial building management software would cost.

What We Learned

Power cycling matters. We tested the gateway's behavior during brownouts and power flickers — common in industrial settings. The ESP32's RTC memory and Zephyr's settings subsystem let us persist the last known state, so the gateway comes back online and resumes polling without manual intervention.

Firmware updates in the field are essential. We built an OTA update mechanism using MQTT as the transport. The gateway subscribes to an update topic, downloads the new firmware image to an external SPI flash chip, verifies the checksum, and then swaps partitions. We've pushed 6 firmware updates since deployment, and the client never had to touch a single device.

Documentation saves support calls. We wrote a detailed deployment guide covering wiring diagrams, IP addressing, and troubleshooting procedures. It's saved us at least a dozen support tickets.

The Results

The client deployed 42 gateways across their facility. Here's what changed:

• Energy consumption dropped 18% in the first quarter — they could finally see which units were running inefficiently and adjust schedules
• Maintenance response time went from hours to minutes — alerts fire immediately when a unit reports an error code
• Tenant complaints dropped significantly — consistent temperatures across zones
• The entire system cost about $15, 000 including hardware, firmware development, and the cloud dashboard — versus the $100, 000+ quote they got for a commercial building management system

The client is now planning to expand the system to their other two facilities.

Want to Build Something Similar?

If you're looking at a legacy smart hvac control system and wondering how to bring it into the IoT era, we've been there. We've done the RS485 debugging, the Modbus register hunting, the MQTT broker setup — and we can help you skip the painful parts.

Whether you need a complete turnkey solution or just a custom PCB design and firmware for your own gateway, get in touch. We ship fully assembled prototypes anywhere in the world, and we're happy to walk through your specific requirements.

DigitalMonk — hardware and embedded systems development, from schematic to shipped prototype. Based in India, serving clients in the US and UK.