Dans cette interview exclusive avec KNXtoday, Joos Demarest, CFT & CTO de l’Association KNX, explique ce que signifie l’IdO pour la communauté KNX mondiale, comment l’Association KNX est un moteur de développement dans ce domaine, et ce que nous pouvons attendre dans l’avenir.
KNXtoday : Pour vous, qu’est-ce que l’IdO et quel est sa raison d’être ?
JD: L’Internet des objets est un monde connecté qui n’est pas limité aux appareils tels que les ordinateurs portables, tablettes et téléphones portables, mais connecté jusqu’au niveau de tout ‘objet’ imaginable sur cette planète. En termes d’automatisation, cela désigne chaque capteur et actionneur communiquant dans les habitations et dans les bâtiments. À mon avis, même avec ses toutes premières installations, KNX a toujours été capable de créer des ‘Intranets des objets’. Depuis 2007, KNX relie ces intranets à l’Internet des objets au moyen de tunnels de connexion KNXnet/IP. Aujourd’hui, avec l’IdO KNX, nous pouvons créer des moyens supplémentaires pour intégrer KNX à l’IdO.
KNXtoday : Pourquoi l’IdO est-il important pour la communauté KNX ? Que nous permet-il de faire actuellement ?
JD: L’IdO crée une situation gagnant-gagnant : KNX peut faire partie de l’IdO et lui fournir des données, et l’IdO peut transmettre des données à KNX. Dans ce dernier cas, il se peut que ces données ne soient jamais transmises à la façon KNX. Par exemple, aucun de nos membres fabricants n’investirait dans le développement de son propre service de prévisions météorologiques. Les fabricants KNX peuvent créer des stations météo fournissant des données météorologiques en temps réel mais, par exemple pour prévoir la production d’énergie sur un gestionnaire énergétique client (Customer Energy Manager, CEM) dans l’installation KNX, ils se fieraient à des services de prévisions météo existant déjà sur Internet. Ainsi le CEM connecté à KNX et à l’IdO dispose de toutes les données possibles pour optimiser la consommation d’énergie.
KNXtoday : Dans l’avenir, qu’allons-nous pouvoir faire avec l’IdO, à votre avis ?
JD: Il nous est impossible d’imaginer toutes les utilisations possibles que nous donnera l’Internet des objets, tout comme, il y a 30 ans, nous ne pouvions imaginer le potentiel d’Internet tel qu’il existe aujourd’hui. Toutefois, on peut dire que, de la même manière que l’Internet d’aujourd’hui peut utiliser toutes les données qui existent sur Internet, dans les maisons et les bâtiments, une application IdO réalisée bénéficiera du fait que son produit voisin crée des données qui peuvent être utiles dès lors qu’elles sont combinées avec ses propres données. Les services de cloud et l’intelligence artificielle pourraient créer des applications basées sur ces données, sans nécessiter que les produits installés communiquent directement les uns avec les autres, même si les fonctions basiques dans les bâtiments doivent toujours être reliées par des intégrateurs qualifiés.
KNXtoday : Quels sont les prérequis d’un système de contrôle des bâtiments qui utilise l’IdO ?
JD: Pour qu’un système de contrôle des bâtiments fasse partie de l’IdO, il doit être capable de fournir des données non pas de sa propre manière originale, mais d’une manière facilement digestible par les systèmes informatiques, c’est-à-dire les machines. Il doit être accessible par le biais de protocoles conçus par l’Internet Engineering Task Force (IETF) même si un protocole propriétaire est utilisé au sein du système de contrôle des bâtiments. Si l’on compare cela aux langues parlées, cela reviendrait à pouvoir parler une langue spécifique au sein d’un écosystème, alors que pour parler à l’IdO vous devriez parler anglais.
KNXtoday : Qu’a fait l’Association KNX pour garantir que le système KNX peut pleinement embrasser l’IdO ?
JD: KNX et ses membres ont investi lourdement dans la conception de meilleures solutions d’intégration dans l’IdO, qui sont appelées IdO KNX.
D’une part, ils ont convenu d’une API de service web RESTful indépendante des fournisseurs pour les appareils KNX classiques, appelée API tierce. Comme ce processus est maintenant standardisé, d’autres parties, même si elles ne sont pas membres KNX, peuvent désormais concevoir des clients beaucoup plus rapides qui se connectent aux serveurs API tierces de différents fabricants qui doivent, via une certification, offrir un ensemble minimum de données.
D’autre part, ils ont convenu d’offrir aux fabricants KNX plus de possibilités d’utiliser des supports de transmission conformes à Ipv6 tels que les réseaux Wi-Fi LAN ou Thread. De cette façon, une installation KNX peut toujours consister en produits KNX TP (Paire torsadée) et KNX RF (Radiofréquences) mais peut aussi inclure des appareils basés sur Thread qui parlent le langage KNX et sont configurables par ETS. Ces dispositifs sont appelés API KNX Point.
KNXtoday : Comment progresse la mise en œuvre ?
JD: Les spécifications KNX API tierce ont déjà été publiées dans une première version et certains fabricants ont déjà utilisé l’API dans des produits réels. La deuxième version est en voie d’achèvement et comprend une démonstration de faisabilité conçue par KNX. Tout est accessible aux développeurs potentiels de serveurs et de clients via schema.knx.org.
Les spécifications de l’API Point sont également dans la dernière phase de développement ; les derniers commentaires issus du vote interne sur les spécifications sont pris en compte en ce moment même. KNX est en train de concevoir, avec un sous-traitant, la première pile Open Source pour ce type de produit, qui sera également bientôt disponible pour les membres KNX.
KNXtoday : Quels développements futurs pouvons-nous attendre de l’Association KNX ?
JD: Tout ce qui est développé par KNX nécessite la prise en charge dans ETS. Pour que les passerelles API tierce offrent des données utiles et interprétables aux ‘objets’ qui accèdent aux données, il serait intéressant que les données du produit des fabricants contiennent davantage de sémantique (qui aide à comprendre la signification des données). Pour cela, KNX doit offrir aux fabricants la possibilité d’enrichir leurs données de produits à l’aide de l’outil du fabricant ETS et ces données doivent pouvoir être exportées vers les serveurs de l’API tierce.
Par ailleurs, la prise en charge des dispositifs API Point doit se faire dans ETS pour qu’un installateur puisse simplement connecter un tel dispositif à une ligne IP dans la fenêtre de topologie ETS et le configurer ou le télécharger comme tout autre appareil KNX.
KNXtoday : Pourquoi l’IdO de KNX est-il la solution incontournable ?
JD: Ce qui précède montre que KNX ne cesse jamais de développer sa technologie et travaille en continu pour améliorer ce qui existe déjà plutôt que de repartir de zéro indéfiniment. Cela présente d’énormes avantages pour tous ceux qui investissent dans KNX : une installation avec le tout premier produit EIB des années 90 pourra ensuite être étendue avec un dispositif API KNX Point. Citez-moi une autre technologie qui offre de telles possibilités !
Joost Demarest est le CFO & CTO de l’Association KNX, le créateur et le propriétaire de la technologie KNX, le standard mondial pour toutes les applications de contrôle de la maison et du bâtiment.
