Cómo llevar los datos de un BMS BACnet a la nube sin abrir puertos
La pregunta aparece siempre en la primera reunión con el departamento de sistemas del cliente: ¿esto me obliga a abrir algo hacia fuera? La respuesta correcta es no, y conviene saber explicar por qué.
Por qué BACnet no puede salir del edificio
BACnet/IP y Modbus TCP son protocolos de campo. Nacieron para una red local de confianza y no llevan autenticación ni cifrado: quien alcanza el puerto puede leer y, en muchos casos, escribir en los puntos del sistema de control. Publicar el 47808 o el 502 hacia internet es exponer las máquinas del edificio, y ningún responsable de sistemas debería aceptarlo.
La consecuencia de diseño es clara: el protocolo del edificio no cruza internet nunca. Solo viaja por la red local, hasta un programa que está dentro de esa misma red.
El patrón: conexión saliente iniciada desde dentro
El esquema que funciona, y el único que suele aprobar un departamento de sistemas, es este:
- Un programa pequeño (llamémosle conector) se instala en un equipo de la red del edificio: una máquina virtual, un mini PC industrial o el propio servidor del BMS.
- Ese conector habla BACnet o Modbus solo hacia dentro, con el BMS.
- Hacia fuera abre él la conexión, saliente, cifrada con TLS y por el puerto 443, el mismo que usa cualquier navegador. Atraviesa los proxies corporativos como una web más.
- Por esa conexión suben las medidas y bajan las órdenes. En el cortafuegos no se abre nada entrante.
El detalle importante es que la conexión sea bidireccional, normalmente un WebSocket. Así la plataforma puede pedir algo sin necesidad de llamar al edificio: la petición viaja por el canal que el conector ya abrió.
Qué preguntará el departamento de sistemas
| Pregunta | Respuesta que debe poder darse |
|---|---|
| ¿Abro puertos entrantes? | No. Solo salida por 443. |
| ¿Qué máquina hace falta? | Un equipo modesto con acceso a la red del BMS. El mismo programa sirve en Windows y en Linux. |
| ¿Qué credenciales lleva? | Un token propio del edificio, revocable desde la plataforma sin tocar el equipo. |
| ¿Puede escribir en el BMS? | Por defecto no. Si se habilita, con nivel de prioridad pactado, caducidad automática y verificación de que el punto volvió a su valor anterior. |
| ¿Qué pasa si se cae la conexión? | El conector guarda las medidas y las reenvía al volver; si hubiera algo escrito, lo libera por su cuenta. |
El mapeo: la parte que de verdad cuesta
Conectar es lo fácil. Lo laborioso es decidir qué puntos se leen y qué significa cada uno. Un BMS
mediano expone miles de objetos con nombres como AI_1024 o UI 1-00.RoomTemp.
El descubrimiento automático (un Who-Is por BACnet y la lectura de la lista de objetos) resuelve el inventario bruto. A partir de ahí hay dos decisiones humanas que ninguna herramienta puede tomar sola: a qué máquina y sala pertenece cada punto, y para qué sirve cada uno, es decir si es temperatura de sala, consigna, marcha, alarma o potencia. Esa segunda clasificación es la que permite luego razonar y comparar entre edificios distintos, y merece la pena hacerla bien una vez.
Cuando no se puede instalar nada
Hay edificios donde no hay equipo disponible, o donde el cliente prefiere no instalar software. Existen dos caminos sin conector:
- La nube del fabricante. Muchos fabricantes de clima ofrecen un servicio en internet con sus unidades. Se lee desde ahí, con las credenciales del titular. A cambio, la resolución suele ser menor y el catálogo de puntos, más pobre.
- La API del propio BMS. Las plataformas modernas exponen un servicio web. No hay un estándar común, así que cada fabricante requiere su propio adaptador, pero cuando existe es la vía más limpia.
En ambos casos se pierde el control fino y se gana simplicidad. Para un edificio pequeño puede ser suficiente; para un BMS serio, el conector local sigue siendo mejor.
Lo que hay que exigir a cualquier solución
- Que el edificio no tenga puertos entrantes abiertos.
- Que el protocolo de campo no salga de la red local.
- Que toda escritura caduque sola, sin depender de que la nube siga viva.
- Que exista registro de cada comando: qué se escribió, cuándo y cuándo se liberó.
- Que el mapeo de puntos sea configuración editable, no código de un integrador.