Bonjour,

Je viens de commencer le développement d'un framework pour le bus domotique KNX, et j'aimerais avoir votre aide concernant l'architecture.

Dans ce premier message, je vais me contenter de décrire un peu le fonctionnement du bus KNX, histoire que vous compreniez de quoi je cause J'exposerai ensuite ce que je cherche à faire, et les points sur lesquels j'aimerais avoir vos lumières.

Le bus KNX n'est pas un bus propriétaire, mais est le fruit d'un regroupement de plusieurs constructeurs (quelques centaines, je crois). Il n'est pas super connu en France, mais très utilisé en Allemagne, surtout dans le tertiaire, étant donné son coût (et sa fiabilité). Il existe une association KNX, qui gère tout ça.

Techniquement parlant, c'est un bus où l'intelligence est répartie entre les différents participants (bouton, détecteur, actionneur...), ce qui le rend très robuste : la perte d'un participant n'empèche pas le reste de l'installation de fonctionner ; seule la fonctionnalité associé à ce participant sera perdue.

Chaque participant peut envoyer une valeur sur le bus lorsqu'un événement externe survient (bouton), ou inter-agir avec l'environnement lorsqu'une certaine valeur est reçue sur le bus (actionneur). En fait, les participant disposent d'un certain nombre d'objets de communication qui vont lire/écrire sur le bus. Par exemple, un bouton simple peut avoir les objets de communication suivants :

- appui court toggle
- appui long off
- led d'état

Déjà, on comprend qu'il y a des objets qui vont écrire sur le bus (appuis), et d'autres qui vont réagir aux données du bus (led d'état). La complexité des objets de communication dépend des participants, et suivant les constructeurs, on peut avoir des choses très touffues. En plus, les objets de communication disponibles sont aussi fonction de la configuration du participant ; certains permettent de faire beaucoup de choses différentes, juste en les paramétrant, ou en changeant le firmware.

Prenons un autre exemple de participant, un actionneur (simple relais) :

- activation sortie
- état sortie

Ici, "activation sortie" est un objet qui va permettre de changer l'état du relais en fonction d'une valeur reçue sur le bus. L'objet "état sortie", lui, reflète l'état du relais, et va écrire sur le bus lorsque celui-ci changera. C'est utile lorsqu'on peut modifier l'état du relais par un bouton manuel directement sur l'actionneur.

L'association KNX a développé un gros logiciel, ETS, qui permet de programmer tout ce beau monde et faire en sorte que ça fonctionne comme on le souhaite. L'idée va être de lier les différents objets de communication entre eux, pour arriver au fonctionnement souhaité. Pour faire cette liaison, on définie des "Groupes d'Addresses" (GA dans le jargon). Par exemple, on va définir une GA "lumière couloir", dans laquelle on va lier l'objet "appui court toggle" de notre bouton et "activation sortie" de notre actionneur. Le relais de cet actionneur étant bien sûr connecté à la lumière du couloir.

Une fois les participants programmés (via ETS), ils fonctionnent en autonome : si j'appuie sur le bouton, celui-ci va émettre sur le bus la GA "lumière couloir" et la valeur valeur (0 ou 1 suivant l'état précédent, puisque c'est un toggle). Notre actionneur va voir arriver cette GA, et va changer l'état de son relais en fonction de la valeur associée à cette GA.

La beauté du truc, c'est qu'on peut programmer plusieurs boutons qui vont émettre une valeur sur cette GA, ce qui permet de réaliser des va-et-vient avec autant de points que l'on souhaite. Et si l'un des boutons ne marche plus, les autres continuent, eux, de fonctionner (sauf grosse défaillance du bus, bien sûr).

On a vu que notre bouton avait aussi une petite led. Ce serait intéressant de faire en sorte qu'elle reflète l'état réel de notre lumière. C'est très simple : l'objet de communication qui permet de changer l'état de la led fonctionne exactement comme l'objet "activation sortie" de l'actionneur. Il suffit donc de lier cet objet "led d'état" à l'objet "état sortie" de l'actionneur, comme on l'a fait pour le bouton et le relais. Pour ça, on créé une autre GA "état lumière couloir", qu'on associe à nos 2 objets. Et voilà ! Que l'on change l'état du relais via l'appui sur un bouton, ou directement sur l'actionneur lui-même, une GA sera émise avec l'état réel du relais, et la led changera d'état en fonction.

Dernier exemple : le bouton a un objet "appui long off". Si on lie cet objet de communication à une GA "tout éteindre", dans laquelle on va également lier l'objet "activation sortie" de plusieurs actionneurs, il sera alors possible, par un simple appui long sur le bouton, d'éteindre toutes les lumières. Le bouton forçant cette fois la valeur off sur cette GA, les lumières déjà éteintes ne vont bien sûr pas se rallumer.

Voili en gros comment ça marche. Il y a bien sûr des siouxeries, des choses plus complexes, mais le coeur du métier est là. J'ai juste omis de dire qu'il n'est possible de lier entre eux que des objets de communication de même type (bit, integer, float). Logique.

Certains constructeurs proposent des participants très complexes, aux fonctionalités vraiment impressionantes, même pour simple bouton. Ceux-ci peuvent en effet avoir plusieurs touches, des leds, et même des capteurs de température, associé à une logique de type thermostat ! J'en ai chez moi, et c'est vraiment cool de pouvoir réguler le chauffage dans chaque pièce via le bouton. Ces boutons ont des objets de communication qui vont permettre de changer la consigne, et de piloter des participants de type relais. Il en existe même avec des petits affichages, eux aussi pilotables, toujours via le même principe d'association d'objets de communications via les GA.

Au dessus de tout ça, on trouve aussi des supervisions. C'est là que ça devient intéressant ! Il existe tout un tas de choses, de modules hard+firmware à des choses purement logicielles. Et il existe des projets libres, comme les très connus eibd/linknx/knxweb. linknx s'appuie sur eibd, un démon qui dialogue directement sur le bus (via diverse types de passerelles). Il est développé en C++, et permet d'écrire des rules qui vont réagir suivant l'activité du bus. Dans linknx, on décrit toutes les GA. knxweb, lui, s'appuie sur linknx, et propose une visu web. Il est développé en php/javascript.

L'équipe linknx/knxweb (francophone) a aussi proposé à la vente une box avec tout pré-installé (plus d'autres ervices, comme Asterisk). La box tourne sur une carte ALIX, sous voyage linux.

Il existe également un gros framework java, Calimero, développé par des allemands. C'est surtout de ce projet que je m'inspire, car il est vraiment très puissant. Ils ont poussé très loin le niveau d'abstraction, pour essayer de coller à toutes les spécifications du bus. Et elles sont plutôt complexes ! Du coup, ça le rend assez lourd, pas forcément facile à utiliser.

Voilà pour les généralités. Dans mon prochain post, je décrirai ce que je souhaite faire, et poserai des questions plus précises sur certains points. Si vous avez des questions sur ce bus, n'hésitez pas.

Merci de m'avoir lu