Cómo habla OpenWebNet Captia Connect
Connect se comporta como cliente de una pasarela, nunca como dispositivo del bus. Esa distinción es la primera que hay que fijar, porque condiciona todo lo demás. El bus físico de la instalación es un par trenzado de dos hilos sin polaridad, alimentado a unos 27 V continuos por el alimentador de la línea, con topología libre en estrella, en árbol o en cadena. Connect no se conecta ahí. Se conecta por Ethernet a la pasarela que ya traduce ese bus a TCP, abre una sesión y lee. En el bus no aparece un participante nuevo, y por tanto no cambia ni el direccionamiento ni el reparto de tráfico que la instalación tenía antes de que llegara nadie.
Sesión: puerto, apertura y los dos modos que existen
La sesión se abre contra el puerto TCP de la pasarela, que por defecto en la práctica totalidad del parque instalado es el 20000. Lo primero que llega no es un dato sino un acuse: la pasarela emite *#*1## y se queda esperando a que el cliente declare para qué ha entrado. Y aquí está la decisión de diseño que más determina el comportamiento de la integración, porque OpenWebNet no permite hacer las dos cosas por el mismo socket:
*99*0##abre una sesión de comando. Sirve para preguntar estados y dimensiones, y la pasarela contesta a cada pregunta. Es una conversación de ida y vuelta.*99*1##abre una sesión de monitorización. La pasarela deja de contestar y pasa a empujar: cada trama que circula por el bus se replica hacia el cliente sin que este pida nada.
Connect mantiene las dos sesiones abiertas en paralelo contra la misma pasarela, y esa es la configuración que hace que la integración funcione. La sesión de monitorización es la que captura la vida real de la instalación, incluido lo que hace una persona pulsando un interruptor de pared, que jamás aparecería si solo se preguntara. La sesión de comando se reserva para dos cosas concretas: el barrido de estado inicial y las lecturas periódicas de las magnitudes que el bus no anuncia por su cuenta.
Entre medias está la autenticación. Según el firmware de la pasarela, esta responde a la declaración de sesión con un nonce numérico entre asteriscos, y el cliente devuelve la contraseña OPEN transformada con el algoritmo clásico, o bien negocia un HMAC con*98*1## o *98*2## en los equipos que lo soportan. Conviene saber dos cosas de campo: la contraseña de fábrica suele seguir puesta y suele ser numérica de cinco cifras, y muchas pasarelas llevan además una lista de rangos IP autorizados que hay que ampliar para incluir al nodo Connect, porque si no la conexión se rechaza sin mensaje útil y se pierde media tarde buscándolo en el sitio equivocado.
Estructura de la trama: WHO, WHAT, WHERE y DIMENSION
OpenWebNet no tiene mapa de registros ni espacio de direcciones navegable. Tiene una gramática de texto plano delimitada por asteriscos y cerrada con almohadilla doble, y toda la integración consiste en saber leerla. Connect trabaja con cuatro formas de trama:
*WHO*WHAT*WHERE##, la trama de acción o de cambio de estado. Cuando Connect la recibe por la sesión de monitorización, significa que algo ha ocurrido.*#WHO*WHERE##, la petición de estado, con la que Connect construye la fotografía inicial.*#WHO*WHERE*DIMENSION##, la petición de una magnitud concreta. Es la forma que devuelve números: potencia, energía acumulada, temperatura medida, consigna.*#WHO*WHERE*DIMENSION*VAL##, la respuesta con el valor. Los acuses son*#*1##para aceptado y*#*0##para rechazado, y un rechazo aquí casi siempre significa que el WHERE no existe en esa instalación, no que la trama esté mal escrita.
El WHO es la familia funcional y es el criterio con el que Connect decide qué le interesa de cada instalación. El WHERE es la dirección física, y aquí está la particularidad que sorprende a quien viene de un protocolo de planta: no es un número plano, es una notación de ambiente y punto. Un 12 no es el elemento doce, es el punto luz 2 del ambiente 1. Existe además el ambiente general, los grupos con# y la extensión de bus local #4#N para lo que cuelga detrás de una interfaz de expansión, que es exactamente donde suelen estar los cuadros secundarios de un edificio grande.
| WHO | Qué cubre | Qué le pide Connect | Qué acaba siendo en el histórico |
|---|---|---|---|
| 1 Iluminación | Puntos de luz, reguladores y circuitos de alumbrado por ambiente | Estado por evento en la sesión de monitorización, más barrido inicial con peticiones de estado | Serie de estado con marca de encendido y apagado, base para horas de funcionamiento y perfil de uso |
| 2 Automatismos | Persianas, cortinas y motorizaciones de fachada | Eventos de subida, bajada y parada | Serie de estado que explica saltos de carga térmica cuando se cruza con el clima |
| 4 Termorregulación | Zonas de clima, sondas de temperatura y consignas | Temperatura medida y consigna por zona, con lectura periódica de dimensión | Series numéricas de temperatura y consigna en grados Celsius, con la zona como contexto |
| 18 Gestión de energía | Medidores de línea y actuadores de gestión de carga | Potencia activa instantánea y totalizadores acumulados por medidor | Serie de potencia en vatios y contador acumulado de energía por circuito |
| 25 Contactos secos y entradas | Contactos libres de tensión y entradas auxiliares del sistema | Eventos de cierre y apertura | Serie binaria utilizable como presencia, ocupación o señal de estado de un equipo externo |
Cadencia: monitorizar por evento, preguntar poco y con criterio
La regla operativa que ordena toda la implantación es esta: lo que el bus anuncia no se pregunta, y lo que hay que preguntar se pregunta despacio. El bus SCS no es determinista ni ancho. Es un medio compartido con arbitraje por contienda y con un caudal de tramas por segundo que se cuenta con los dedos de dos manos. Un cliente que sondea toda la instalación cada segundo no obtiene mejor dato: obtiene un bus saturado y, sobre todo, obtiene que el usuario del edificio note retardo entre pulsar un interruptor y ver la luz. Ese es el modo de fallo real y es de los que generan una llamada de mantenimiento el mismo día.
Por eso Connect reparte el trabajo. Los estados discretos de iluminación, automatismos y contactos llegan por evento y no cuestan nada, porque la trama ya circula por el bus la haya pedido alguien o no. Las magnitudes analógicas, temperatura y potencia, sí exigen preguntar, y ahí Connect trabaja con periodos del orden de minutos y no de segundos, escalonando las peticiones entre zonas y medidores en lugar de lanzarlas en bloque. En las pasarelas que lo soportan, la vía preferente ni siquiera es preguntar: es pedir a la centralita de energía que emita el consumo instantáneo de forma periódica durante una ventana de tiempo, con lo que la magnitud pasa a llegar sola y el bus deja de recibir preguntas.
Qué hay entre la pasarela y la plataforma
El nodo Connect vive en la instalación, en contenedores Docker, y persiste localmente sobre una base de datos de series temporales. La sesión OpenWebNet es saliente desde el nodo hacia la pasarela y se queda dentro de la red del edificio. Hacia fuera, el nodo no abre puertos entrantes: el enlace con la plataforma lo establece Tailscale como conexión saliente segura. Esto importa más aquí que en un protocolo de planta, porque OpenWebNet viaja en claro y su autenticación es débil por diseño: exponer una pasarela MyHome a internet con un redireccionamiento de puerto es una mala idea que sigue viéndose, y la integración con Connect la vuelve innecesaria. La pasarela solo tiene que ser accesible desde una IP, la del nodo.
La persistencia local también cubre un caso muy concreto de este protocolo: cuando la sesión de monitorización se cae, y se cae, porque muchas pasarelas cierran sesiones inactivas y se reinician tras un corte de tensión, Connect reconecta y vuelve a lanzar el barrido de estado inicial. Sin ese barrido, la reconexión dejaría un hueco silencioso en el que la instalación cambió de estado y nadie se enteró.
Qué equipos hablan OpenWebNet en una instalación real
OpenWebNet no aparece en la máquina. Aparece en el edificio que rodea a la máquina, y en un proyecto industrial suele entrar por uno de estos cuatro sitios.
El primero es la pasarela web o servidor de la instalación, que es el único equipo con el que Connect habla de verdad. Es la caja de carril DIN con conector Ethernet que el instalador puso para el control remoto o para la app del edificio, y su papel es traducir entre el bus de dos hilos y TCP. Todo lo demás se ve a través de ella. La conversación de arranque de un proyecto empieza siempre por la misma pregunta: qué pasarela hay, qué firmware tiene y quién conoce la contraseña OPEN.
El segundo son los actuadores y reguladores de iluminación de zonas comunes, oficinas, naves con alumbrado gestionado y aparcamientos. Son la fuente natural de horas de funcionamiento por circuito y de perfiles de uso reales, que es el dato que falta cuando alguien intenta justificar una renovación de alumbrado con estimaciones de catálogo.
El tercero es la termorregulación: sondas de zona, unidades de clima gobernadas desde la centralita y consignas por ambiente. Aquí el valor no está en la temperatura suelta sino en la pareja temperatura medida contra consigna, porque la diferencia sostenida entre ambas es la que revela una zona que nunca alcanza el objetivo o un equipo sobredimensionado que cicla.
El cuarto son los medidores de la gestión de energía del sistema, que dan potencia activa y acumulados por línea. Conviene situarlos bien: miden circuitos internos del edificio, no la frontera con la distribuidora. La medida de frontera es otra cosa y se lee por otra vía, normalmente IEC 870-5-102 contra el contador fiscal.
Fuera de esto queda todo lo que es proceso. Un autómata, un variador o un analizador de red no hablan OpenWebNet y no van a hacerlo: esos se leen por Modbus o por OPC UA. El proyecto de ingeniería que hace convivir ambos mundos en una sola capa de adquisición es el de interoperabilidad entre sistemas industriales y de edificio, y la toma de datos de la parte de instalación es conectividad de sensores e instalación.
De trama OpenWebNet a serie temporal
Aquí está el trabajo real de esta integración, y es más profundo que en OPC UA por una razón simple: la trama no trae casi nada. No trae tipo declarado, no trae unidad, no trae calidad de lectura y, sobre todo, no trae marca de tiempo. Una trama*1*1*12## significa que el punto luz 2 del ambiente 1 se ha encendido, y punto. Todo lo demás lo pone Connect.
El timestamp lo pone el edge, y hay que ser honesto sobre ello
La pasarela no fecha las tramas. Connect marca cada muestra en el instante en que la recibe en el nodo, que está en el propio edificio y a un salto de red de la pasarela, de modo que la diferencia con el instante real del evento es la latencia del bus y del enlace local. Es una aproximación buena para consumo, clima y uso de instalación, que es para lo que sirve este dato. No es una base de tiempos para reconstruir el orden de sucesos de un incidente eléctrico, y la página lo dice porque la alternativa es que alguien lo descubra durante un análisis. Cuando el histórico necesita eventos fechados en origen con resolución fina, el protocolo adecuado es otro.
Codificación de valores: lo que hay que decodificar
Las magnitudes vienen empaquetadas en convenios propios que hay que deshacer al normalizar. La temperatura llega como una cadena de cuatro dígitos en la que el primero indica el signo y el resto son décimas de grado, así que 0250 son 25,0 grados Celsius y no doscientos cincuenta de nada. Los estados de regulación de un dimmer llegan como valores de WHAT escalonados que hay que traducir a porcentaje de nivel. Los totalizadores de energía son acumulados monótonos que se reinician al sustituir o reprogramar el medidor, así que la serie útil no es el acumulado sino la diferencia entre lecturas consecutivas, con detección del salto negativo que delata un reinicio. Nada de esto lo resuelve el protocolo. Lo resuelve la capa de normalización, y es la mitad del valor de la integración.
La identidad de la señal es el entregable
Un WHERE como 12 o 7A#0 es perfectamente legible para la instalación y perfectamente inútil para cualquiera que consulte el histórico seis meses después. Cada dirección se ata a su ubicación real, planta, ala, sala o cuadro, y se le fija nombre y unidad estables. Este paso exige acompañarse del esquema del instalador o de un recorrido físico del edificio conmutando circuitos y viendo qué trama aparece, y suele ser la tarea que más tiempo consume en un proyecto de este tipo. También es la que hace que el dato de edificio sea comparable con el de producción, que es todo el motivo por el que se integra.
| Lo que entrega la trama | Qué falta y quién lo pone | Para qué sirve después |
|---|---|---|
| WHAT de estado discreto, por ejemplo encendido o apagado de un punto de luz | La semántica y la unidad las fija el mapeo; el valor se guarda como serie binaria de estado | Horas de funcionamiento por circuito y perfil real de uso frente al horario teórico |
| Dimensión de temperatura codificada en décimas con dígito de signo | Connect la decodifica a grados Celsius y la asocia a la zona de clima | Diferencia sostenida entre medida y consigna, que es lo que revela una zona mal resuelta |
| Dimensión de potencia activa de un medidor de línea | Connect fija la unidad en vatios y ata el medidor a su circuito y cuadro | Curva de carga por circuito, base de reparto de consumo entre proceso y servicios |
| Totalizador de energía acumulado | Connect guarda el acumulado y deriva el incremento entre lecturas, detectando reinicios del contador | Consumo por periodo comparable entre circuitos y entre meses |
| Trama sin marca de tiempo | Connect fecha la muestra en el nodo, en el propio edificio, al recibirla | Serie utilizable para consumo, clima y uso, no para reconstruir orden de sucesos eléctricos |
| Dirección WHERE en notación de ambiente y punto | Se ata a planta, sala o cuadro con nombre y unidad estables | Hace la señal consultable por quien no tiene el esquema del instalador delante |
El recorrido genérico de este trabajo, con independencia del protocolo de origen, está desarrollado en la guía de sistema de adquisición de datos, y la definición neutra del elemento que traduce el bus está en el término de glosario pasarela industrial.
Cuándo OpenWebNet no es la vía adecuada
Este es el apartado que ningún fabricante publica y el que evita proyectos mal planteados. OpenWebNet resuelve muy bien un ámbito concreto y es una mala elección fuera de él. Hay seis situaciones en las que hay que decir que no.
No es un protocolo de planta y no debe usarse como tal. El bus no es determinista, no garantiza tiempo de entrega y no tiene ningún concepto de calidad de dato. Cualquier señal que participe en un enclavamiento, en una parada de seguridad o en un lazo de control se lee del sistema que la gobierna, por OPC UA o por Modbus. Que una señal esté cableada al bus del edificio no la convierte en señal de proceso.
No sirve para medida de frontera ni para nada con valor regulatorio. Los medidores del sistema de gestión de energía son medida de reparto interno, útiles para saber qué circuito consume qué. La medida que se factura o que se presenta ante un tercero se lee del contador fiscal por IEC 870-5-102. Confundir las dos produce cuadres imposibles y discusiones que se resuelven tarde.
No sirve cuando se necesita resolución de subsegundo o secuencia de eventos. Sin marca de tiempo en origen y con un bus compartido de por medio, pedirle a OpenWebNet una cronología fina es pedirle algo que no tiene. Si el requisito es ese, la señal hay que tomarla del equipo que sí la fecha.
No sirve para sensórica añadida a posteriori. Añadir un sensor inalámbrico de temperatura, de calidad de aire o de vibración a un edificio no pasa por el bus SCS: pasa por MQTT, que es pub/sub y no obliga a cablear ni a tocar la instalación existente. Ampliar el bus para incorporar sensórica nueva es caro y no aporta nada frente a esa vía.
No sirve si la pasarela solo expone servicios en la nube del fabricante. Es un caso que crece: en parte del parque más reciente el acceso local está desactivado o limitado, y toda la información sale por una API del fabricante. Entonces esto deja de ser un problema de protocolo de bus y pasa a serlo de integración IT, que se resuelve por API REST o webhooks. Comprobarlo antes de comprometer un alcance evita la peor sorpresa de este protocolo.
No es la vía para mandar sobre el edificio desde la plataforma. El protocolo admite tramas de comando, pero la integración se plantea de adquisición. Escribir sobre iluminación o clima desde una capa de datos significa disputarle el gobierno de la instalación a la centralita, con dos sistemas capaces de dar órdenes contradictorias sobre el mismo actuador y sin arbitraje entre ellos. Connect adquiere; el control del edificio se queda donde estaba.
Y un límite que no es del protocolo sino del encargo: OpenWebNet no da contexto. La trama dice que un punto luz se encendió, no dice que ese punto luz es el alumbrado del muelle de carga ni qué turno lo usa. Sin ese trabajo de asignación, el resultado es un histórico de direcciones que nadie consulta. Es la misma cuestión que ordena cualquier integración y la que define qué se le pide a un sistema de adquisición de datos industrial cuando se hace bien.
Convivencia con el resto de la instalación
En un edificio industrial nadie tiene un solo protocolo: tiene el bus del edificio que puso el instalador eléctrico, los autómatas que puso el integrador de proceso y el contador que puso la distribuidora. Connect adquiere en paralelo por todas esas vías y las lleva al mismo modelo de series temporales, de modo que en el histórico la potencia de un circuito de alumbrado leída por OpenWebNet, la producción de una línea leída por OPC UA y la energía de frontera leída por IEC 870-5-102 quedan al mismo nivel. Nadie tiene que saber de qué protocolo vino un dato para poder cruzarlo con otro.
La convivencia que más valor produce es exactamente ese cruce. El consumo del edificio solo se interpreta bien contra la actividad: una nave que consume igual un sábado sin producción que un martes a pleno rendimiento tiene un problema de servicios auxiliares, no de proceso, y eso no se ve mirando ninguna de las dos series por separado. Separar consumo de proceso y consumo de instalación es la condición previa de cualquier trabajo serio de eficiencia energética, y es la razón por la que este protocolo, que parece menor al lado de uno de planta, acaba siendo el que completa el balance.
Sobre migración, la recomendación es no plantear ninguna. Sustituir un bus de edificio en funcionamiento es una obra eléctrica con coste y con parada de servicio, y no la pide nadie para poder medir. Lo que ocurre en la práctica es más sencillo: la instalación existente se queda como está y se lee a través de su pasarela, y todo lo que se añada después entra por la vía que le corresponda, normalmente sensórica sobre MQTT o equipos de proceso sobre Modbus y OPC UA. Cuando existe una capa de adquisición que acepta lo que hay, el bus del edificio deja de ser un sistema aislado y pasa a ser una fuente más.
Sobre esa base ya trabajan los módulos de la plataforma, y el proyecto de ingeniería que la implanta en un edificio con instalación existente es el de interoperabilidad entre sistemas industriales y de edificio.