En relación con la interoperabilidad entre productos de diferentes fabricantes, KNX siempre ha destacado gracias al riguroso esquema de certificación de productos KNX de terceros. A pesar de ello, el mercado actual requiere que todos los sistemas proporcionen una forma documentada de interactuar a través de mecanismos innovadores en la industria de las TI principalmente debido a la gran cantidad de soluciones de domótica e inmótica (ya sean propietarios u otros protocolos) y debido al uso generalizado de Internet.

Si desea acceder a los datos de las instalaciones KNX a través de sistemas superiores o plataformas de integración (vinculando KNX a otros dispositivos de terceros no KNX), esperaría no tener que aprender el protocolo KNX, pero podría recuperar los siguientes datos a través de una RESTful AP estandarizada y no específica del fabricante:

• ¿De qué ubicaciones (salas) se compone la instalación?
• ¿Qué funcionalidades (como iluminación, calefacción/refrigeración, protección solar, ...) influyen en una determinada ubicación?
• ¿Qué datos están relacionados con esa funcionalidad o con el dispositivo que realiza la funcionalidad y cómo puedo leerlos y cambiarlos (en caso necesario)?
• ¿Qué enlace tiene esta funcionalidad con el mundo real/físico?
• ¿El dispositivo estaba físicamente instalado?

Lo importante para los fabricantes que implementan tales plataformas de integración es que la información proporcionada por estas pasarelas KNX IoT se pueda leer con máquinas y presente una semántica enriquecida o, en el mejor de los casos, el resultado directo de los datos del producto utilizados o el trabajo realizado por el instalador que diseña y configura KNX. Por lo tanto, los datos (semánticos) enriquecidos simplemente deben suministrarse a la pasarela KNX IoT mediante una exportación ETS específica que sea más estable que el formato XML actual y más fácil de actualizar. Dichos datos enriquecidos también deben brindar la posibilidad de simplificar la fase de diseño de una instalación KNX (selección más sencilla de la funcionalidad del producto compatible), constituyen la base para una vinculación más cómoda entre diferentes productos y deben documentar una instalación durante su vida útil como parte de los datos para el modelado de información de construcción (BMI, por sus siglas en inglés).

El API de terceros también se ha diseñado de manera que sea compatible con una interfaz websocket que permite, por ejemplo, la integración directa en la nube con comunicación bidireccional. De esta forma, las aplicaciones en la nube pueden suscribirse a información bajo demanda para minimizar la transferencia de datos a la nube y los costes. La interfaz websocket también se puede usar para mensajería, por ejemplo, para que una interfaz gráfica reciba notificaciones sobre datos modificados para poder mostrar inmediatamente cambios en el sistema. Huelga decir que la interfaz KNX IoT de terceros proporciona seguridad de TI de última generación.

Con la votación final de las especificaciones, KNX completa la interfaz de terceros anterior y el modelo de información KNX accesible para miembros ajenos a KNX a través de https://schema.knx.org.

Como siguiente paso y sobre la base del borrador de especificaciones KNX ya disponibles, KNX también desea finalizar las especificaciones KNX IoT Point API, una solución que permite la comunicación de sensor/actuador (grupo) con nivel de campo IPv6. Esto permitirá ampliar las instalaciones KNX con dispositivos que utilicean otros medios como Thread o WiFi para intercambiar datos KNX. Como primer paso, la comunicación de grupos se realizaría a través de destinatarios preconfigurados (intermediarios). Para ello, KNX planea completar la votación final de las especificaciones en un año y un prototipo ETS que permita la configuración de seguridad y tablas de grupo en los primeros prototipos de dispositivos KNX IoT de los fabricantes.

Descubra las nuevas posibilidades encontradas en el panorama del desarrollo KNX gracias a las especificacionesde KNX IoT.