Suite au billet posté ici en septembre expliquant un peu l’architecture logicielle de mon installation, j’avais eu des commentaires fort sympathiques dans le billet et des mails demandant plus de détails sur le cœur du système de contrôle ainsi que l’application mobile correspondante. Voici donc la suite avec des demos des deux applications/webapp du système.

Depuis plusieurs années que je développe ce système pour mes propres besoins, je l’avais appelé ‘HomeGuru’ sans trop réfléchir (pas mon genre de réfléchir de tt de façon :p)… Et bien on peut oublier le nom J’ai regardé rapidement l’autre jour et il s’avère que ce nom existe déjà, notamment sur l’App Store Apple où il existe une application qui s’appelle HomeGuru (une application de contrôle domotique Insteon d’ailleurs ).

Bref,  hier j’ai renommé mon ensemble logiciel en : ImperiHome (oui ok c’est pas forcément mieux mais bon c’est pas bien grave, l’idée c’est d’éviter les confusions lorsque le code sera rendu public )

Alors, pour rappel, il y a, actuellement (en dehors des agents xPL) 3 composants à ImperiHome :

• ImperiHome Server : le daemon de contrôle domotique, le coeur/intelligence du système (techno : programme perl utilisant le framework xpl-perl).
• L’application mobile (la webapp) : c’est l’interface utilisateur du système, celle qui permet de contrôler les lumières, de voir les consommations, les températures, les cameras… Elle est utilisée sur smartphone ou sur tablette (techno : webapp en Sencha Touch + Sencha Touch Charts; convertion en application mobile avec PhoneGap, utilisable avec un browser type Safari/Chrome).
• Le site de configuration qui permet d’administrer le tout, créer les devices, les scenarios, etc… (techno : site web en Sencha Ext JS 3, utilisable avec un browser classique FireFox et cie…).

Pour continuer à donner plus de détails, le plus simple est que vous puissiez essayer vous-même. J’ai donc mis à disposition une demo de la webapp et du site de configuration, les deux alimentées avec des données factices et aléatoires (ne vous étonnez pas de températures étranges pour la saison ou des consommations d’énergie cheulou ).

WebApp Mobile		Site de configuration
http://demo.imperihome.com/webapp/		http://demo.imperihome.com/admin/Vous pouvez naviguer dans toute l’interface de configuration, il y a des données un peu partout pour faire la demo. Par contre c’est de la lecture seule, vous ne pourrez rien créer/modifier.
Sur un ordinateur de bureau: y aller de préférence avec le browser Safari (ça ne marchera pas avec Firefox ou IE). Possible que ça marche avec Chrome mais pas essayé. Sur un mobile : ça fonctionne bien avec les browsers standard Android et iOS. Vous pouvez utiliser le flashcode . Si vous n’avez pas un mobile très récent et que ça rame vous pouvez désactiver les animations dans les settings puis revenir à l’onglet Home et recharger l’application.		Y aller avec un browser classique mais récent type FireFox, IE…

Voila, comme ça, ça donne une idée de ce à quoi ça ressemble en vrai et de la façon dont ça s’utilise en attendant que tout le code soit mis à disposition. Dans l’application mobile vous pouvez cliquer sur les valeurs des sondes ou des consos d’énergie pour voir les graphes correspondants.

Avant de rentre tout le code (enfin celui du serveur surtout) public je dois passer un peu de temps à rendre les choses ‘présentables’, à packager correctement, à virer les cas particuliers et les trucs en dur dans le code, mais ça va venir Idem pour les specs du webservice qui sert à communiquer avec le serveur : ça ressemble (volontairement) un peu à ce qui existe sur domogik, mais je dois faire un effort de documentation .

Comme d’hab, n’hésitez pas pour les remarques positives ou négatives (bon soyez indulgents quand même hein, le tout n’est évidemment pas exempt de bugs, et est d’une façon générale très incomplet car en permanente construction).

Bref tout ça m’avait refroidit.

C’est en lisant une discussion sur le forum TouteLaDomotique que j’ai vu un des membres (titi_oft) expliquer comment il souhaitait fait pour remplacer le couteux couple RFXMeter + RFXPulse.

Il s’agissait en fait de relier le compteur à impulsions à un simple détecteur d’ouverture Chacon désossé. En effet le détecteur d’ouverture Chacon est un détecteur magnétique qui utilise une technologie dit à ampoule REED, ce qui est également le cas de mon compteur d’eau à impulsion. C’est un peu à la ‘bricolo bricolette’, mais ça a le mérte de fonctionner et de diviser le budget par 2 Voici comment procéder :

Le matériel :

• Un compteur d’eau à impulsion (1 impulsion/litre) : 75€ environ (chez planete-domotique par exemple)
• Un  capteur d’ouverture Chacon  : 15€ environ (lien chez planete-domotique)
• Un récepteur compatible avec Chacon (RFXCom, ZiBase…)
• Un fer à souder, de l’étain, des mains (deux devraient suffire) et un tournevis

Le compteur d’eau :

Le compteur est livré dans un carton, avec ses accessoires (adaptateurs, joints, et cable). Je ne suis pas plombier, mais le tout semble de très bonne qualité.

Modification du détecteur d’ouverture :

Bon ça c’est le détecteur Chacon. Vous pouvez jeter la plus petite partie, elle ne contient qu’un aimant et vous sera inutile. Il faut alors ouvrir la partie la plus grande en dévissant la vis  au dos puis en déclipsant le plastique  :

Ca vous donne à peu près ça. Vous pouvez voir l’emplacement de la pile à gauche, l’antenne à droite, et la fameuse ampoule REED en bas :

C’est aux bornes de cette ampoule reed que nous allons souder les deux fils de notre compteur à impulsion. Il ne restera ensuite plus qu’à retirer l’ampoule reed en sectionnant ses pattes, et à replacer la carte électronique dans son boitier :

Et voila ! Vous refermez le boitier, mettez la pile, et votre détecteur chacon émettra à chaque litre d’eau consommé; le tout pour moins de 100€. Elle est pas belle la vie ?

Le comptage du volume d’eau :

Attention il y a une subtilité. Comme vous le savez peut etre, les détecteurs chacon (comme les detecteurs X10 d’ailleurs) ont une facheuse tendance à envoyer plusieurs fois d’affilée leurs ordres, afin de s’assurer que ceux-ci sont bien reçus. Ce qui fait que, dans notre montage, si on compte simplement le nombre de « ON » envoyés, on va se retrouver avec un chiffre bien au dessus de la consommation réelle.

L’astuce consiste, au lieu de compter les « ON », à compter les changements d’état « OFF » => « ON ». En utilisant cette méthode, on obtient une très bonne précision (chez moi, le taux d’erreur est d’environ 0.3%, ce qui est plus que satisfaisant). Personnellement j’ai juste fait un petit agent xPL qui écoute les ordres du capteur et les retransmet sur le réseau xPL un fois convertis en données de volume.

Les limites et les inconnues :

• Durée de vie de la pile du détecteur Chacon : je ne sais pas dire combien de temps tiendra la pile bouton du détecteur. Ces petits modules n’étant pas faits pour émettre plusieurs centaines de fois par jour. Pour le moment je suis à environ 8000L consommés et pas de problème.
• Occupation de la fréquence : Il est possible que, lorsque l’on consomme beaucoup d’eau (ex. une bonne grosse douche, ou arrosage jardin…) le détecteur émette des ordre à un rythme élevé, ce qui pourrait ‘occuper’ la fréquence 433Mhz et provoquer des ratés sur d’autres devices (par exemple non-réception d’une trame d’une sonde Oregon ou autre…). Je n’ai pas constaté ce problème pour le moment mais c’est une éventualité.

Voila, c’est clairement un peu bricolo bricolette mais ça fonctionne plutôt bien jusqu’à présent après 1 mois d’utilisation . J’en profite pour remercier titi_oft du forum TLD pour son idée !

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

La plupart de ceux qui lisent ce blog connaissent déjà, de nom au moins, la ZiBase : le contrôleur domotique de la société française Zodianet. Cette ZiBase est capable de parler plusieurs protocoles liés à la domotique : le X10 RF, le HomeEasy/Chacon, le Visonic, et même, plus récemment, le X2D (c’est le protocole utilisé par les produits Delta Dore ce qui ouvre la ZiBase à une gamme très large de produits déjà largement distribués) !

Ayant des modules Delta Dore pour le contrôle par fil pilote de mon chauffage électrique, l’ajout du support du X2D est ce qui m’a fait franchir le pas pour acquérir cette fameuse ZiBase .

Ceux qui ont déjà lu les quelques autres articles de ce blog savent comment cela devait se finir chez moi : par la réalisation d’un module xPL permettant d’interfacer la ZiBase sur mon réseau xPL.

Voici donc ma gateway xPL pour la ZiBase, comme d’habitude développée en perl par dessus le framework xpl-perl de Mark Hindess, et conçue pour fonctionner sous linux. J’en profite pour remercier Zodianet et Mickael pour leur aide, support et enthousiasme !

Pour le téléchargement, c’est par ici.

Pour l’installation c’est du standard :

tar zxfv xpl-zibase*.tar.gz
perl Makefile.PL
make
sudo make install

et pour lancer le module c’est tout simple :

xpl-zibase -v --zibase-verbose

Une fois lancé le module va chercher une ZiBase sur le même réseau et, une fois trouvée il affichera quelque chose du genre :

Listening on 192.168.X.XXX:YYYY
Sending on 192.168.X.XXX
Listening ZiBase messages on 0.0.0.0:28734
Found ZiBase 'ZiBASEXXXXXX' at IP 111.222.333.444

Le module va diffuser sur le réseau xPL tous les messages RF qu’elle reçevra. Par exemple pour une sonde Oregon Scientific:

* - thgr228n.OS439171073[temp]=16.2
* - thgr228n.OS439171073[humidity]=67

Et, pour envoyer des commandes à vos appareils déclarés dans votre ZiBase :

# Pour allumer le device F5 :
xpl-sender -m xpl-cmnd -c x10.basic device=f5 command=on

 # Pour dimmer une lampe ayant le code F5 (marche seulement pour les modules Chacon et X2D) :
 xpl-sender -m xpl-cmnd -c x10.basic device=f5 command=dim level=50

Et voila ! Comme d’habitude n’hésitez pas à me faire part des difficultés que vous pourriez rencontrer avec ce module, soucis et remarques en tous genres; soit en commentaire de de billet, soit via le formulaire de contact du site.

A noter que la ZiBase qui était depuis quelque temps en rupture de stock devrait être réapprovisionnée d’ici quelques jours dans toutes les bonnes crèmeries comme par exemple ici chez Planète-Domotique, avec en prime une réduction de 50€ si vous pré-commandez jusqu’au 15 avril (oui je sais… c’est demain ), voir ici.

Les ‘notifications push’ sont très intéressantes dans le domaine de la domotique comme l’ont fait remarquer bien avant moi sur leurs blogs Clement Storck : http://clement.storck.me/?p=78 et Spy : http://www.e-home.fr/2011/01/domotique-notifications-push/

Pour les non initiés ou les non utilisateurs d’iPhone/iPad, les notifications push c’est un système qui permet aux applications iOS d’afficher une notification avec une alerte sur un iPhone ou un iPad; un peu comme un SMS en fait mais gratuit et avec des fonctionnalités plus extensibles.

Comme vous pouvez le voir dans l’article de Clement, les deux applications les plus connues dans ce domaine sont :

• Prowl : http://www.prowlapp.com/
• Pushme.to : http://pushme.to/

Ayant eu envie d’utiliser ces moyens de notification dans mon installation domotique, je me suis attelé à les y intégrer; ce qui a débouché (comme souvent chez moi ) sur un petit agent xPL écrit en perl s’intégrant au framework xpl-perl de Mark Hindess.

Son petit nom c’est xpl-pushmsg et pour le télécharger, il faut aller dans la section downloads (sisi c’est en haut à droite là).

L’installation se fait comme n’importe quel programme perl :

tar zxfv xpl-pushmsg*.tar.gz
perl Makefile.PL
make
sudo make install

Puis il se lance simplement :

xpl-pushmsg -v

Vous pouvez ensuite envoyer des notification Prowl ou Pushme.to via des commandes sur votre réseau xPL.

Pour Prowl :
xpl-sender -m xpl-cmnd -c sendmsg.basic to=APIKEY@prowl body=bonjour subject=Alerte
(Regardez le man de xpl-pushmsg pour connaitre tous les paramètres car il y a d'autres possibilités comme par exemple la priorité des messages ou encore la possibilité d'attacher une URL)

Pour Pushme.to :
xpl-sender -m xpl-cmnd -c sendmsg.basic to=NICKNAME@pushmeto body=bonjour from=Maison

Et voila ! De cette façon vous pourrez vous envoyer des notifications pour n’importe quel évènement de votre maison, comme certains l’ont fait par exemple lorsque quelqu’un sonne à leur porte : http://clement.storck.me/?p=80

Comme d’habitude avec les bouts de code que je fait, celui-ci n’est probablement pas exempt de bug, et je suis preneur de toute suggestion

En ce tout début d’année, je me suis intéressé de plus près à mettre en place une IHM de contrôle pour mon installation domotique. Je vais donc partager le début de mes réflexions.

Les contraintes pour réaliser ce que je voulais :

(pour rappel chez moi c’est des technos low cost type Chacon/HomeEasy, et c’est du xPL pour les interfaces)

• Pas envie de dépenser des centaines d’euros dans une station de contrôle domotique type Crestron ou les écrans HomeSeer : j’ai déjà suffisamment de gadgets qui trainent… autant les utiliser !
• Évidemment, pas envie d’acheter de software ni de licence
• Pas envie (enfin… surtout pas le temps en fait) d’apprendre à fond un nouveau langage de programmation, un nouvel environnement non connu (genre Objective C et XCode pour ne pas les nommer )
• Je veux du pratique, du « à portée de main », du tactile, et quelque chose d’un minimum joli et réactif (oui hein on est en 2011, c’est fini le minitel)

Les opportunités et autres réflexions :

• Un des rares trucs que j’aie fait sur mon installation est de tout passer en xPL (Cf mes précédents articles sur le sujet). Du coup, pas de code compliqué à faire pour discuter avec les interfaces domotique (RFXCOM, TellStick, CM15, etc..)
• A moins que vous ayez été isolé du monde durant les précédents mois, ça ne vous aura pas échappé : l’essor des appareils mobiles : iPhone et smartphones Android  évidemment, mais aussi la déferlante de tablettes tactiles qui arrivent sur le marché. Perso de ce côté là je suis équipé en Apple (iPhone et iPad) : je veux donc quelque chose qui me permette de contrôler mon installation au moins depuis ces deux appareils
• En prévision de cette problématique, j’avais réalisé en perl (avec les librairies xpl-perl comme d’hab) un petit programme de contrôle domotique qui tourne sur mon réseau xPL, et qui expose une API Web à la REST (très simple pour le moment) pour permettre de commander et de récupérer le status des modules et capteurs de mon installation : Je peux donc contrôler mon installation à coup de requêtes Web simples : il ne reste plus qu’à faire un joli frontend (‘ya pu k’à’ comme dirait l’autre )

Choix de la techno :

Deux possibilités : une webapp ou une vraie application mobile. Le titre de l’article vous a mis sur la voie : j’ai choisi la Webapp pour plusieurs raisons :

• Rapidité de développement : pas envie de passer trop de temps à refaire de l’Objective-C sous XCode ou à apprendre à coder pour Android
• Portabilité : une webapp n’est rien d’autre qu’un site web qui ressemble à une application. Du coup une webapp est potentiellement utilisable sur n’importe quel device équipé d’un navigateur Web récent. C’est particulièrement important pour moi qui n’aie pas envie de m’enfermer sur une marque. (A titre d’exemple, on commence à trouver des tablettes Android low cost qui feraient potentiellement de bons écrans de contrôle tactiles, beaucoup moins chez qu’un iPad).

Choix du Framework :

Décision est prise de faire une Webapp. Pour faciliter le développement (et aussi parce-que je suis une feignasse),  l’idée est bien entendu d’utiliser un Framework dédié aux Webapps. Je vous laisse googler, il y en a plusieurs, iWebKit, JQTouch, iUI, etc… Mon choix (en espérant qu’il soit bon) s’est porté sur le framework Sencha Touch.

Sencha Touch est un framework javascript spécifiquement fait pour les applications mobiles tactiles. Il est une excroissance de Ext JS pour ceux qui connaissent, un autre framework javascript bien connu depuis un moment. Il utilise les technos Javascript, HTML5 et CSS3, et est à ce titre compatible avec les appareils sous iOS ET avec ceux sous Android. Il est plus généralement compatible avec les navigateurs WebKit. En ce qui concerne les navigateurs pour ordinateurs classiques, c’est vers Safari ou vers Chrome qu’il faudra se tourner pour tester les développements réalisés sur un PC ou un Mac.

Last but not least, Sencha Touch dispose d’une licence open-source.

Mes impressions :

Étant plus à placer dans la catégorie des développeurs du dimanche, j’ai eu un peu de mal à me mettre dans la logique du framework Sencha Touch; c’est un peu particulier, mais rien d’insurmontable quand on suit les nombreux exemples qu’on trouve sur le net.

Comme je le mentionnait plus haut, avoir toutes les infos liées à mon installation à disposition dans une API Web REST a été d’une grande aide => ça permet de vraiment se concentrer sur la partie UserInterface et de ne pas s’embetter avec les détails d’implémentation de la partie domotique à proprement parler.

Ce que ça donne maintenant :

Attention hein, interdit de se moquer : c’est loin d’être fini :p. Mon premier objectif était de faire un écran général pour visualiser les infos principales et contrôler mes modules domotiques. Voici ce que ça donne :

Sur iPhone :

Sur iPad :

Pour la suite :

Ca reste très succinct pour le moment. Plein de choses à y ajouter, dans le désordre ce qui me vient à l’esprit :

• l’accès aux graphes pour les données environnementales
• l’accès à des macros, voire à des screnarii
• le contrôle multimédia : multiroom (squeezebox soft), media center (XBMC)
• une section pour tout ce qui est sécurité (détecteurs d’ouverture, videosurveillance, etc…)

On verra ce que je peux faire avancer en fonction du temps (ou plutot du manque de temps ). Autre point intéressant avec une Webapp qui accède à toutes ses données via une API Web en REST, c’est que peut être si un jour j’utilise un autre soft (Domogik ? ) je pourrai, à moindre frais, le plugger dessus…

La téléphonie est un domaine qui a énormément évolué ces dernières années, sous l’impulsion des mobiles d’une part, et des box internet d’autre part. Ces évolutions (généralisation de la présentation du numéro, ToIP, messagerie unifiée web/tel, etc…) permettent de connecter sa téléphonie avec son système domotique; dans quel but me direz-vous ?

Comme souvent on distingue deux axes :

• La collecte d’informations : Savoir si il y a eu un appel, de qui, à quelle heure, pendant combien de temps. Savoir si j’ai des messages sur ma boite vocale, si j’ai des SMS/MMS non lus, etc…
• L’émission d’informations : L’envoi de SMS/MMS, l’émission d’appels téléphoniques de notification (via de la synthèse vocale par exemple), etc…

Mises en situation et utilité :

• Application n°1 : Notification d’appel en temps réel. Vous êtes chez vous et votre téléphone sonne; votre système domotique vous notifie de l’appel en y ajoutant des informations sur le numéro appellant (numéro de tel, nom, photo…) :
  • Suivant l’heure une notification visuelle (par exemple sous forme de lumière dans le séjour) vous averti de l’appel.
  • Si vous êtes en train de regarder tranquillement un film via Media Center, une popup de notification apparaît dans un coin de la télévision, affichant le nom et la photo de l’appellant. De cette façon vous pouvez décider (sans vous lever de votre canapé -ben oui… c’est fatiguant quand même ;)) de répondre ou de poursuivre votre film.
  • Vous êtes en train de surfer sur internet avec votre PC ou laptop, une popup s’affiche avec les informations de l’appellant
  • Votre nabaztag vous notifie de l’appel, soit avec ses lumières, ses oreilles, ou via la synthèse vocale

• Application n°2 : Historisation des appels. Votre système domotique garde une trace de tous les appels reçus en votre absence, incluant heure d’appel et coordonnées de l’appellant.
  • Vous pouvez reçevoir un mail ou un SMS lorsque quelqu’un a appellé en votre absence
  • Vous pouvez consulter la liste des appels en absence, sur un interface Web ou encore sur l’écran tactile de contrôle domotique de votre maison
  • Lorsque vous rentrez chez vous le soir, votre Nabaztag vous fait un récap des appels reçus en votre absence.

• Application n°3 : L’envoi d’informations par téléphone. Notamment utile dans le cas de notification d’urgence :
  • Votre système domotique détecte une intrusion, il vous téléphone et vous l’annonce via une phrase en synthèse vocale.
  • Il se produit une coupure d’electricité chez vous durant votre absence, votre système domotique, sur onduleur, vous appelle et vous le dit avant que les batteries soient à plat.

• Application n°4 : Intégration avec un PABX personnel. En intégrant carrement un PABX (ou un IPBX) personnel à votre système domotique, de nombreuses nouvelles possibilités apparaissent. Par exemple :
  • L’intégration directe de la messagerie vocale à votre système domotique (par exemple votre Nabaztag vous joue vos messages vocaux)
  • La possibilité de contrôler votre maison avec les touches de n’importe quel téléphone via un serveur vocal
  • L’intégration de la réception et de l’envoi de FAX à votre système domotique
  • Le suivi précis des communications téléphoniques, temps, destinations, etc…

• Application n°5 : Intégration avec les APIs d’opérateurs. Un peu comme l’utilisation d’un PABX, certains opérateurs de ‘box’ triple play proposent des APIs pour permettre, dans notre cas, à votre système domotique d’accéder aux informations téléphoniques. Par exemple :
  • Messagerie vocale
  • SMS/MMS
  • Facturation

Matériel :

Là encore, tout dépend de ce que vous voulez faire :

• La solution la plus simple est d’utiliser un simple modem 56K ‘à l’ancienne’ branché sur le port USB de votre serveur domotique. Ce modem vous permettra notamment de détecter les appels entrants et de récupérer les informations de présentation du numéro.
• Pour les plus courageux, vous pouvez aussi carrément intégrer un PABX (comme l’IPBX logiciel opensource ‘Asterisk‘) à votre système domotique pour des possibilités quasi-infinies.

Dans les deux cas vous devrez adapter la partie logicielle à votre système domotique et à ce que vous voulez en faire.

Références :

• Logiciel VistaCallerID : http://www.kentdome.com/vistacallerid
• Logiciel CallerIDMCE : http://www.kentdome.com/calleridmce
• Le plugin CallerIDModem de Domogik : http://www.domogik.org/plugin_cidmodem

Sujet que j’ai déjà abordé plusieurs fois sur ce blog, le contrôle de la consommation (en énergie certes, mais pas que…) est une chose particulièrement appréciable => Ça permet entre autres de se rendre vraiment compte de ce que le foyer consomme, d’anticiper les dépenses, de mesurer l’impact réel de telle ou telle mesure d’économie d’énergie, d’être alerté lorsqu’il se passe quelque chose de pas normal, etc…

Pour moi la mesure de consommation peut concerner :

• L’électricité, énergie que l’on retrouve dans tous les foyers
• Le Gaz, énergie pas présente chez tout le monde mais très importante
• Le Fioul, idem ci-dessus
• L’eau, qui n’est pas une énergie à proprement parler mais qui est une ressource utilisée par tout le monde et qu’il convient d’économiser.

Mises en situation et utilité :

• Application n°1 : Toute simplement, suivre sa consommation en énergie et en ressources :
  • Avoir des mesures instantanées
  • Avoir des données historiques et des graphes, qui permettent par exemple de projeter la consommation sur une période particulière de l’année en se basant sur la mesure de l’année précédente.
  • Optimiser sa consommation d’eau : par exemple en mesurant séparément sa consommation d’eau d’arrosage, il est possible de calculer simplement l’intérêt de demander l’installation d’un compteur vert comme le proposent certaines municipalités (il s’agit d’un deuxième compteur d’eau uniquement destiné aux eaux d’arrosage et sur lequel vous ne payez que la fourniture d’eau (pas de frais d’assainissement)).
  • Optimiser sa consommation d’électricité : A partir du moment où vous avez une année entière de mesure de consommation d’électricité, vous pouvez de façon très précise estimer le tarif d’électricité le plus adapté et le souscrire, que ce soit chez EDF ou chez des fournisseurs alternatifs.

• Application n°2 : Être averti en cas de consommation anormale d’eau. A partir du moment où la consommation d’eau est intégrée au système domotique, rien n’empêche de définir certains critères et d’envoyer des alertes/notifications en cas de consommation anormale. Par exemple :
  • Consommation anormale d’eau en pleine nuit (peut être révélateur d’une fuite)
  • Consommation anormalement élevée sur tel ou tel circuit (par exemple sur le circuit d’arrosage automatique cela peut indiquer un mauvais réglage ou bien une vanne qui serait restée ouverte, etc…)

• Application n°3 : Mesurer vos économies d’énergie/d’eau. Rien de plus frustrant que de faire un effort pour moins consommer une ressource, sans avoir aucune idée rapidement de l’économie réelle.
  • Vous installez des mousseurs économiques sur tous vos robinets => vous pourrez mesurer dès la première journée l’impact sur votre consommation d’eau
  • Vous remplacez vos ampoules par des fluo-compactes => vous pourrez mesurer tout de suite l’économie réalisée sur votre consommation d’électricité
  • Vous faites un nouveau réglage de votre arrosage automatique => idem, vous visualisez directement ce que cela consomme

Matériel :

Côté matériel cela se complique. Certaines ressources sont facilement mesurables (électricité) tandis que pour d’autres c’est carrément du bricolage (Eau/Gaz), voire même apparemment inexistant après avoir fait quelques recherches :

• Électricité : De nombreux systèmes existent et s’intègrent déjà bien dans les systèmes domotiques. Plus de détails sur cet article :
  • http://www.poulpy.com/2010/02/mesure-de-la-consommation-electrique-en-domotique/
• Eau : Souvent il s’agit de systèmes de mesure indirecte (i.e. on ne mesure pas l’eau elle même mais le nombre de tours de l’aiguille du compteur, que l’on transforme en volume)
  • Exemple 1wire http://www.macoda.com/index.php/Montage:Compteur_eau_DS2423.
  • Exemple compteur sortie impulsion : http://www.planete-domotique.com/compteur-d-eau-avec-sortie-impulsion.html
  • Autre compteur sortie impulsion : http://www.alaxa.nl/english/index.htm
• Gaz/Fioul : Là je n’ai rien trouvé de ouvert et faisable facilement. Il existe en revanche des solutions propriétaires qui mesurent la consommation Gaz comme MyHome chez Legrand.

Références :

• Récap solutions de consommation électrique : http://www.poulpy.com/2010/02/mesure-de-la-consommation-electrique-en-domotique/
• Compteur d’eau home made : http://www.touteladomotique.com/forum/viewtopic.php?t=348
• Discussion compteur d’eau / de gaz : http://www.touteladomotique.com/forum/viewtopic.php?t=3261

Après un long moment de non mise à jour de ce blog, voici le premier article d’une série que j’espère la plus longue possible, traitant des différentes applications réelles de la domotique. L’objectif est de s’éloigner un peu de la technologie pure, et de s’attacher aux situations de la vie quotidiennes où la domotique peut avoir sa place.

Ce premier billet traite d’un objet anodin de la vie courante, que nous utilisons -presque- tous une fois par jour : la boite aux lettres.

Principe :

Une boite aux lettres domotisée ? Je vous entend vous dire « mais qu’eeeeest ce que c’est que cette idée farfelue complètement inutile !? ». J’assume le côté farfelu (d’autant que l’idée n’est pas de moi => allez voir les références à la fin de cet article dont l’une pointe sur l’excellent article de Cedric qui explique comment il a réalisé sa domotisation de boite aux lettres), mais vous allez voir ce n’est pas -complètement- inutile.

L’idée est simple : être capable de détecter les ouvertures de votre boite aux lettre et les transmettre à votre système domotique. Vous pourrez ensuite utiliser cette information pour différentes choses.

Mises en situation et utilité :

• Application n°1 : Être averti quand le facteur passe. Lorsque le facteur passe et dépose une lettre ou un paquet dans votre boite aux lettre, votre maison vous informe. Suivant que vous soyez chez vous ou pas, plusieurs méthodes de notification sont possibles :
  • Vous recevez un e-mail qui vous dit que le facteur est passé (désolé je n’ai encore pas trouvé de moyen fiable pour différencier le vrai facteur du mec qui remplit votre boite aux lettre de publicité )
  • Vous recevez un SMS
  • Une fenêtre popup apparait sur l’écran de votre Media Center si vous étiez en train de regarder la TV
  • Vous recevez un message sur MSN Messenger, Jabbe, ou un autre système de messagerie instantanée
  • Votre Nabaztag vous dit à voix haute Le facteur est passé !

• Application n°2 : Stocker l’heure de passage du facteur dans votre système domotique. Celle-ci pourra être utilisée par la suite pour différentes choses :
  • Faire un recap de la journée que votre nabaztag vous dictera quand vous rentrerez du travail « Le facteur est passé à 12h18, puis à 13h02… »
  • Faire des statistiques pour connaître à l’avance les heures de passage moyennes du facteur tel ou tel jour

Matériel :

Côté matériel il ne faut pas grand chose mais il va falloir bricoler un peu.

L’ouverture de la boite aux lettre peut être détectée en utilisant un simple détecteur d’ouverture classique comme par exemple le Marmitek DS18 si vous êtes en X10 (utilisé par Cédric et Lionel dans leurs excellent tutoriaux : voir Références en bas de cet article) ou encore le détecteur d’ouverture Chacon CH54581 comme je l’ai fait. Dans les deux cas, il vous faudra démonter le détecteur, trouver les bons emplacement dans votre modèle de boite aux lettres, fixer les éléments correctement et éventuellement ajouter un fil ‘antenne’ pour augmenter la portée de votre détecteur car d’une part parfois la boite aux lettres est éloignée de la maison, et d’autre part le fait que le capteur soit enfermé à l’intérieur de la boite métallique réduit drastiquement sa portée d’émission.

Dans tous les cas je vous encourage à lire les deux excellents liens en bas de cet article où sont présentées deux installations avec explications détaillées et photos à l’appui.

Il vous faudra également le dispositif ‘kivabien’ pour recevoir sans fil les signaux envoyés par le détecteur d’ouverture : généralement c’est un boitier RFXCOM ou équivalent qu’il vous faut.

Enfin, je ne détaillerai pas la partie ‘notification’ où vous pourrez laisser libre cour à votre imagination (nabaztag, tuxdroid, lumière, mail, sms, musique…).

Références :

• http://blog.locqueneux.com/index.php/2010/01/11/domotiser-sa-boite-aux-lettres/
• http://domotique.lesfichiers.info/viewtopic.php?f=26&t=73

Un gros défaut de ce TellStick était sa portée : en effet, chez moi à 10m avec une ou deux cloisons en placo alvéolaire ça ne fonctionnait plus : on était très vite limité.

Il se trouve que j’ai été en contact avec le constructeur (Telldus => ils sont très sympa et ouverts), qui est au courant de ce problème sur les tellstick de première génération, et qui propose gratuitement d’échanger votre Tellstick de première génération contre un TellStick avec une antenne externe.

J’ai évidement suivi cette procédure et ai reçu à la maison un nouveau TellStick et une enveloppe pré-adressée pour renvoyer l’ancien (frais de port à ma charge par contre mais bon dans une enveloppe bulle simple c’est loin d’être inabordable, et c’est un ‘sacrifice’ que je fais volontiers lorsque le constructeur est une petite boite qui_n’en_veut avec des gens sympas, accessibles et serviables )

Voici sur la photo les deux tellstick (ancien en bas, nouveau en haut) :

Comme vous le voyez l’emballage change mais à priori l’electronique est identique (model id identique), mis à part bien sur l’apparition d’une antenne externe ‘filaire’.

Tests fait => c’est BEAUCOUP mieux ! J’arrive maintenant à contrôler tous les modules Chacon de mon habitat sans problème !

Bref si vous avez un TellStick avec des soucis de porté, envoyez un petit mail à rma _at_ telldus.se en expliquant votre problème (en anglais hein… pas la peine de faire du google translate Français/Suédois) et ils vous expliqueront tout.

Merci Telldus !

M’intéressant de plus en plus à Domogik (si vous ne connaissez pas allez jeter un oeil : c’est un work in progress mais TRES prometteur), et, celui-ci étant écrit en language python, je me suis penché sur le sujet de la programmation du TellStick en Python.

J’avais déjà fait module xpl pour le TellStick mais celui-ci est très basique et ne supporte pas toutes les possibilités de ce petit transmetteur RF bien pratique, donc je me suis lancé, mais cette fois en python.

Voici donc la première partie du travail : une classe Python qui permet de contrôler le TellStick. Celle-ci s’appuie sur la librairie telldus-core fournie par Telldus, il faut donc l’avoir installée au préalable.

Cous trouverez la classe python dans la section téléchargements de ce blog, ou plus précisément ici.

Pour l’installer, c’est du python classique :

$ tar zxfv TellStick-0.1.tar.gz
$ cd TellStick-0.1
$ sudo python setup.py install

L’utilisation est expliquée dans le fichier lui-même, et voici un exemple d’utilisation en Python :

#!/usr/bin/python

from TellStick import *

# Création de l'objet
ts = TellStick()

# Anciens modules Chacon : allumer le module A4
ts.sendOff("arctech", "codeswitch", "A", "4")

# Nouveaux modules Chacon : eteindre le module 0x12345 / 2
ts.sendOn("arctech", "selflearning-switch", "0x12345", "2")

# Prise commandable 1er prix Castorama : Allumer la A1
ts.sendOff("risingsun", "", "1", "1")

Et voala, c’est pas plus compliqué que ça. Vous trouverez des infos sur les protocoles et devices supportés sur cette page chez Telldus.

Prochaine étape : le plugin xPL complet pour TellStick…

Telldus Technologies, le constructeur du TellStick, a le (très) bon goût de mettre à disposition les logiciels (et leurs sources) permettant d’utiliser leur Tellstick sous linux : il s’agit de la commande rfcmd.

« Ben c’est parfait alors ! » me direz-vous; et bien… presque, il ne manquait plus que le logiciel gateway xPL pour intégrer tout ça dans un réseau domotique xPL en place. Et bien voilà qui est chose faite après quelques lignes perl en cette journée pluvieuse.

Pour le télécharger, ça se passe ici

Ca s’installe à la mode perl, comme d’habitude pour mes modules :

perl Makefile.PL
make
sudo make install

Et ça permet d’envoyer des commandes aux modules HomeEasy/Chacon :

xpl-sender -m xpl-cmnd -c homeeasy.nexa house=A unit=1 command=on

Ca permet aussi de commander les modules utilisant le protocole ‘RisingSun’ comme les modules de type GAO, ou encore les prises telecommandées on/off premier prix de chez casto (merci à Boris pour ce bon plan permettant d’avoir des prises commandables pour 20€ les 3) :

xpl-sender -m xpl-cmnd -c risingsu.basic code=1 device=1 command=on
xpl-sender -m xpl-cmnd -c risingsu.basic code=1 device=1 command=off

Dans ce billet nous allons parler de la mesure de consommation électrique, plus que jamais au coeur des préoccupations du grand public avec toutes les campagnes prônant les économies que l’on peut voir depuis quelque temps.

Une chose est certaine : il est difficile de demander à quelqu’un de faire des économies lorsqu’on ne peut rien mesurer => ça ne motive pas et ça ne permet pas de vérifier les économies réelles faites en adoptant tel ou tel comportement.

Voici donc un petit tour d’horizon des technologies de mesure de consommation électrique les plus répandues dans le domaine de la domotique.

Chacon EcoWatt

Principe : Pince amperemetrique à clampter autour du fil de phase de la ligne à mesurer. La pince est reliée à un petit module qui transmet les informations de puissance électrique sans fil à une base avec un afficheur, qui permet de visualiser la consommation en temps réel. Le module transmetteur est alimenté par batterie.

CurrentCost ENVI

Principe : Pince amperemetrique à clampter autour du fil de phase de la ligne à mesurer. La pince est reliée à un petit module qui transmet les informations de puissance électrique sans fil à une base avec un afficheur, qui permet de visualiser la consommation en temps réel. Le module transmetteur est alimenté par batterie.

RFXCom RFXPower

Principe : Pince amperemetrique à clampter autour du fil de phase de la ligne à mesurer. La pince est reliée à un module RFXMeter qui transmet les informations de puissance électrique sans fil à un RFXcom. Le module RFXMeter est alimenté par un adaptateur secteur.

PlugWise

Principe : Des modules à brancher sur chaque prise de courant pour laquelle on veut mesurer la consommation électrique. La communication se fait sans fil (adaptation du protocole ZigBee), jusqu’à un petit adaptateur USB à brancher sur le PC. Toutes les prises sont en réseau maillé (Mesh) ce qui augmente la portée. Les prises sont également contrôlables sans fil (ON/OFF).

QEES Power

Principe : Des modules a cabler sur les fils des appareils ou prises pour lesquels on veut mesurer la consommation électrique. La communication se fait sans fil via le protocole ZWave. Les modules sont également contrôlables sans fil (ON/OFF).

Et voilà pour ce petit tour du marché de la mesure de consommation électrique pour système domotique home made. N’ayant pas testé toutes les solutions je me garderai de donner un avis tranché sur toutes. Cependant je peux dire deux choses :

• Pour une mesure de consommation globale, les solutions se basant sur des pinces ampèremétriques sont sécurisantes : rien à démonter dans le tableau électrique + pas d’équipement « en coupure » de votre arrivée électrique.
• Personnellement j’utilise la solution de CurrentCost : le ENVI. Installation ultra simple, support client de qualité, format de données ouvert => j’en suis tout à fait satisfait.

Les personnes possédant une interface X10 USB Marmitek CM15A (aussi appellée CM15Pro) et désirant intégrer celle-ci dans leur réseau xPL tout en restant sous Linux ont eu probablement le même problème que moi : il n’y a rien qui existe pour le faire.
Plus généralement, les logiciels disponibles pour cette interface USB sont très peu nombreux sous linux. Cela est principalement dû au manque de documentation technique sur cette interface : En effet, bien que plus évoluée que le archi-connu CM11, le CM15 est aussi conçu très différemment : plus de port série (même émulé sur de l’USB), protocole de communication différent, intégration des commandes X10 sans fil RF…
Grâce au travail de la communauté, plusieurs « proof of concept » ont été réalisés pour faire fonctionner cette interface sous Linux :

• Petite application en ligne de commande permettant d’actionner des modules et de recevoir les commandes X10 – http://www.eclipsehomeauto.com/cm15a_on_linux/cm15a.shtml
• Module CM15A pour le célèbre MisterHouse. Mais celui-ci ne permet que de faire de l’émission de commandes (pas de réception) – http://misterhouse.wikispaces.com/X10-CM15A
• Le driver adapté par Neil Cherry permettant de ‘voir’ le device CM15A sous linux et de communiquer avec l’interface – http://www.linuxha.com/USB/cm15a.html

Beaucoup de travail a déjà été fait, et permet la communication ‘simple’ avec le CM15A (il reste encore toute une partie des specs de l’interface qui reste inconnue, mais l’envoi/réception des commandes les plus utilisées est tout à fait faisable).

En voyant cela, et utilisant uniquement un CM15A pour l’interfacage X10 (je n’ai plus de CM11) je me suis dit que ça serait pas mal de développer un module pour faire gateway entre le CM15 et mon réseau xPL. Voila qui est chose faite

Pour le téléchargement direct, allez voir dans la section des downloads. Pour les explications, lisez la suite

2. Pré-requis

Je ne détaillerai pas ici, mais vous devez également avoir le perl qui fonctionne correctement avec les modules qui vont bien, ainsi qu’une installation fonctionnelle des librairies xPL-Perl (http://www.xpl-perl.org.uk).
Comme toute machine faisant partie d’un réseau xPL, vous devez avoir au moins un HUB qui tourne dessus (perso j’utilise celui fournit avec les librairies xPL Perl).

Un autre pré-requis important est le driver CM15 dont l’installation est détaillée ci-dessous.

3. Installation du driver pour le CM15

Pour faire fonctionner l’application, il vous faudra d’abord installer le driver iplc de Neil Cherry :

apt-get install linux-headers-generic
wget http://www.linuxha.com/common/iplcd/iplc-driver.tgz
tar zxf iplc-driver.tgz
cd iplc/driver/linux-2.6/
# Pour les kernels les plus récents faire, executer :
sed -i s/\\Winfo\\W*\(/\ pr_info\(/ *.c
cd cm15a.d
make

Vous devriez maintenant avoir un joli driver sous la forme du fichier cm15a.ko que vous pouvez copier où bon vous semblera et que vous allez maintenant charger dans votre noyau :

$ insmod /path/to/cm15a.ko
$ dmesg | tail
[274611.018498] cm15a USB #252 now attached to major 180 minor 252
[274611.018536] usbcore: registered new interface driver cm15a
[274611.018544] X10 CM15A USB Driver v0.03

Vérifiez enfin que le device a bien été créé :

$ ls -la /dev/cm15a0
crw-rw---- 1 root root 180, 252 2010-02-14 19:59 /dev/cm15a0

Le driver marche, vous êtes maintenant parés à installer mon module xPL CM15

4. Installation du module xpl

Pour le téléchargement, ça se passe ici : Download

Téléchargez et décompressez le tarball et procédez à l’installation classique « à la perl ». Attention, il faut que le module soit installé dans le même PREFIX que les librairies xpl-perl. Par exemple :

• Si xPL-perl est installé dans /usr/share/perl5/xPL/, alors votre prefix est « /usr »
• Si par contre c’est installé dans /usr/local/share/perl5/xPL, alors le prefix est « /usr/local »

$ wget ......../xpl-cm15a-0.2.tar.gz
$ tar zxf xpl-cm15a-0.2.tar.gz
$ cd xpl-cm15a-0.2
$ perl Makefile.PL PREFIX=/usr   # Mettre le bon PREFIX voir ci-dessus
# Vérifier qu'il n'y a pas de warning de dépendances
$ make
$ sudo make install

Si tout est OK, l’installation aura entre autres créé le script /usr/bin/xpl-cm15a

5. Lancement de l’application

Tout est indiqué dans la page de man qui aura été installée avec le programme à l’étape précédente. Voici la syntaxe générale :

$ xpl-cm15a --help
Usage:
xpl-cm15a [flags] [options]
where valid flags are:
--help                - show this help text
--verbose             - verbose mode (for the xPL layer)
--cm15a-verbose       - verbose mode (for the cm15a layer)
--cm15a-ignore-rf     - ignore x10 RF messages from the cm15a
--cm15a-ignore-plc    - ignore x10 PowerLine messages from the cm15a
and valid options are (default shown in brackets):
--interface if0            - the interface for xPL messages (first
non-loopback or loopback)
--cm15a-device /dev/xxx    - device for the cm15a (/dev/cm15a0)

Il est obligatoire de spécifier le paramètre ‘cm15a-device’ en précisant le device de votre cm15 (/dev/cm15a0 par défaut).

Il vous est également possible de demander à la gateway d’ignorer les messages X10 RF et/ou les messages X10 courant porteur. Cela concerne uniquement les évennements qui ARRIVENT jusqu’au CM15, et cela évite que l’application ne génère des notifications sur votre réseau xPL si jamais vous n’en voulez pas.
Pour donner un exemple concret : J’ai un CM15 (qui capte les ordres X10 RF sans fil) et j’ai un RFXCOM qui capte lui aussi les ordres X10 RF. Donc, par défaut, quand j’actionne une commande X10 RF (telecommande ou détecteur par exemple), cela va me génèrer DEUX messages sur mon réseau xPL : un envoyé par la gateway RFXCom et l’autre par la gateway CM15 => Dans ce cas là j’ai spécifié l’option « –cm15a-ignore-rf » pour que la gateway CM15 ne me renvoie pas les messages X10 RF.

Exemple de lancement (attention il faut le lancer en root, ou bien avec des droits suffisants pour lire/écrire dans /dev/cm15a0):

$ /usr/bin/xpl-cm15a --cm15a-ignore-rf --cm15a-verbose --cm15a-device /dev/cm15a0

6. Réception / Emission d’ordres X10

Pour émettre un ordre X10, il suffit alors d’envoyer le message correspondant sur votre réseau xPL. Par exemple pour allumer le module A3 :

$ /usr/bin/xpl-sender -m xpl-cmnd -c x10.basic device=a3 command=on

La gateway devrait alors envoyer l’ordre sur courant porteur et votre module devrait s’activer.

Pour vérifier le fonctionnement en réception, vous pouvez par exemple lancer le logger xPL et actionner une commande X10 (par exemple sur un télécommande, ou bien passer devant un détecteur de mouvement…etc..). Vous verrez alors que la gateway xpl-cm15a enverra le message correspondant sur votre réseau xPL :

$ /usr/bin/xpl-logger
192.168.X.X:YYYY [xpl-trig/x10.basic: tlam-CM15A.zzzzzz -> * - off a2]

7. Limitations

Certaines choses ne fonctionnent PAS, notamment :

• Les fonctions compliquées de X10 comme les extended functions
• L’émission d’ordres X10 RF (par manque de documentation du CM15A, seule la réception marche pour le RF)

D’autres n’ont pas pu être testées :

• Les modules X10 bi-directionnels
• Le X10 security

Et voilou, j’espere que ça dépannera les galériens du CM15 sous linux comme moi N’hésitez pas à me remonter les problèmes d’utilisation ou remarques sur ce module xpl-cm15a.

Grâce à cet module complètement indispensable, on peut « discutter » avec sa maison, pour peu qu’elle ait un peu de conversation.
Le module en lui même ne fait que :

• Se logger sur un service Jabber (Google Talk par exemple)
• Diffuser sur le réseau xPL les messages qu’il reçoit
• Permettre d’envoyer des messages à des contacts Jabber via une commande xPL

Pour ceux qui veulent tester sans lire la suite, vous trouverez le module sur la page de téléchargements

Voyons comment installer tout ça.

1. Pré-requis :

• Un PC (ouaou super) sous Linux (C’est du perl donc ça marche probablement sur Mac aussi mais je n’ai jamais essayé).
• Un réseau xPL en place (i.e. les applications essentielles déjà installées, notamment le Hub XPL)
• Un compte jabber (gtalk par exemple) créé spécialement pour votre système domotique et vous ayant dans sa liste de contacts
• Les librairies xPL-Perl installées (http://www.xpl-perl.org.uk)
• Certains modules perl utilisés

Pour ceux sous ubuntu/debian il faut notamment installer les packages suivants :

$ sudo apt-get install libconfig-general-perl libnet-jabber-perl

2. Installation

Télécharger mon petit module en cliquant là : Download.

Décompressez le tarball et procedez à l’installation classique « à la perl ». Attention, il faut que le module soit installé dans le même PREFIX que les librairies xpl-perl. Par exemple :

• Si xPL-perl est installé dans /usr/share/perl5/xPL/, alors votre prefix est « /usr »
• Si par contre c’est installé dans /usr/local/share/perl5/xPL, alors le prefix est « /usr/local »

$ tar zxf xpl-jabber-*.tar.gz
$ cd xpl-jabber-*
$ perl Makefile.PL PREFIX=/usr   # Mettre le bon PREFIX voir ci-dessus
# Vérifier qu'il n'y a pas de warning de dépendances
$ make
$ sudo make install

Si tout se passe bien, le programme s’installe là : /usr/bin/xpl-jabber

3. Configuration

Avant de lancer le soft, il faut définir le compte jabber à utiliser. Pour cela vous pouvez partir du fichier de configuration fourni en exemple et le mettre au bon endroit.

$ sudo mkdir -p /etc/xplperl
$ sudo cp conf/jabber.conf.example /etc/xplperl/jabber.conf

Editez le fichier pour y mettre vos propres infos. Si il s’agit d’un compte google talk, vous n’avez que les paramètres ‘username’ et ‘password’ à changer. Le fichier devrait ressembler à ça :

$ cat /etc/xplperl/jabber.conf
#
# xPL Jabber Gateway config file
#
username = my_gtalk_username
domain = gmail.com
password = my_gtalk_password
server = talk.google.com
port = 5222
tls = 1

4. Lancement

Normalement vous êtes pret à lancer xpl-jabber. Préparez quand même :
- Votre client jabber connecté avec votre compte à vous (histoire de voir quand votre maison se connectera )
- Un logger de messages xPL (xpl-logger du package xpl-perl sera parfait) pour vérifier le bon fonctionnement du tout

$ xpl-logger -v

Attendez quelques secondes, et vous devriez voir le compte que vous avez configuré se connecter sur votre messagerie jabber => victoire !

Envoyez lui le message « help », il devrait vous répondre un message générique.

5. Réception de messages

A chaque fois que vous envoyez un message sur jabber à votre maison, un message xPL sera envoyé sur votre réseau xPL. Par exemple en envoyant le message « home sweet home » sur jabber, on verra passer le message sur le réseau xPL grâce au logger :

$ xpl-logger
[xpl-trig/sendmsg.im: tlam-jabber.home -> * - votre_compte@gmail.com => votre_maison@gmail.com : home sweet home]

Libre à vous ensuite d’utiliser ce message et de déclencher, à sa réception, des actions dans votre habitat.

6. Envoi de messages

Pour que votre maison envoie des messages Jabber, il vaut envoyer un message xPL au bon format. Par exemple, si on veut envoyer le message « rentre vite ! » à l’utilisateur Gtalk mon.compte@gmail.com :

$ xpl-sender -m xpl-cmnd -c sendmsg.im to=mon.compte@gmail.com \
   body='rentre vite !'

Là aussi, libre à vous d’envoyer des messages Jabber en fonction des évennements sur votre réseau domotique. Par exemple lorsqu’un détecteur de mouvement capte quelque chose, lorsque la température descend en dessous d’une certaine limite, etc…

7. Pour aller plus loin

Comme vous l’avez probablement compris, le module xpl-jabber n’est qu’une application « gateway » : elle n’embarque aucune intelligence de contrôle domotique : c’est en utilisant une application de controle (xPLHAL par exemple) que vous pourrez faire inter-agir tous vos éléments xPL avec xpl-jabber.

Enfin quand même un petit avertissement : faites attention à la façon d’intégrer l’Instant Messaging à votre installation : la securité d’une commande par instant messaging n’est clairement pas optimale, c’est le moins qu’on puisse dire.

N’hésitez pas à poster vos commentaires/retours ici même, j’y répondrai avec plaisir !