Wat interoperabiliteit tussen producten van verschillende fabrikanten betreft, is KNX vanaf dag één altijd de beste in zijn klasse geweest. Dat is onder meer te danken aan het strenge KNX certificeringsprogramma voor producten van derden. Niettemin, en vooral vanwege de overvloed aan andere oplossingen voor woning- en gebouwautomatisering (zowel bedrijfsgebonden als andere protocollen) en door het wijdverbreide gebruik van het internet, vereist de markt tegenwoordig dat elk systeem een goed gedocumenteerde manier biedt om ermee te interageren, via mechanismen die in de IT-industrie state-of-the-art zijn.
Als je wilt gebruikmaken van data van KNX installaties via bovengeschikte systemen of integratieplatforms (die KNX linken aan andere niet-KNX apparaten van derden), zou je verwachten dat je het KNX protocol niet hoeft te instrueren, maar dat je de volgende data kunt ophalen – via een gestandaardiseerde RESTful API die niet fabrikantspecifiek is:
Wat belangrijk is voor
fabrikanten die dergelijke integratieplatforms implementeren, is dat de
informatie die deze KNX IoT-gateways leveren machinaal leesbaar is en een rijke
semantiek heeft. In het ideale geval is dat het directe resultaat van de
gebruikte productgegevens en/of het werk geleverd door de elektricien bij het
ontwerpen en configureren van de KNX installatie. Daarom zouden de rijke
(semantische) data eenvoudigweg aan de KNX IoT gateway moeten worden geleverd
via een specifieke ETS-export, die stabieler is dan de huidige
XML-bestandsindeling en gemakkelijker te upgraden valt. Die verrijkte data
zouden ook de mogelijkheid moeten bieden om een KNX installatie makkelijker te
ontwerpen (eenvoudigere selectie van ondersteunde productfunctionaliteit).
Mogelijk zouden ze ook de basis moeten vormen voor een eenvoudigere binding
tussen verschillende producten en zouden ze een installatie tijdens haar
levensduur moeten documenteren als onderdeel van de BIM-gegevens (Building
Information Modelling).
De API voor derden is ook zo ontworpen dat hij een websocketinterface kan ondersteunen die bijvoorbeeld directe cloudintegratie met bidirectionele communicatie mogelijk maakt. Cloudtoepassingen kunnen zich op deze manier abonneren op informatie op aanvraag, waardoor de gegevensoverdracht naar de cloud en de kosten tot een minimum worden beperkt. De websocketinterface kan ook worden gebruikt voor berichtgeving, bijvoorbeeld om via een GUI meldingen te krijgen over gewijzigde gegevens. Zo kunnen wijzigingen aan het systeem onmiddellijk worden getoond. Uiteraard biedt de KNX IoT interface voor derden ook geavanceerde IT-beveiliging.
Met de definitieve stemming over de specificaties vervolledigt KNX nu de bovenvermelde interface voor derden en het bijbehorende KNX informatiemodel, dat ook toegankelijk is voor niet-KNX leden via https://schema.knx.org.
Als volgende stap en op basis van de KNX conceptspecificaties die al beschikbaar zijn, wil KNX ook de laatste hand leggen aan de KNX IoT Point API specificaties, een oplossing die IPv6-communicatie op veldniveau tussen sensor en actor (groep van actoren) mogelijk maakt. Hierdoor zullen KNX installaties uit te breiden zijn met apparaten die andere media zoals Thread of wifi gebruiken om KNX data uit te wisselen. In een eerste fase zou de groepscommunicatie worden gerealiseerd via vooraf geconfigureerde ontvangers (brokers). KNX wil hiervoor de definitieve stemming over de specificaties binnen een jaar afronden en plant een ETS-prototype dat de configuratie van veiligheids- en groepstabellen in de eerste KNX IoT apparaatprototypen van fabrikanten mogelijk maakt.
Ontdek de nieuwe mogelijkheden in het KNX ontwikkelingslandschap dankzij
de KNX IoT-specificaties.