Per quanto riguarda l’interoperabilità tra prodotti di costruttori diverse, KNX è sempre stato il migliore della categoria fin dalla sua concezione, grazie anche al rigoroso schema di certificazione KNX di terze parti dei prodotti. Nonostante questo, principalmente per la pletora di altre soluzioni di automazione di case ed edifici (di proprietà o altri protocolli) e per la diffusione di internet, oggi il mercato richiede che un sistema fornisca una via di interazione ben documentata, attraverso meccanismi allo stato dell’arte nel settore IT.

Se desideri attingere ai dati delle installazioni KNX tramite piattaforme integrative o sistemi superordinati (che collegano KNX ad altri dispositivi non KNX di terze parti), ti aspetteresti semplicemente di non dovere conoscere il protocollo KNX, ma di riuscire a recuperare i seguenti dati, tramite un’API RESTful standardizzata e non specifico del costruttore:

• quali posizioni (sale) costituiscono l’installazione?
• quali funzionalità (per es. illuminazione, riscaldamento/raffreddamento, ombreggiatura, ecc.) influiscono su una determinata posizione?
• quali dati sono collegati a tale funzionalità o dispositivo che esegue la funzionalità e come posso leggerli e (eventualmente) modificarli?
• qual è il collegamento di questa funzionalità con il mondo reale/fisico?
• dov’è installato fisicamente il dispositivo?

L’importante per i costruttori che implementano queste piattaforme integrative è che i dati forniti dai gateway IoT KNX siano leggibili dalla macchina e possiedano un arricchimento semantico, preferibilmente il risultato diretto dei dati di prodotto utilizzati e/o trattati dall’installatore che progetta e configura l’installazione KNX. Di conseguenza, l’arricchimento (semantico) dei dati potrebbe essere semplicemente fornito al gateway IoT KNX da un’esportazione ETS specifica, che sia più stabile dell’attuale formato KML e più facile da aggiornare. Questi dati arricchiti offriranno inoltre la possibilità di semplificare la fase progettuale di un’installazione KNX (selezione più facile di funzionalità del prodotto supportata), oltre a costituire eventualmente la base di un legame più semplice tra i diversi prodotti e documentare un’installazione nel corso della sua vita nell’ambito dei dati di Building Information Modelling (BIM).

L’API di terze parti è stata inoltre progettata in modo da supportare un’interfaccia websocket che consente, per esempio, l’integrazione diretta del cloud con la comunicazione bidirezionale. Le applicazioni cloud possono in questo modo sottoscrivere le informazioni on demand, riducendo al minimo i trasferimenti dati sul cloud e i costi. L’interfaccia websocket è inoltre utilizzabile per la messaggistica, per esempio, per le notifiche della GUI sui dati modificati in modo da mostrare immediatamente le modifiche del sistema. Inutile dirlo, l’interfaccia KNX di terze parti per IoT KNX offre sicurezza allo stato dell'arte.

Con la votazione finale delle specifiche, KNX sta completando oggi l’interfaccia di terze parti di cui sopra e il relativo modello informativo KNX, accessibile anche ai membri non KNX tramite https://schema.knx.org.

Come step successivo e sulla base della bozza delle specifiche KNX già disponibili, KNX intende inoltre finalizzare le specifiche API Point IoT KNX, una soluzione che consente la comunicazione (di gruppo) di attuatori/sensori a livello di campo IPv6. Ciò permetterà di estendere le installazioni KNX a dispositivi che utilizzano altri supporto come Thread o WiFi per lo scambio dati KNX. Nel primo step, la comunicazione di gruppo sarà effettuata tramite destinatari pre-configurati (broker). Per questo, KNX prevede di completare la votazione finale delle specifiche entro un anno a partire da adesso e progetta un prototipo di ETS che consenta di configurare tavole di gruppo e sicurezza nei primi prototipi di dispositivi IoT KNX dei costruttori.

Scopri le nuove opportunità nel panorama dello sviluppo KNX grazie alle specifiche IoT KNX.