Integración de protocolos
Integración KNX
Cómo se mapean las direcciones de grupo, las pasarelas y los tipos de punto de datos KNX en una plataforma de edificios, y cómo se prueban y se entregan sin perder el control local.
Qué es KNX y dónde se utiliza
KNX es un estándar abierto de control de edificios construido en torno a un bus de par trenzado, con extensiones para IP, radio y powerline. Es habitual en Europa y se usa ampliamente para iluminación, protección solar, control de habitaciones, actuadores de climatización (HVAC) y detección de presencia. Los dispositivos se ponen en marcha individualmente: cada uno tiene un programa de aplicación, parámetros y direcciones de grupo. El bus es descentralizado, por lo que un pulsador puede activar un regulador sin un controlador central. Esa resiliencia local es una de las razones por las que KNX sobrevive mucho después de que el instalador original se haya ido. Es un bus de campo ante todo, no un sistema IP. El proyecto de integración debe respetarlo: el bus conserva su comportamiento local y la plataforma añade supervisión en lugar de dependencia. Referencia del protocolo: una línea admite hasta 64 dispositivos de bus y un área hasta 15 líneas, y el bus se alimenta por separado de las fuentes propias de los dispositivos. Esos límites deciden dónde deben situarse los acopladores, los repetidores y la capacidad de reserva. Un bus que está sano a nivel de campo puede seguir estando mal documentado, y la documentación es lo que hereda el siguiente proyecto.
- Iluminación, regulación de intensidad y control de escenas
- Protección solar y automatización de fachadas
- Control de habitaciones, actuadores de climatización (HVAC) y presencia
- Europa y proyectos con especificaciones multimarca
- Límites del bus planificados antes de la integración
Rutas de integración y selección de pasarela
Hay tres rutas habituales. Una interfaz o pasarela KNX conecta el bus a la plataforma por IP y expone las direcciones de grupo como puntos legibles y escribibles. Un router IP KNX hace lo mismo en la capa de red y puede abarcar líneas. Un puerto KNX nativo es posible cuando el controlador lo admite. La ruta decide la capacidad, la latencia y el diagnóstico. Pregunte cuántas direcciones de grupo puede exponer la pasarela, si admite tunelización o enrutamiento, cuántas conexiones simultáneas permite y qué ocurre cuando falla el bus o la red IP. Para una instalación grande, segmente el bus y coloque los routers de forma deliberada en lugar de extender una sola línea. Una pasarela es infraestructura: dele una unidad de reserva, una dirección fija y un procedimiento de sustitución documentado. La tunelización es cómoda para un único supervisor; el enrutamiento es mejor cuando varios clientes necesitan el bus a la vez. Registre qué líneas están detrás de cada acoplador; un fallo en una línea no debería obligar a abrir todo el cuadro.
- Pasarela o interfaz KNX sobre IP
- Router IP KNX para instalaciones grandes o segmentadas
- Puerto KNX nativo cuando esté disponible
- Capacidad, latencia y failover confirmados antes del diseño
De la dirección de grupo al punto de plataforma
Un punto KNX no es solo una dirección. El registro de mapeo debe incluir la dirección de grupo, el tipo de punto de datos, la unidad, la escala, la dirección de lectura/escritura, el dispositivo propietario y la función a la que sirve. Un objeto de un bit puede ser un estado, un comando o un disparador de escena; el registro debe indicar cuál. Los tipos de punto de datos llevan el escalado: un valor de un byte puede ser un porcentaje, un valor de dos bytes puede ser una temperatura en décimas de grado. Los indicadores de lectura y escritura no son intercambiables, y una dirección de estado debe estar separada de una dirección de comando. La nomenclatura debe seguir un estándar de edificio en lugar de las iniciales del instalador. La lista de puntos es el contrato entre el programador KNX y el ingeniero de la plataforma. Pruebe una muestra de cada tipo de punto de datos en lugar de suponer que un ejemplo que funciona cubre el resto. Cuando dos sistemas escriben en una dirección de grupo, el proyecto necesita una regla de arbitraje y un único responsable. Una dirección de grupo utilizada tanto para comando como para estado es una causa habitual de oscilación.
- Dirección de grupo y tipo de punto de datos
- Dirección de lectura/escritura y responsabilidad
- Unidad, escalado y rango de ingeniería
- Convención de nomenclatura y regla de arbitraje
Nomenclatura de puntos y registro de mapeo
La nomenclatura de puntos debe ser legible a las 03:00. Utilice una estructura fija: edificio, planta, sala o sistema, dispositivo, función y tipo de señal. Mantenga la dirección de grupo KNX en el registro, no necesariamente en el nombre visible; el operador necesita la función y el ingeniero necesita la dirección. El registro de mapeo debe poder exportarse, porque se comparará con el proyecto ETS, la exportación de la pasarela y la base de datos de la plataforma. Cada punto debe mostrar su tipo de punto de datos, unidad, escala, dirección, límite de alarma y responsable. Cuando un punto se calcule o combine, registre las entradas. Una convención de nomenclatura solo es útil si se aplica; añada un paso de revisión antes de congelar la lista de puntos. Evite nombres que codifiquen una condición temporal, como una planta que se renombrará o un inquilino que se mudará. Evite abreviaturas que solo entiende un instalador. El registro también debe anotar la dirección de dispositivo ETS, para que una traza de bus pueda asociarse a un dispositivo.
- Estructura fija legible sin el plano
- Dirección de grupo en el registro, función en el nombre
- Registro de mapeo exportable
- Revisión antes de congelar la lista de puntos
Pruebas y puesta en marcha
Pruebe primero el bus, después la pasarela y por último la plataforma. En el bus, confirme la alimentación de los dispositivos, los acopladores de línea, la comunicación de direcciones de grupo y la recuperación de escenas. En la pasarela, confirme el descubrimiento, la exportación de direcciones, el comportamiento de lectura y escritura y la reconexión tras una interrupción de red. En la plataforma, confirme que cada punto mapeado muestra el valor, la unidad y el estado correctos, y que un comando llega al dispositivo de campo. Pruebe la ruta de fallo: desconecte la pasarela y compruebe que las funciones KNX locales continúan. Registre el resultado contra la lista de puntos, no en un cuaderno aparte. Un punto que aparece en un árbol de navegación no está puesto en marcha hasta que se ha leído, escrito y observado. Incluya una comprobación de carga del bus: un sondeo intenso puede hacer que una instalación sana parezca poco fiable. Incluya un reinicio de la pasarela y un reinicio de la plataforma; el comportamiento de recuperación forma parte de la función. Pruebe el bus con la plataforma desconectada y después conectada; ambos estados importan.
- Salud del bus, acopladores y tráfico de direcciones de grupo
- Descubrimiento de pasarela, lectura/escritura y reconexión
- Valor, unidad y estado por punto en la plataforma
- Operación local con la pasarela desconectada
- Pruebas de reinicio y recuperación
Limitaciones, entrega y responsabilidades
KNX es robusto a nivel de campo, pero tiene límites. El ancho de banda del bus es compartido, por lo que un sondeo intenso es un mal diseño. El caos de direcciones de grupo es habitual en instalaciones antiguas y debe depurarse antes de la integración. Algunos dispositivos exponen solo objetos limitados, y algunos fabricantes utilizan sus propias extensiones. KNX Secure requiere una gestión de claves que la plataforma debe admitir. La regla práctica es sencilla: mantenga el control de campo en el campo, mantenga la lógica entre sistemas en la plataforma y documente la frontera. La integración debe hacer el bus más legible, no ocultarlo. El paquete de entrega debe incluir el proyecto ETS o una exportación de direcciones, el registro de mapeo, la configuración de la pasarela y los registros de pruebas. La responsabilidad del bus sigue siendo del instalador KNX; la responsabilidad del mapeo recae en el integrador. Incluya ese reparto en el contrato, especialmente para los cambios posteriores a la entrega. Una futura adecuación añadirá dispositivos; deje rangos de direcciones y capacidad de pasarela para ella. Un pequeño stock de reserva de acopladores, fuentes de alimentación y terminales de bus ahorra una visita.
- Evite el sondeo cuando funcione la comunicación basada en eventos
- Depure y documente las direcciones de grupo heredadas
- Confirme el soporte de KNX Secure antes del diseño
- Mantenga el control local independiente de la plataforma
- Deje margen de direcciones y de pasarela
Planificación de la integración KNX
14 rows| Elemento | Qué confirmar | Por qué importa |
|---|---|---|
| Medio del bus | Par trenzado, IP, radio o mixto | Determina la pasarela y la topología |
| Estructura de líneas y áreas | Acopladores, fuentes de alimentación, capacidad de reserva | Evita sobrecargas y simplifica el diagnóstico |
| Límites de dispositivos | Referencia del protocolo: 64 dispositivos por línea, 15 líneas por área | Determina dónde deben situarse acopladores y repetidores |
| Esquema de direcciones de grupo | Nomenclatura, rangos, responsabilidad | Hace posible el mapeo y los cambios futuros |
| Tipos de punto de datos | Tipo, unidad, escalado | Evita valores y comandos erróneos |
| Indicadores de lectura/escritura | Separación de comando y estado | Evita bucles de realimentación y escrituras conflictivas |
| Capacidad de la pasarela | Número de direcciones, tunelización o enrutamiento, clientes | Establece el límite de integración |
| Derechos de lectura/escritura | Quién puede escribir en cada dirección | Evita comandos conflictivos |
| Escenas y horarios | Dónde residen y quién es responsable de ellas | Evita la lógica duplicada |
| KNX Secure | Gestión de claves y soporte de dispositivos | Afecta la puesta en marcha y la elección de plataforma |
| Diagnóstico | Monitor de bus, registros de pasarela, eventos de plataforma | Acorta la localización de fallos |
| Carga del bus | Tasa de sondeo y tráfico de eventos | Mantiene la respuesta predecible |
| Registros de pruebas | Dirección, tipo de punto de datos y resultado observado | Demuestra cada punto mapeado |
| Entrega | Proyecto ETS, exportación de direcciones, lista de puntos | Mantiene el sistema mantenible |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Se puede integrar una instalación KNX existente?
Normalmente sí, si el bus está sano y las direcciones de grupo pueden leerse. La auditoría debe confirmar la alimentación de los dispositivos, los acopladores, la disponibilidad del proyecto ETS y si las direcciones están documentadas.
02¿Necesitamos el proyecto ETS original?
Ayuda. Sin él, los parámetros de los dispositivos y las direcciones de grupo pueden seguir siendo legibles, pero los cambios se vuelven arriesgados. Un proyecto ETS ausente es un hallazgo que debe resolverse antes de la integración, no un detalle que se descubre en la puesta en marcha.
03¿Pueden Loxone y KNX compartir el control?
Sí. El proyecto define qué sistema es responsable de cada dirección de grupo y cómo se resuelven los conflictos. Un reparto habitual es KNX para los dispositivos de campo y Loxone para la lógica entre sistemas y las vistas de operador.
04¿La integración KNX requiere una pasarela?
Requiere una interfaz entre el bus KNX y la plataforma. Puede ser una pasarela, un router IP o un puerto KNX nativo, según el controlador y la instalación.
05¿Cuántas direcciones de grupo se pueden integrar?
Depende de la pasarela y del controlador, no de un límite fijo de la plataforma. El diseño debe confirmar el número de direcciones, la tasa de actualización y el diagnóstico antes de congelar la lista de puntos.
06¿Podemos conservar las escenas KNX?
Sí. Las escenas pueden permanecer en los dispositivos KNX o trasladarse a la plataforma, pero no en ambos sin un responsable claro. La lógica de escenas duplicada es una causa habitual de comportamiento incoherente.
07¿Qué ocurre si la plataforma se desconecta?
Los dispositivos KNX deben continuar sus funciones locales: pulsadores, reguladores, actuadores de persianas y controles de habitación. La lógica entre sistemas se detiene hasta que la plataforma vuelve. Ese modo de fallo debe probarse y explicarse al operador.
08¿Es KNX adecuado para hoteles?
KNX es habitual en las especificaciones de habitaciones de hotel, especialmente en Europa. Funciona bien para iluminación, protección solar y control de habitaciones; la lógica de PMS y energía suele situarse por encima.
Siguiente paso
Tráiganos el edificio.
Cuéntenos el tipo de edificio, los sistemas incluidos y el resultado que necesita. Le mostraremos la ruta más corta hacia un sistema en funcionamiento.