Monitoreo HVAC en data centers: arquitectura de referencia para Colombia

En un data center colombiano, una falla de HVAC no detectada en 10 minutos puede sacar de operación servidores enteros y disparar SLAs. La forma usual de cubrir esto —un BMS propietario costoso o un operador mirando luces verdes en una sala— escala mal y no produce evidencia para auditoría.

Esta es la arquitectura de monitoreo HVAC que desplegamos en infraestructura crítica colombiana: no invasiva, vendor-neutral y operativa 24/7 desde el primer día.

TL;DR — la arquitectura en una imagen mental

[HVAC #1..N]   →   [Gateway edge]   →   [Broker MQTT]   →   [Time-series DB]   →   [Dashboard + alertas]
 Modbus/BACnet     normaliza             AWS IoT / EMQX     InfluxDB             Grafana → email/WhatsApp/PagerDuty
                   buffer local

Cinco capas, cada una reemplazable sin tocar las otras. Sin lock-in con el vendor del HVAC ni con la nube.

1. Conectarse al HVAC sin tocarlo

La regla #1 en infraestructura crítica: no se toca el equipo que funciona. La integración debe ser pasiva.

Los HVAC industriales típicos en data centers colombianos (Liebert/Vertiv, Stulz, APC, Daikin, Schneider) exponen variables vía:

• Modbus RTU (RS-485) o Modbus TCP — el caso más común en equipos de 5+ años.
• BACnet IP — equipos modernos o integrados a BMS de edificio.
• SNMP — algunos equipos de nicho.
• Protocolo propietario — Liebert con SiteScan, Stulz con C7000. Requieren la API/SDK del fabricante.

Validar antes de comprometer arquitectura: abrir el manual del HVAC y confirmar qué expone. Variables mínimas que necesitamos: temperatura de retorno, temperatura de impulsión, estado on/off, consumo eléctrico, alarmas activas, modo (cooling/heating/fan).

Si el equipo no expone nada útil por protocolo estándar, presupueste un módulo de comunicación adicional del fabricante (USD 400–1.500 según marca) o sensores externos no invasivos como respaldo.

Este patrón de integración es exactamente lo que cubrimos en el servicio de desarrollo IoT y aplicamos en la solución de monitoreo HVAC.

2. Gateway edge: el corazón de la resiliencia

Un gateway industrial (Moxa UC, Advantech UNO, Raspberry Pi industrial) hace cuatro cosas:

1. Poll a los HVAC vía Modbus/BACnet cada N segundos.
2. Normaliza unidades y nombres (cada vendor mete sus variables con nombres distintos).
3. Bufferiza localmente cuando el upstream falla — los datos no se pierden.
4. Publica al broker MQTT con tópicos jerárquicos (dc1/sala-a/hvac-3/temp-impulsion).

Punto crítico: un gateway por sala (o por agrupación lógica), no uno solo para todo el data center. Si un gateway falla, solo se pierde visibilidad de su zona. Y los gateways se monitorean entre sí — si uno deja de publicar, los demás emiten alerta.

3. Broker MQTT y time-series

El broker es el corazón del sistema. Opciones reales:

• AWS IoT Core — gestionado, escala solo, integra con todo el ecosistema AWS. Costo previsible.
• EMQX o Mosquitto self-hosted — control total, costo bajo, requiere gestionar HA.
• Azure IoT Hub / GCP IoT — equivalentes al de AWS según su nube preferida.

Para data centers en Colombia donde la política dicta on-premise, EMQX en HA es la apuesta. Para clientes en cloud-first, AWS IoT Core gana por simplicidad operativa.

Time-series: InfluxDB (open source o cloud) o TimescaleDB (PostgreSQL extension). Para data centers preferimos InfluxDB por las retenciones por bucket y compresión eficiente. Con 50 HVAC enviando 10 variables cada 30s, son ~1.4 GB/año por equipo — manejable en cualquier deployment.

4. Dashboards y alertas: lo que el operador realmente usa

Grafana es el estándar de facto. Lo que importa no es la herramienta, es el diseño:

• Vista de sala: temperatura promedio, hot-spots, equipos en alarma, redundancia activa.
• Vista por HVAC: histórico 24h, consumo, ciclos, comparación contra setpoint.
• Vista ejecutiva: SLA del mes, MTTR de incidentes, tendencia mensual de consumo.

Las alertas son donde fallan los proyectos. Reglas mínimas para data center:

1. Temperatura de retorno > umbral durante N minutos → alerta inmediata.
2. HVAC en alarma propietaria → alerta inmediata con código del fabricante.
3. Caída de redundancia (si tiene N+1, perdió el +1) → alerta crítica.
4. Tendencia anómala (consumo subiendo sin razón) → alerta no urgente, ticket diurno.
5. Gateway sin publicar 5 minutos → alerta a equipo de IT, no al operador del DC.

Cada alerta debe tener dueño, canal y acción esperada. Una alerta sin dueño asignado es ruido — al mes la gente la silencia.

Esta capa es exactamente lo que cubre el servicio de monitoreo en tiempo real.

5. Escalado de alertas: no toda alerta despierta al jefe de IT

Modelo estándar 3-niveles:

Nivel	Canal	Quién	Tiempo de reacción
1 — Información	Slack/Teams	Equipo DC	Próxima ronda
2 — Acción	Email + Slack	Operador on-call	< 15 min
3 — Crítica	SMS + WhatsApp + PagerDuty	On-call + supervisor	< 5 min, 24/7

PagerDuty maneja el escalado: si el operador de turno no acknowledge en 10 min, escala al supervisor; si éste tampoco, al jefe de operaciones. Sin eso, una alerta crítica enviada a las 3 am puede no recibir respuesta.

Decisiones que tomamos en proyectos reales

Decisión	Default recomendado	Cuándo cambiar
¿Cloud o on-premise?	Cloud (AWS/Azure)	Política de seguridad lo prohíbe
¿1 gateway por sala o por equipo?	Por sala	Equipos con protocolo propietario aislado
¿Polling cada cuánto?	30 segundos	Variables críticas: 5–10 s
¿Retención de datos?	1 año en caliente, 3 años frío	Requisitos regulatorios
¿BMS existente?	Coexistir, no reemplazar	El BMS está siendo retirado

Este es el tipo de arquitectura que aplicamos en el sector de data centers e infraestructura crítica, y donde la solución HVAC se cruza con monitoreo unificado.

Errores típicos en proyectos HVAC

1. Diseñar para el día 1 sin pensar en el 100. Lo que funciona con 3 HVAC colapsa con 30 si los tópicos MQTT no están bien diseñados.
2. Alertas sin dueño. Termina silenciado en un canal de Slack que nadie lee.
3. Olvidar la dimensión humana. El operador del DC necesita una vista distinta del jefe de TI. Un solo dashboard para todos no sirve.
4. No probar el escalado. Las alertas críticas se prueban a las 3 am de un sábado, no en el demo del lunes.
5. Saltarse el inventario de equipos. Un solo HVAC no documentado descubierto en producción puede romper el cronograma.

Checklist mínimo antes de cotizar

• Inventario completo de HVAC con marca, modelo, año, protocolo soportado.
• Definida la política de hosting (cloud / on-premise / híbrido).
• Identificadas las variables críticas a monitorear por equipo.
• Definida la matriz de alertas: nivel, canal, dueño, tiempo de respuesta.
• Acordado el horizonte de retención de datos.
• BMS existente: ¿coexistimos o reemplazamos?

---

¿Operando un data center o sala técnica sin visibilidad continua del HVAC? En COL0 desplegamos esta arquitectura en infraestructura crítica colombiana. Cuéntenos su caso o conversemos por WhatsApp — en una llamada le decimos si su entorno permite la implementación que describimos arriba o requiere ajustes.