Un des principes de la domotique est (selon moi en tout cas) de réussir à faire communiquer différents objets de la vie courante entre eux, pour rendre le tout plus intelligent, plus contrôlable, plus extensible.

Partant de ce principe, une des difficultés auxquelles on se retrouve vite confronté est la multitude de technologies différentes à interconnecter entre elles, au sein d’un seul et unique système domotique. On peut en effet se retrouver très vite avec par exemple :

  • Des capteurs Oregon Scientific pour les données environnementales
  • Un système X10 courant porteur pour la commande des appareils electriques de la maison
  • Du X10 RF (sans fil) pour tout ce qui est télécommandes, détecteurs de mouvements…
  • Une console CC128 pour le controle de la consommation électrique
  • Un media center- Des capteurs 1wire
  • Plein d’autres choses….

En considérant que l’on est capables d’utiliser toutes ces technologies, mais qu’elles n’ont d’intéret que si elles sont utilisées ensemble, il nous faut un moyen de féderer tout ça, de faire converger toutes ces informations pour que l’on puisse ensuites les utiliser dans un système domotique, sans avoir à descendre dans les détails d’implémentation de chaque technologie. Il nous faut…. le xPL ! ;)

Le Protocole xPL

Un protocole créé en 2003 et appellé xPL (eXtremely simPle protocoL : tout un programme ;) ) se propose justement de féderer le controle et le monitoring de tous les équipements de la maison au sein d’un même mode de communication.
Il s’agit d’un protocole qui se veut très simple (réseau IP classique, du XML et c’est tout), tout en incorporant des possibilités d’auto-configuration et d’auto-découverte très intéressantes, surtout quand on bidouille pas mal dans le domaine de la domotique.

Comment ça marche

Tout d’abord ma spécialité : un schéma de principe moche ;)

Schéma de principe d'un réseau xPL

Chaque patate sur ce schéma est une application autonome. Elle est dans la majorité des cas sur un ordinateur de la maison, mais peut être carrément embarquée dans des équipements.

Les applications ‘interfaces’ Gateways : Il s’agit des applications qui font le lien entre les différentes technologies et le protocole xPL. Ce sont ces applications qui connaissent les détails d’implémentations des différentes technos. Par exemple on trouvera des Gateways pour :

  • X10 (qui se connecte alors à l’interface CM11 par exemple)
  • RFXCom (qui se connecte au produit du même nom, et permet alors de s’interfacer avec toutes les tecnologies que le RFXCom connait)
  • CurrentCost (qui se connecte à la console ENVI pour mesurer les consommations d’électricité de votre maison)
  • SMS (qui permet d’envoyer des SMS)
  • 1wire (qui permet de communiquer avec toute la gamme de capteurs 1Wire)
  • ZWave (pour communiquer avec la gamme d’automatismes ZWave)
  • …. et plein d’autres…

Les applications de stats et de monitoring : Ce sont des applications qui ne font que reçevoir des informations, elles n’émettent rien. On pourra par exemple enregistrer tous les changements d’états des automatismes de la maison dans une base MySQL, ou encore enregistrer les données provenant de différents capteurs dans des bases RRD (Round Robin Database) pour ensuite génerer des graphes.

Les applications de contrôle : Il s’agit des applications qui contiennent l’intelligence et toute la logique du système domotique : Ce sont par exemple ces applications qui vont décider d’éteindre la lumière lorsqu’il fait jour, ou bien de baisser le chauffage lorsque votre logement est vide. Elles reçoivent toutes les données en provanance des applications gateways par le protocole xPL, et émettent leurs ordres vers ces mêmes gateways, toujours en utilisant le protocole xPL.

Le HUB : Comme son nom l’indique c’est un élément indispensable d’un réseau xPL. La présence d’un HUB est obligatoire sur chacun des ordinateurs faisant tourner une ou plusieurs applications xPL. Le HUB ne contient aucune intelligence de contrôle, mais lui qui sera chargé de l’acheminement des messages xPL vers leur application destinataire.

Techniquement :

Les transmissions du protocole xPL se font en Broadcast UDP. Les applications émettent elles-même leurs messages sur le réseau, et le HUB répartit ensuite les messages à leurs destinataires.
Dans le principe de fonctionnement, TOUTES les applications reçoivent TOUS les messages, y compris ceux qu’elles ont elles-même envoyé.
Le HUB maintient une liste des applications qui lui sont connectées : Dès qu’il recoit un message, il enregistre l’application dans sa liste.

Portabilité

C’est également là toute la puissance d’un protocole ouvert et simple : il existe des applications xPL pour tous les OS les plus utilisés : Windows, Linux, MacOS. Vous pouvez donc avoir des ordinateurs sous différents OS dans un même réseau xPL, ceux-ci se comprendront très bien.
Il existe notamment des toolkit pour les languages C, perl et java ce qui assure un bonne base d’interopérabilité.

Et dans la réalité alors ?

Je commence juste à explorer les possibilités de ce protocole, mais, lorsque l’on construit son propre système domotique, en développant ses propres modules, ce protocole est très utile car il permet de tout centraliser simplement et sans perdre de temps.
De nombreuses applications existent déjà (certains sont stables et d’autres moins ceci dit) et m’ont permis de mettre la majorité de mes équipements domotique sur le réseau xPL sans trop de difficulté :

  • Tous mes capteurs environnementaux (température + hygro) Oregon Scientific via le récepteur RFXCom
  • La consommation électrique de mon logement avec la console CurrentCost Envi
  • Les automatismes via une interface CM11 pour le X10
  • Les commandes X10 sans fil (télécommandes et détecteurs de mouvements) via le RFXCom

Le tout grâce à la suite logicielle xpl-perl de Mark Hindess qui contient tous les composants necessaires, et sous Linux évidemment (ubuntu karmic pour être précis)

La première chose que j’ai faite c’est de configurer le module pour archiver les données des capteurs dans une base RRD, ce qui permet facilement ensuite de produire des graphes de tous les capteurs de système (et quelle que soit leur technologie => xPL power). Par exemple, les temperatures et la consommation electrique :

Par contre clairement il y a eu un peu de bidouille pour que tout marche bien. Exemples de petites déconvenues necessitant bidouille :

  • Le module CurrentCost semble remonter des indicateurs en Ampères (alors que je voulais grapher des Watts) => Opérations à faire sur la valeur au niveau du graphage
  • L’inteface X10 CM15A (ou CM15 Pro) n’est actuellement pas supportée les applications xPL existantes. Du coup je suis en train d’en écrire une en me basant sur les travaux déjà faits sur le fonctionnement de cette interface sous linux (http://www.linuxha.com/USB/cm15a.html)
  • Les bases RRD créées automatiquement n’étaient pas assez détaillées par rapport à ce que je voulais => modification à faire dans les fichiers RRD (via rrdresize pour agrandir le nombre d’échantillons conservés dans chaque RRA)
  • Le système de lancement automatique des différentes applications livrées dans le package xpl-perl ne fonctionnait pas sous karmic (ou alors j’ai pas réussi à le faire fonctionner) du coup j’ai juste fait un simple script d’init classique)

Voilou pour les premières armes sur xPL. Je donnerai probablement des nouvelles bientot (notamment pour le module CM15A).

Quelques liens à visiter