HVAC monitoring in data centers: a reference architecture for Colombia

In a Colombian data center, an undetected HVAC failure within 10 minutes can take whole servers down and trip SLAs. The usual coverage —an expensive proprietary BMS or an operator staring at green lights— scales poorly and produces no audit evidence.

This is the HVAC monitoring architecture we deploy on Colombian critical infrastructure: non-invasive, vendor-neutral and 24/7 operational from day one.

TL;DR — the architecture in one mental image

[HVAC #1..N]   →   [Edge gateway]   →   [MQTT broker]   →   [Time-series DB]   →   [Dashboard + alerts]
 Modbus/BACnet     normalizes           AWS IoT / EMQX     InfluxDB             Grafana → email/WhatsApp/PagerDuty
                   local buffer

Five layers, each replaceable without touching the others. No lock-in to the HVAC vendor or the cloud.

1. Connect to HVAC without touching it

Rule #1 in critical infrastructure: you don’t touch working equipment. Integration must be passive.

Typical industrial HVAC in Colombian data centers (Liebert/Vertiv, Stulz, APC, Daikin, Schneider) expose variables via:

• Modbus RTU (RS-485) or Modbus TCP — most common on 5+ year-old equipment.
• BACnet IP — modern equipment or integrated into building BMS.
• SNMP — some niche devices.
• Proprietary protocol — Liebert with SiteScan, Stulz with C7000. Require vendor API/SDK.

Validate before committing architecture: open the HVAC manual and confirm what it exposes. Minimum variables we need: return temp, supply temp, on/off state, electrical consumption, active alarms, mode (cooling/heating/fan).

If the equipment exposes nothing useful via standard protocol, budget for an additional vendor communication module (USD 400–1,500 depending on brand) or non-invasive external sensors as backup.

This integration pattern is exactly what we cover in the IoT development service and apply in the HVAC monitoring solution.

2. Edge gateway: the resilience layer

An industrial gateway (Moxa UC, Advantech UNO, industrial Raspberry Pi) does four things:

1. Polls the HVAC via Modbus/BACnet every N seconds.
2. Normalizes units and names (each vendor names its variables differently).
3. Buffers locally when upstream fails — data is not lost.
4. Publishes to the MQTT broker with hierarchical topics (dc1/room-a/hvac-3/supply-temp).

Critical point: one gateway per room (or per logical grouping), not a single one for the whole data center. If a gateway fails, only its zone loses visibility. Gateways monitor each other — if one stops publishing, the others raise an alert.

3. MQTT broker and time-series

The broker is the heart of the system. Real options:

• AWS IoT Core — managed, auto-scaling, integrates with the whole AWS ecosystem. Predictable cost.
• EMQX or Mosquitto self-hosted — full control, low cost, requires managing HA.
• Azure IoT Hub / GCP IoT — equivalents per your cloud of choice.

For data centers in Colombia where policy dictates on-premise, EMQX in HA is the bet. For cloud-first clients, AWS IoT Core wins by operational simplicity.

Time-series: InfluxDB (open source or cloud) or TimescaleDB (PostgreSQL extension). For data centers we prefer InfluxDB for bucket retention and efficient compression. With 50 HVAC units sending 10 variables every 30s, that’s ~1.4 GB/year per device — manageable in any deployment.

4. Dashboards and alerts: what the operator actually uses

Grafana is the de-facto standard. What matters is not the tool, it’s the design:

• Room view: average temp, hot spots, devices in alarm, active redundancy.
• Per-HVAC view: 24h history, consumption, cycles, comparison vs setpoint.
• Executive view: monthly SLA, incident MTTR, monthly consumption trend.

Alerts are where projects fail. Minimum rules for a data center:

1. Return temp > threshold for N minutes → immediate alert.
2. HVAC in proprietary alarm → immediate alert with vendor code.
3. Redundancy loss (N+1 down to N) → critical alert.
4. Anomalous trend (consumption climbing without reason) → non-urgent alert, daytime ticket.
5. Gateway silent for 5 minutes → alert to IT, not DC operator.

Every alert needs owner, channel and expected action. An alert without an assigned owner is noise — people will mute it in a month.

This layer is exactly what the real-time monitoring service covers.

5. Alert escalation: not every alert wakes the IT lead

Standard 3-level model:

Level	Channel	Who	Reaction time
1 — Info	Slack/Teams	DC team	Next round
2 — Action	Email + Slack	On-call operator	< 15 min
3 — Critical	SMS + WhatsApp + PagerDuty	On-call + supervisor	< 5 min, 24/7

PagerDuty handles escalation: if the on-call operator doesn’t ack in 10 min, it escalates to the supervisor; if neither, to the head of operations. Without that, a critical 3 AM alert may go unanswered.

Decisions we make on real projects

Decision	Recommended default	When to change
Cloud or on-premise?	Cloud (AWS/Azure)	Security policy forbids it
1 gateway per room or per device?	Per room	Equipment with isolated proprietary protocol
Polling interval?	30 seconds	Critical variables: 5–10 s
Data retention?	1 year hot, 3 years cold	Regulatory requirements
Existing BMS?	Coexist, don’t replace	The BMS is being retired

This is the kind of architecture we apply in the data center & critical infrastructure sector, where the HVAC solution crosses with unified monitoring.

Typical mistakes on HVAC projects

1. Designing for day 1 without thinking about day 100. What works with 3 HVAC units collapses at 30 if MQTT topics aren’t well designed.
2. Alerts without owner. They end up muted in a Slack channel nobody reads.
3. Forgetting the human dimension. The DC operator needs a different view than the IT lead. A single dashboard for all doesn’t work.
4. Not testing escalation. Critical alerts are tested at 3 AM on a Saturday, not at the Monday demo.
5. Skipping the equipment inventory. A single undocumented HVAC found in production can wreck the schedule.

Minimum checklist before quoting

• Full HVAC inventory with brand, model, year, supported protocol.
• Hosting policy defined (cloud / on-premise / hybrid).
• Critical variables identified per device.
• Alert matrix defined: level, channel, owner, response time.
• Data retention horizon agreed.
• Existing BMS: coexist or replace?

---

Running a data center or technical room without continuous HVAC visibility? At COL0 we deploy this architecture in Colombian critical infrastructure. Tell us your case or chat via WhatsApp — in one call we’ll tell you whether your environment supports the implementation above or needs adjustments.