Les protocoles de communication en Domotique et en GTB à Light + Building 2018

De nombreuses associations défendant un protocole de communication spécifique sont venues exposer leurs solutions à Light + Building . Voici quelques tendances et leurs dernières avancées.

Les routeurs WiFi eero créent un réseau WiFi maillé en amont et fonctionnent sur le réseau maillé IPv6 Thread en aval. ©PP

Dissocier la couche applicative

La principale tendance que nous observons, de manière croissante, dans la construction des protocoles de communication, est la dissociation entre les 6 couches de transport des données et la 7e couche, dite couche applicative ou d’application (Application Layer).

Cette 7e couche définit le sens des données transportées (données de température, position d’une vanne, ordre, acquittement, ...) et permet à l’appareil émetteur et à l’appareil récepteur de se comprendre. La dissocier des couches transport signifie que l’on peut transporter des données de différents types sur divers protocoles de communication.

Sur le stand de Thread, par exemple, un protocole de communication sans fil, IPv6, qui ne propose pas de 7e couche, Arnulf Rupp, membre du conseil d’administration du Thread Group et responsable de la standardisation chez Osram, expliquait qu’il est possible de concevoir des microprocesseurs (chips) qui embarquent Thread pour le transport des données sans fil et comportent, en quelque sorte préchargées, plusieurs couches applicatives différentes.

Lors de la configuration de l’installation, l’intégrateur activera la ou les deux couches d’application qu’il entend utiliser pour son projet précis. Pour les fabricants, cette solution signifie une seule puce parlant plusieurs langues différentes : un avantage puissant.

Voici un contrôleur de lumière Legrand particulièrement versatile. Il utilise la couche applicative OFC, WiFi et Thread pour la communication. ©PP

L’adoption de Thread progresse

Arnulf Rupp explique qu’Osram, par exemple, imagine des puces utilisant Thread pour le transport des données sur lesquelles ils pourront activer deux couches applicatives différentes : une couche « publique » et ouverte, comme Dotdot, ZigBee ou d’autres, plus leur nouvelle couche applicative propriétaire correspondant à leur nouveau service Cloud, qui sera présenté dans un prochain article.

En attendant, sur le stand Thread, plusieurs appareils utilisant Thread étaient exposés. Nest, par exemple, déploie Thread avec Weave et Open Weave, ses propres couches applicatives. Weave est la couche applicative des divers objets connectés Nest, Open Weave est compatible avec Weave, avec sans doute quelques fonctionnalités en moins, et accessible à tout fabricant.

Plusieurs industriels, dont Yale, membre du groupe Assa Abloy, pour ses serrures connectées disposent déjà de produits Thread +Weave. eero exposait des répétiteur WiFi pour l’univers domestique : WiFi en amont, BLE (Bluetooth Low Energy) et Thread en aval. Dans un logement ou un bureau, les répétiteur eero créent un réseau WiFi maillé.

Tous les objets Nest communiquent désormais entre eux en Thread qui apporte une communication TCP/IP, IPv6 (des milliards de milliards d’adresses différentes) jusqu’à chaque objet. Nest ajoute la couche applicative WEAVE au-dessus de Thread. Le groupe Assa Abloy a adopté la même architecture Thread + WEAVE pour ses serrures connectées Yale. ©PP

Une dizaine de fondeurs proposent désormais des puces et des boards pour Thread. ©PP

Legrand, Thread et Samsung SmartThings Cloud

Legrand a exposé très discrètement, un boîtier de pilotage de l’éclairage qui fonctionne simultanément avec Thread + OCF et WiFi + OCF. Notons que OCF ou Open Connectivity Foundation est une couche applicative développée par des entreprises issues de l’informatique, plutôt gourmande en puissance de traitement et donc en consommation d’électricité.

Legrand utilise la version 1.3.1 au dessus de Thread. Elle incorpore une sécurisation des données transmises. OCF est relativement populaire au Etats-Unis et s’interface sans difficulté avec les commandes vocales Alexa d’Amazon, Google Assistant et Samsung SmartThings Cloud. En octobre dernier, Samsung a annoncé la consolidation de ses différents services Cloud, dont Samsung Connect Cloud et Artik Cloud dans une seule plateforme Cloud pour l’IoT (Internet of Things ou Internet des Objets), nommée SmartThings Cloud.

Le but de SmartThings Cloud est de proposer des API pour permettre une interconnectivité par le Cloud entre des objets connectés mais qui ne sont pas prévus pour une interactivité locale, selon un mécanisme déjà expliqué dans un article du site batirama.

Samsung unifie ses différents clouds dans un seul : SmartThings Cloud, tout en préservant la compatibilité avec les différentes versions précédentes. ©Samsung

Le Cloud, le Cloud, le Cloud

On ne compte plus les plateformes Cloud à Light + Building. Chaque entreprise un peu ambitieuse développe le sien : Osram, Trilux, Sylvania, sans compter Haier, Samsung, LG, Siemens, Schneider Electric pour Wiser, Legrand bien sûr, etc. Il semble que l’interactivité de Cloud à Cloud (Cloud-to-Cloud) ait le vent en poupe. Même Sylvania pense que ce sera le prochain mode de pilotage dominant en éclairage.

Il faut naturellement que le logement ou le bureau ou l’hôtel soit doté d’une connexion internet rapide et en état de marche. Mais, tenter de faire passer l’interactivité Cloud to Cloud pour un moyen d’économiser l’énergie est une hérésie : pour allumer une lampe Philips Hue à l’aide d’un interrupteur Legrand en Cloud to Cloud, au moins deux Data Centers reçoivent, puis échangent des informations et l’un d’entre eux envoie un ordre. Sinon, l’utilisateur peut toujours se lever et appuyer sur l’interrupteur. C’est moins smart, mais tellement meilleur pour sa santé !

KNX existe depuis 25 ans, mais se réinvente régulièrement pour demeurer d’actualité. La nouvelle ambition de l’Association KNX porte naturellement sur l’IoT (internet of Things, Internet des Objets) dans le bâtiment, mais aussi sur l’IoT dans la ville pour faire partie des développements des villes intelligentes.  ©KNX

L’apparition de KNX IoT

Avec un peu plus de 25 ans d’existence, le protocole de communication KNX fait figure d’ancêtre dans la domotique et la GTB, mais il s’adapte. Face à l’IoT, avec tout son potentiel de business, sinon de services, KNX a commencé en 2016 par publier les sources des Webservices KNX, de manière à ce que les industriels puissent construire des passerelles (automates traducteurs) entre les Webservices KNX, d’une part, oBIX, OPC/UA ou BACNet, d’autre part.

Cette année, l’association KNX a dévoilé la seconde étape KNX IoT, qui n’est autre qu’une couche applicative KNX, séparée des couches de transport de données du protocole KNX. KNX a choisi Thread comme couche de transport de KNX IoT. Ce qui probablement signifie à court terme l’arrêt de la production d’appareils utilisant KNX RF, la déclinaison radio du protocole KNX, même si dans un réseau, ils demeureront accessibles à travers des passerelles entre KNX filaire ou KNX RF et KNX IoT sur Thread.

KNX s’est également associé à Fairhair alliance, un rassemblement de grands industriels mondiaux qui se propose, premièrement de favoriser le développement de réseaux TCP/IP, Thread, LoRa ou d’autres, dans le monde de l’IoT appliqué au tertiaire. Ensuite, Fairhair alliance développe tout un protocole de reconnaissance des appareils IoT sur TCP/IP entre eux, ainsi qu’une sécurisation des réseaux. Tout cela de manière à ce que des réseaux sans fil IPv6 puissent être déployés en toute sécurité dans différents types et tailles de bâtiments tertiaires.

Fairhair Alliance développe des collaborations avec BACnet, KNX, OpenAIS, Thread et ZigBee, pour faire en sorte que ces organisations adoptent ses recommandations. L’association KNX souligne qu’il faudra continuer d’utiliser l’outil ETS pour configurer une installation KNX IoT sur Thread. La vente d’ETS fournit une grosse partie du revenu de l’association qui n’est pas prête à y renoncer, même si elle ne le dit pas en ces termes.

KNX ne se lance pas sel dans l’IoT. Il a choisi Thread comme protocole de communication sans fil. Et, pour le tertiaire, s’appuie sur les travaux de la Fairhair Alliance qui développe des procédures de sécurité, ainsi que découverte et de reconnaissance des objets compatibles TCP/IP entre eux : moi, le régulateur de chauffage, je comprends qui tu es (une sonde de détection de présence, par exemple), où tu te trouves et je sais si nous pouvons utilement travailler ensemble (échanger des données). ©KNX

Voici l’architecture complexe et le programme de travail dans lesquels sont engagés de grandes organisations mondiales pour l’IoT en tertiaire soit simple, efficace et sûr. ©Fairhair Alliance