J’ai reçu coup sur coup plusieurs messages de visiteurs de ce blog me demandant plus de détails sur l’architecture logicielle de mon installation domotique. Effectivement j’ai plusieurs fois raconté ma life ici même en donnant des explications sur tel ou tel élément de mon installation mais je n’ai jamais donné de vision un peu globale de l’usine à gaz du système.

Je vais donc essayer de remédier à cette lacune en donnant quelques explications sur la partie logicielle, et comme je ne recule devant aucun sacrifice, j’ai même sorti ma plus belle souris pour faire un schéma global, dont je détaille en dessous les différents éléments.

 

 

 

 

1 – xPL Software Gateways

 Il s’agit de tous les agents xPL permettant de s’interfacer avec du ‘logiciel’. Par exemple :

  • xpl-rrd pour archiver les données des sensors dans des Round Robbin Databases et permettre de graphage
  • xpl-pushmsg pour permettre d’envoyer des notifications à mes appareils mobiles sous iOS ou Android
  • xpl-sendmail pour envoyer des mails
  • xpl-dawndusk pour notifier du lever/coucher du soleil

2 – xPL Hardware Gateways

 Tout comme ceux ci-dessus, il s’agit d’agents xPL mais qui permettent de s’interfacer avec des appareils/des devices. Par exemple pour ceux que j’utilise :

  • CidModem (from domogik) : communique avec un modem 56K USB branché sur ma ligne téléphonique pour détecter les appels entrants et numéro d’appelant sur mon téléphone fixe
  • xpl-currentcost : communique avec un CurrentCost ENVY pour remonter sur mon réseau xPL la consommation électrique instantanée de mon habitat
  • xpl-rfxcomrx/tx : ces deux agents (le RX pour la réception et le TX pour la transmission) communiquent avec les célèbres RFXCom. Cela permet à mon installation domotique de ‘parler’ un certain nombre de protocoles RF de domotique (notamment X10, HomeEasy/Chacon, sensors Oregon Scientific, etc…)
  • xpl-zibase : cet agent communique avec la ZiBase, et permet à celle-ci de ‘parler’ le xPL. En ce qui me concerne cela m’offre la possibilité entre autres d’intégrer des appareils X2D (protocole de domotique du fabricant DeltaDore) à mon installation, comme par exemple mes modules de contrôle de chauffage sur fil pilote
  • xpl-apcups : cet agent permet d’interfacer un onduleur APC sur le réseau xPL, et donc de reçevoir les évennements liés aux interruptions d’alimentation électrique et à la durée restante sur batterie.
  • NabazTag : cet agent permet comme son nom l’indique de communiquer avec les Nabaztag (mais vu l’actualité peu réjouissante de ces lapins je ne m’étendrai pas sur le sujet dans ce billet ;) )

 

3 – xPL-enabled Devices

Il n’y en a pas beaucoup mais il y en a quand même : certains appareils sont conçus pour parler nativement le xPL. C’est notamment le cas des SqueezeBox de Logitech, grâce au plugin xAP : cela permet de gérer toute la diffusion audio dans la maison, avec plusieurs SqueezeBoxes, etc…

Un autre appareil récemment  sorti qui supporte nativement le xPL est le nouveau RFXCom v3, mais je n’en ai pas, mes RFXCom sont des modèles anciens en USB.

 

4 – HomeGuru Server

Là ça se complique un peu car ça devient vraiment custom ;) .

Il s’agit du cœur du système de domotique, de l’équivalent du xPLHAL pour ceux qui connaissent. C’est cet élément qui va par exemple :

  • connaitre la liste de tous les devices de mon installation domotique
  • centraliser les évennements xPL, et y réagir
  • lancer des actions en fonction d’un certain nombre de critères, etc…
  • plus globalement c’est le « cerveau » de l’installation domotique, c’est lui qui embarque l’intelligence

Je l’avais appelé à l’époque HomeGuru, et c’est le nom qu’a gardé ce petit soft depuis plusieurs années chez moi.

Techniquement, il s’agit d’un agent xPL au même titre que les autres agents que j’ai développés. Il est d’ailleurs également écrit en perl, utilisant le framework xpl-perl. Par contre il est plus compliqué que les simples gateway xPLs, car il prend en charge :

  • Une partie base de données : la liste des devices, leur configuration est stockée dans une base de données MySQL
  • Une partie ‘moteur de règles’ : c’est ce qui permet de lancer des actions suivant des déclencheurs et des conditions, avec des opérateurs logiques (ex: Quand TRIGGER1 est levé, lancer l’action ACTION1 SI CONDITON1 ET CONDITION2 sont réunies)
  • Une partie WebService : HomeGuru Server expose un petit webservice ‘REST’ pour que d’autre éléments (Cf parties 5 et 6) viennent interagir avec le système. C’est via ce webservice que la TOTALITE de la configuration est faite, en effet, HomeGuru Server en lui-même ne dispose pas d’une quelconque interface graphique (GUI) ou en ligne de commande (CLI).
  • Une partie scheduler : qui permet de lancer des actions suivant des dates et timers
  • Toute l’intelligence du système : types de devices, actionneurs, capteurs, sécurité…
  • La communication avec d’autres ‘univers’ qui ne se pluggent pas bien avec du xPL : par exemple pour ma part : les cameras de surveillance IP

 

5 – Mobile App / Webapp

Ici c’est en fait l’interface de commande « end user » du système domotique. C’est cette interface qui permet de consulter  l’état des modules domotiques, de les actionner, de voir les capteurs, les graphiques de températures ou de consommation électrique, les cameras en temps réel, etc…

 

 

 

 En terme de technos, il s’agit à la base d’une WebApp pour mobiles écrite en utilisant le framework HTML5/JS « Sencha Touch« , ce qui la rend compatible avec les devices iOS et Android; mais aussi avec le navigateur Safari pour Windows par exemple.

Au fur et à mesure de l’utilisation j’ai fini par implémenter carrement sous forme d’application via ‘PhoneGap‘, qui permet de transformer une webapp en application pour Android ou iOS (ou même d’autres OS mobiles, 6 en tout). Cela permet d’être plus réactif, et d’éviter la problématique de l’hébergement de la WebApp.

Last but not least, comme vu au dessus, cette WebApp interagit avec le HomeGuru Server (et uniquement avec le HomeGuru Server) via le WebService REST exposé par celui-ci.

 

6 – Configuration Website

Pour finir, il s’agit de l’interface de configuration/administration du système domotique. Il permet par exemple de :

  • Ajouter un device/appareil
  • Configurer le moteur de règle des évènements via des Triggers, Conditions et Actions
  • Configurer la partie ‘sécurité’ (dev in progres…)
  • Voir les logs du réseau xPL

En techno, il s’agit ici encore d’un site web écrit en utilisant le framework Sencha Ext JS. Pour ceux qui connaissent, cela le fait ressembler à une application classique.

Ici aussi, le site d’administration communique avec le HomeGuru Server (et seulement avec lui), en utilisant le WebService REST exposé.

 

7 – Autres éléments utilisés

On trouve aussi d’autres éléments logiciels utilisés indirectement dans le système :

  • Openjabnab : Pour remplacer les defunts serveurs Nabaztag
  • SqueezeCenter : le logiciel serveur (gratuit) des SqueezeBox de Logitech
  • ZoneMinder : le logiciel pour centraliser toute la partie caméras de surveillance
  • MythTV (partie backend) pour la distribution video de la TV par satellite notamment
  • XBMC : le frontend pour la video et la TV
  • …d’autres que j’oublie ?…

 

 

Et voila pour le petit tour d’horizon de la partie logicielle. Comme d’habitude n’hésitez pas à me poser vos questions, j’essayerai d’y répondre du mieux que je peux, et le plus vite possible (enfin… le moins lentement possible…).

A venir, probablement d’autres article détaillant certains points (dites moi si vous avez une partie préferée).

J’entends d’ici (oui oui j’ai l’ouïe super développée) certains dire « ok c’est bien beau tout ça mais quand est ce que tu nous met à dispo tes développements ? » Et bien je l’espère assez rapidement pour les 3 éléments que je n’ai pas encore publiés :

  • Le HomeGuru Server, coeur du système
  • La WebApp Mobile
  • Le site de configuration