Comparación
Loxone frente a KNX
Una comparación práctica de Loxone y KNX: dónde se ejecuta la lógica, cómo se cablean los dispositivos, cómo se realizan los cambios y cuándo tiene sentido un diseño híbrido.
Dos arquitecturas en una frase
KNX distribuye la inteligencia a los dispositivos. Un sensor de presencia, un actuador de regulación, un actuador de persianas y un pulsador tienen cada uno su propia conexión al bus y su propia aplicación. Intercambian direcciones de grupo por un bus de par trenzado, y cualquier dispositivo puesto en marcha puede actuar sobre un telegrama sin un controlador central. Loxone centraliza la lógica en un controlador. El Miniserver lee las entradas, ejecuta el programa y activa las salidas; los dispositivos se conectan mediante Tree, Air, KNX, Modbus o IP. Esta diferencia explica la mayoría de los compromisos prácticos que siguen. También explica por qué los dos sistemas fallan de forma distinta: una instalación KNX puede seguir funcionando dispositivo a dispositivo cuando se pierde un supervisor, mientras que una instalación Loxone depende del controlador y de su copia de seguridad. Ningún modelo es una religión; cada uno impone una disciplina distinta al diseño, las pruebas y la documentación. La pregunta correcta es dónde debe residir la lógica durante la vida del edificio.
- KNX: dispositivos distribuidos, telegramas de direcciones de grupo
- Loxone: lógica central, controlador local, dispositivos multiprotocolo
- Ambos pueden coexistir en el mismo proyecto
Cableado, topología y límites de dispositivos
Una instalación KNX es un bus: los dispositivos se conectan en cadena o en estrella sobre el mismo par, con una fuente de alimentación y un acoplador entre líneas y áreas. Referencia del protocolo: una línea admite hasta 64 dispositivos de bus y un área hasta 15 líneas, por lo que la topología y la capacidad de reserva deben planificarse en lugar de improvisarse. Es predecible y muy adecuada para proyectos de obra nueva con una lista de dispositivos clara. Loxone Tree utiliza un único cable que transporta alimentación y comunicación a los dispositivos Tree, lo que reduce los tendidos individuales pero vincula la selección de dispositivos al ecosistema Tree. Air cubre la rehabilitación y las ubicaciones difíciles de cablear. En la práctica es habitual un diseño híbrido: KNX para iluminación y protección solar, Tree o Air para controles de habitación, y un controlador para la lógica entre sistemas. La topología debe dibujarse antes de tender el primer cable. La longitud del bus, el margen de la fuente de alimentación, la ubicación de los acopladores y los dispositivos de reserva importan más que la etiqueta del cable.
- Bus KNX: planificación de líneas, áreas y acopladores
- Tree: un solo cable para alimentación y datos
- Air: rehabilitación y trazados difíciles
- Híbrido: protocolo elegido por dispositivo, no por ideología
Programación, control de cambios y versionado
La ingeniería KNX se realiza en ETS. Cada dispositivo tiene un programa de aplicación, parámetros y direcciones de grupo; un cambio se aplica descargando de nuevo el dispositivo. El modelo es explícito y portable, pero depende del proyecto ETS y de la disciplina de direcciones de grupo. La ingeniería Loxone se realiza en Loxone Config. La lógica se construye como bloques de función y conexiones en el controlador, lo que hace que las secuencias entre sistemas sean más rápidas de leer y modificar, pero la lógica queda vinculada a la configuración de ese controlador. Ningún modelo es intrínsecamente mejor; fallan de formas distintas. Un proyecto KNX sin su archivo ETS es difícil de modificar con seguridad. Un proyecto Loxone sin una copia de seguridad versionada de Config es igual de frágil. Ambos necesitan registros as-built, un registro de cambios y una persona designada que pueda aprobar una descarga. La prueba práctica es sencilla: ¿puede un tercero competente entender el cambio, realizarlo y revertirlo?
- KNX: proyecto ETS, parámetros de dispositivo, direcciones de grupo
- Loxone: proyecto Config, bloques de función, enlaces
- Copias de seguridad versionadas para ambos
- Aprobador designado para las descargas
Pasarelas y selección de interfaces
Las pasarelas determinan cuánto de un sistema puede ver el otro. Una interfaz IP KNX expone las direcciones de grupo a un controlador; un router IP KNX une líneas y áreas y puede transportar tanto enrutamiento como tunelización. La elección afecta la capacidad, la latencia, el diagnóstico y el número de conexiones simultáneas. Pregunte cuántas direcciones de grupo puede exportar la interfaz, si admite enrutamiento o tunelización, cómo se comporta tras una interrupción de red y si se requiere KNX Secure. Una pasarela saturada en la entrega no deja margen para la siguiente adecuación. La misma lógica se aplica a otros puentes de protocolo: cuente puntos, no dispositivos, y reserve capacidad para los cambios que siempre llegan. La pasarela debe tratarse como infraestructura con un modo de fallo, una unidad de reserva y un procedimiento de sustitución documentado. Registre su dirección IP, subred, puerto y credenciales bajo control de cambios.
- Interfaz IP KNX frente a router IP
- Tunelización frente a enrutamiento y clientes concurrentes
- Capacidad, latencia y KNX Secure
- Reserva, dirección fija y procedimiento de sustitución
Puesta en marcha, pruebas y modos de fallo
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 en el dispositivo de campo. Las pruebas de secuencia deben incluir los casos que solo ocurren de noche: una luminaria averiada, una persiana bloqueada, un reinicio del controlador durante una escena.
- 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
- Registros de pruebas firmados contra la lista de puntos
Ecosistema, coste del ciclo de vida y dependencia del proveedor
KNX tiene un mercado de dispositivos amplio: muchos fabricantes, muchos formatos y una base de instalaciones extensa, especialmente en Europa. La competencia puede mantener visibles los precios de los dispositivos, pero el tiempo de ingeniería y de puesta en marcha son costes reales. Loxone tiene un catálogo de dispositivos más reducido y una experiencia de software más integrada; el controlador y su programación pasan a ser el centro del proyecto. En ambos casos, la oferta inicial más barata no siempre es la más económica a lo largo del ciclo de vida. Cuente las horas de ingeniería, los repuestos, la formación y los cambios futuros, no solo el hardware. Cuente también el coste de la frontera: dos sistemas implican dos conjuntos de competencias, dos conjuntos de documentación y un mapeo que debe mantenerse. Un diseño híbrido suele ser la respuesta correcta, pero no es gratuito. La dependencia del proveedor no es solo una cuestión de licencias; también es una cuestión de competencias, y la comparación honesta incluye a la persona que seguirá disponible dentro de cinco años para cambiar una dirección de grupo o un bloque de Config.
- KNX: dispositivos multimarca, se requieren competencias en ETS
- Loxone: pila integrada, centrada en el controlador
- El coste del ciclo de vida incluye ingeniería y cambios
- Dos sistemas implican dos conjuntos de competencias y un mapeo
Cuál se adapta a su edificio
Elija KNX cuando la especificación exija un bus independiente del fabricante, cuando el consultor o el cliente ya tenga experiencia en KNX, o cuando la variedad de dispositivos de muchos fabricantes sea un requisito estricto. Elija Loxone cuando el edificio necesite una capa de lógica sobre climatización (HVAC), iluminación, protección solar, energía y acceso, y cuando el control local con una interfaz de operador clara importe más que la independencia de los dispositivos. Muchos proyectos eligen ambos: KNX en el nivel de campo, Loxone en el nivel de integración. Es una decisión de diseño, no un compromiso. La decisión debe registrarse con sus motivos, porque la siguiente persona preguntará por qué la frontera está donde está. Una regla sencilla ayuda: ponga el control donde está el dispositivo y la coordinación donde está el edificio. Si el proyecto no tiene equipo de mantenimiento, prefiera la arquitectura con menos piezas móviles y documentación más clara.
- KNX primero: dispositivos de campo multimarca y ETS interno
- Loxone primero: lógica integrada y una única vista de operador
- Híbrido: bus de campo KNX, supervisión Loxone
- Documente la frontera y sus motivos
Loxone y KNX en comparación
15 rows| Criterio | Loxone | KNX |
|---|---|---|
| Arquitectura | Centrada en el controlador; lógica en el Miniserver | Distribuida; lógica en los dispositivos de bus |
| Cableado de campo | Tree, Air, KNX, Modbus e IP | Bus de par trenzado con acopladores de línea y de área |
| Límites de topología | Capacidad del controlador y límites de segmento Tree o Air | Hasta 64 dispositivos por línea y 15 líneas por área |
| Programación | Bloques de función de Loxone Config | ETS con parámetros de dispositivo y direcciones de grupo |
| Elección de dispositivos | Ecosistema Loxone más protocolos abiertos | Catálogo KNX multimarca |
| Iluminación y protección solar | Dispositivos nativos e integración KNX o DALI | Actuadores y sensores KNX nativos |
| HVAC | Mediante I/O, Modbus, BACnet o KNX | Mediante actuadores y pasarelas KNX |
| Lógica entre sistemas | Sólida; un único programa de controlador | Posible, pero repartida entre dispositivos y pasarelas |
| Rehabilitación | Air y Tree reducen el cableado nuevo | Sigue siendo necesario cablear el bus hasta cada dispositivo |
| Pasarela e interfaz | Interfaz KNX nativa o pasarela IP | Interfaz IP o router, tunelización o enrutamiento |
| Diagnóstico | Registros de la plataforma y diagnóstico del controlador | Monitor de bus, registros de pasarela y diagnóstico de ETS |
| Comportamiento ante fallos | El fallo del controlador detiene la lógica central; los dispositivos locales varían | Los dispositivos de bus pueden mantener funciones locales |
| Gestión de cambios | Versión de Config y copia de seguridad del controlador | Proyecto ETS y disciplina de direcciones de grupo |
| Competencias | Formación en Loxone Config | Experiencia en ETS y disciplina de direcciones de grupo |
| Encaje típico | Lógica integrada del edificio y una única vista de operador | Especificación de dispositivos multimarca |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Puede Loxone controlar dispositivos KNX?
Sí, mediante una interfaz o pasarela KNX. Los dispositivos KNX conservan sus propios programas de aplicación; Loxone lee y escribe direcciones de grupo. El proyecto debe confirmar qué tipos de punto de datos y direcciones de grupo se exponen.
02¿Es KNX más abierto que Loxone?
KNX es un estándar abierto con dispositivos de varios fabricantes. Loxone es una plataforma propietaria con interfaces abiertas, incluidas KNX, Modbus, BACnet y API basadas en IP. La apertura depende de lo que necesite cambiar más adelante, no solo del nombre del protocolo.
03¿Cuál es más económico?
No hay una respuesta universal. KNX puede tener precios de dispositivos más competitivos, pero requiere ingeniería ETS. Loxone puede reducir el cableado y el esfuerzo de integración, pero centra el proyecto en su controlador. Compare todo el ciclo de vida: diseño, hardware, programación, puesta en marcha, repuestos y cambios futuros.
04¿Podemos combinar Loxone y KNX en un mismo edificio?
Sí. Un patrón habitual es KNX para iluminación y protección solar en el nivel de campo, con Loxone ejecutando la lógica entre sistemas, la climatización (HVAC) y la energía. La frontera debe documentarse: qué sistema es responsable de cada dirección de grupo, escena y horario.
05¿Sustituye Loxone una instalación KNX?
No físicamente. Los dispositivos KNX existentes normalmente pueden permanecer en su sitio e integrarse. La sustitución solo tiene sentido cuando los dispositivos están obsoletos, no disponibles o no pueden proporcionar la función requerida.
06¿Cuál es mejor para un hotel?
Ambos pueden funcionar. KNX es habitual en las especificaciones hoteleras europeas y ofrece una amplia variedad de dispositivos. Loxone es sólido cuando el control de habitaciones, los eventos del PMS, la energía y la supervisión del edificio necesitan una única capa de lógica. El tipo de habitación y el modelo operativo deben decidirlo.
07¿Necesitamos ETS para modificar un sistema KNX?
Sí para cambios a nivel de dispositivo: los parámetros y las direcciones de grupo residen en el proyecto ETS. Un supervisor puede cambiar escenas y horarios sin ETS, pero no la aplicación del dispositivo.
08¿Qué ocurre cuando falla el controlador?
Los dispositivos KNX pueden continuar la operación local del bus para las funciones que no dependen de un controlador. Los controladores Loxone deben especificarse con capacidad de reserva, copia de seguridad y un procedimiento de recuperación documentado. El modo de fallo forma parte del diseño.
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.