Domotique KNX en Python
Introduction
Le bux KNX est un bus domotique que l'on retrouve aussi bien dans des maisons individuelles que dans des bâtiments BBC. Il permet de faire transiter des données de toutes sortes : commandes d'ouverture/fermeture de portes / d'évents / de volets roulants, allumage/extinction de lumières ou de tout autre appareil (notamment chauffage), contrôles de température / pression / vitesse du vent / luminosité, etc.
Ce bus peut être couplé au réseau ethernet filaire RJ45 du bâtiment via une passerelle installée dans le tableau électrique du bâtiment. Dès lors, on peut configurer les capteurs et actionneurs KNX depuis un logiciel dédié, malheureusement propriétaire, et onéreux. Ce logiciel spécial permet notamment de «figer» la configuration dans les appareils, de sorte qu'une panne d'un actionneur ne perturbe pas tout le fonctionnement du bâtiment.
Contexte de départ
Mon travail a ici consisté à remplacer l'interface tactile d'une dalle KNX, installée avec un système d'exploitation propriétaire obsolète (donc dangereux puisque non maintenu côté sécurité), par une interface full web, accessible depuis n'importe quel poste informatique. Petit détail croustillant : le logiciel dédié, qui a servi à lire/écrire la configuration KNX dans les actionneurs, n'était pas présent dans la dalle. A t'il bien été livré au départ, ou enlevé par la suite par l'automaticien installateur ? Mystère... Toujours est-il que la logique de contrôle étant déjà fixée dans les appareils, le rôle de la dalle tactile se cantonnait à remonter visuellement les informations et alertes du bus, et à contrôler un certains nombre d'actionneurs clés du bâtiment.
Outre l'emplacement physique de la dalle qui rendait son exploitation délicate, l'interface du logiciel tactile était sommaire, tant sur le nombre d'actionneurs supportés que sur l'ergonomie générale. C'est d'ailleurs un des points communs que j'ai pu observé sur d'autres installations KNX en fonctionnement : l'ergonomie des réalisations laisse bien souvent à désirer. Le web offre quand même aujourd'hui des outils visuels plus pointus et plus souples, et vu les coûts d'automatisation, on s'attendrait logiquement à pouvoir contrôler tout de suite les actionneurs depuis un ordinateur ou un smartphone... C'est désormais chose possible avec mon outil.
Programmation web
Il a fallut dans un premier temps analyser le fonctionnement du bus, trouver un outil libre sous GNU/Linux qui permette une remontée d'information efficace et robuste, et se greffer dessus.
Ma première version, écrite en PHP/JS/HTML5/CSS3, permettait déjà aux usagers d'accéder aux informations et de contrôler les actionneurs publics du bâtiment, en traçant les actions des usagers, cette dernière condition étant bien entendu indispensable pour éviter qu'un usager n'aille s'amuser avec les actionneurs d'un autre bureau que le sien...
Côté interface client, j'ai opté pour JQuery et le Bootstrap classique, afin d'imposer dès le départ une interface en responsive design, indépendante de la taille du périphérique client utilisé. Mais si cette première version a permis de valider un «proof of concept» fonctionnel, elle s'est avérée rapidement trop limitée...
En effet, le cahier des charges imposait de surveiller les événements KNX entrants, et de les distribuer en temps réel aux clients web connectés, ce qui imposait de fait une programmation multithread que seul Python, en haut niveau, était capable d'assumer pleinement.
En outre, Python3 a apporté plusieurs changements majeurs qui le rendaient autrement plus intéressant que PHP. Je ne vais pas vous en dresser la liste, mais j'en citerai deux qui me paraissent équivoques. D'abord Python3 impose désormais l'UTF-8 par défaut, ce que PHP6 n'a pas été capable de faire. Ensuite Python3 n'accepte plus que des données binaires dans ses sockets, ce qui supprime de fait bon nombre d'erreurs à la con en phase de développement... Bref, on voit que Python évolue dans une direction logique et pérenne, là où PHP a bien du mal à quitter son mode client/serveur historique.
Enfin, j'avais déjà écrit une librairie WebSocket pour Python2 il y a quelques années, et j'en ai logiquement profité pour la faire évoluer vers Python3, régler quelques bugs, ajouter des fonctionnalités (prise en charge de wss://), etc.
Le plus gros travail a été de traduire les librairies PHP de prise en charge des trames KNX vers Python3. Il a fallut découper le code d'origine pour le rendre plus modulaire, histoire de simplifier aussi la maintenance future. Une autre difficulté classique en programmation multithread est de pouvoir retracer exactement les erreurs dans leur contexte. Et avoir un code modulaire offre largement plus de facilité dans ce sens...
Paradoxalement, la seule faiblesse gênante de Python a été l'accès à la base de données MySQL sous-jacente, de sorte que j'ai fini par extraire et traduire la base SQL directement en Javascript/AJAX. En effet, le module Python3 utilisé fonctionne en ORM, ce qui est certes un avantage dans les projets Python purs, mais devient un inconvénient quand on doit envoyer les données en texte sur les clients via les WebSockets : il faut alors convertir les objets en texte, ce qui occasionne beaucoup de temps perdu pour rien...
Résumé de l'architecture
Serveur GNU/Linux
-----------------
[Logiciel externe] [Thread 1] [Thread 3] [Thread 4]
Capte les événements <---> Boucle qui prend les <---> Boucle qui dépile <---> Serveur WebSocket
KNX en temps réel événements et les place les événements et qui enregistre les
et les transmet au dans une pile les envoie en WS clients, réceptionne
programme principal. ou envoie les données
^
|
v
Clients web
-----------
[Connectés au thread 4]
Recoivent et affichent
les données / Envoient
les demandes sur les
actionneurs.
Résultats
Pour des raisons de confidentialité, les captures suivantes ont été anonymisées, mais permettent de se rendre compte de ce que le client final a comme type d'interface.
Conclusion
Mon expérience du bux KNX me permet désormais de proposer des solutions innovantes et des interfaces riches aux installations existantes, moyennant aussi certaines réserves : je ne suis pas automaticien de profession non plus !
Il n'en reste pas moins qu'entre la dalle tactile de départ, très limitée, mal située, et sans aucune évolutivité possible, le passage à une interface full web offre quand même un large confort aux usagers, et permet d'intégrer bien plus pratiquement les outils domotiques du bâtiment, tout en sachant toujours qui fait quoi, et en s'assurant qu'un usager X ne puisse ouvrir les portes auxquelles il n'est pas censé avoir accès. En outre, nous avons intégré la caméra d'accueil dans l'interface web de l'outil, ce qui permet désormais aux salariés d'ouvrir la porte d'entrée depuis leurs bureaux respectifs !
Il n'en reste pas moins que la sécurité est sans aucun doute le talon d'achille du protocole KNX, car trop simple à craquer de mon point de vue. Il faut bien comprendre qu'entre la domotique d'une maison et celle d'une installation industrielle multi-utilisateurs, les contraintes de sécurité ne sont pas du tout les mêmes. Et là, le problème fondamental du KNX, c'est que les actionneurs sont eux-mêmes minimalistes dans les fonctions supportées, et ce malgré leur prix d'achat souvent élevé, de sorte qu'il n'est pas possible de sécuriser une installation KNX comme on sécuriserait par exemple l'accès à des partages réseaux informatiques.
On passera également sur certains logiciels d'accès, qui cryptent les données des badges, mais laissent passer les commandes d'ouverture des portes en clair sur le bus... On sent bien que globalement, la domotique reste quand même un milieu de bricoleurs, assez éloigné des contraintes informatiques réelles d'un système d'information moderne. L'automaticien reste avant tout un électricien spécialisé, et non un informaticien.
Un autre raté des logiciels KNX est qu'ils ne proposent qu'un simple champ texte limité en taille pour décrire un actionneur et sa localisation. Cette taille oblige de fait l'automaticien à s'inventer un code maison pour pouvoir retrouver ses petits, ce qui ne serait pas un mal s'il laissait ensuite une trace du code utilisé... De mon côté, cela s'est traduit par un véritable jeu de piste chronophage, à retrouver où se trouvait exactement l'actionneur XYZ dans le bâtiment, et là, vous ne pouvez jamais être certain d'avoir fait complètement le tour.
Vu les coûts d'une intégration domotique, on s'attendrait quand même, de la part d'un professionnel sérieux, d'avoir à minima un schéma, même manuscrit, avec la position précise et l'adresse/le type KNX de chaque actionneur dans le bâtiment. Dans mes installations serveurs en clientèle, j'ai moi-même pour habitude de laisser au client un document complet reprenant tous les éléments d'administration de sa structure, ce qui devrait être, de mon point de vue, une obligation juridique.
N'hésitez pas à me contacter pour tout renseignement ou projet d'intégration KNX.