Poulpy – Domotique, OpenSource et Geekeries

Domotique, OpenSource et Geekeries


ImperiHome continue son petit bout de chemin !

 

Déjà compatible avec la ZiBase, la Vera, et la station météo Netatmo, notre application évolue encore. Suite aux nombreux retours que nous avons eus, nous avons avec Hugo décidé de travailler à rendre ImperiHome compatible avec Android 2.3 Gingerbread (contre 4.0 jusqu’à présent).

Voilà qui est fait avec la sortie de la version 1.3 d’ImperiHome !

D’autres améliorations et fonctionnalités sont au rendez-vous de cette mise à jour ;) Retrouvez l’annonce ainsi que la liste des améliorations sur le site d’ImperiHome

Et pour installer l’application c’est toujours sur le Play Store.

Encore d’interminables mois depuis mon dernier post, comme d’habitude, mais vous commencez à être habitués ;)

 

Aujourd’hui un articule un peu particulier car au lieu de vous parler de 10.000 sujets différents je ne vais parler que d’un seul, mais un qui m’a pas mal occupé ces derniers mois. Ce sujet il s’appelle ImperiHome. C’est quoi donc me direz-vous ? et bien c’est une nouvelle application mobile de contrôle domotique un peu particulière que je vais tâcher de vous présenter succinctement.

Aller, la vidéo de présentation pour commencer ;) :

 

Un peu de contexte pour commencer

Ceux qui suivent ce blog depuis un moment le savent : j’ai travaillé sur plusieurs « mini-projets » dans le domaine de la domotique, du xPL par ci, de la ZiBase par là, etc… Cela faisait de nombreuses années que j’avais envie de réaliser une appli de contrôle domotique (au sens ‘IHM’, interface homme machine).

De nombreuses nouveautés sont venu secouer le secteur de la domotique ces dernières année (démocratisation des smartphones, des tablettes, du tactile capacitif, multiplication des box domotique, des objets comuniquants de toutes sortes, etc…), aussi, nous avons décidé il y a quelques mois avec un ami (Hugo de son prénom ;) ) de nous lancer dans le développement d’une telle application : ImperiHome.

 

ImperiHome : le contrôle domotique sous Android

Nous venons de terminer la toute première version de l’application, et celle-ci est disponible dès à présent sur le Play Store de Google. Ce n’est qu’une première version, destinée à mettre un place un socle solide pour toutes les idées que nous avons pour la suite, mais elle dispose d’ores et déjà des fonctionnalités et particularités suivantes :

  • L’application est multi-box! Elle peut se connecter simplement avec :
    • les ZiBase de Zodianet
    • les Vera de Micasaverde
  • Prise en charge des principaux types de modules domotique (switch, dimmers, détecteurs d’ouverture/mouvement, capteurs d’humidité de température de consommation électrique, cameras…)
  • L’appli détecte si vous vous trouvez sur le même réseau que votre box domotique (mode local) ou pas (mode remote) et adapte automatiquement ses fonctionnalités et son comportement
  • L’appli a été conçue pour offrir une réactivité maximum (via divers mécanismes) afin de réduire le délai d’utilisabilité et le nombre de ‘clicks’
  • Reconnaissance vocale pour allumer/éteindre des appareils ou lancer des scenarios
  • Support de la technologie NFC ! Configurez des tags NFC pour effectuer des actions domotique dès que vous approchez votre smartphone
  • Support des smartphones comme des tablettes, pour lesquelles un layout ‘portrait’ particulier a été réalisé
  • … aller je vous laisse découvrir le reste ;)

Aller hop quelques screenshots :

 

Comment installer l’application ?

Rien de plus simple. Il vous faut tout d’abord disposer d’un smartphone ou d’une tablette sous Android 4.0 (Ice Cream Sandwich) minimum (ça marche avec 4.1 Jelly Bean). Ensuite allez simplement sur le Google Play Store et installez ImperiHome ;) Aller pour ceux qui ont pas envie de taper voici le lien direct et le QR Code correspondant ;) :

 

Bonus, pour ceux qui n’ont pas encore franchi le pas d’acquérir une box domotique, l’application dispose d’un mode « démo » : vous pourrez voir ce que ça donne avec de ‘faux’ devices, pour vous rendre compte sans avoir besoin de vous équiper totalement pour le moment.

 

Et la suite ?

Comme dit plus haut, cette première version apporte quelques innovations mais elle n’est en réalité que le socle pour la suite, car nous avons avec Hugo une liste d’idées longue comme le bras (longue comme 4 bras en réalité). Sans trop m’étendre sur les détails, ce que nous souhaitons faire pour le futur :

  • « Release early, release often » : nous souhaitons, autant que possible, faire des mises à jours très régulières de l’application, afin d’y ajouter des nouvelles fonctionnalités et d’assurer une bonne dynamique.
  • Supporter d’autres box domotiques ou d’autres systèmes : pour le moment nous ne supportons que Vera et ZiBase, mais nous souhaitons supporter d’autres systèmes, et pas forcément que des systèmes pûr domotique. Je ne peux pas encore vous dire lesquels ni quand mais c’est une volonté forte de notre part.
  • Poursuivre le développement de fonctionnalités communes à toutes les box (par exemple les graphes, une meilleure gestion des groupes, plus de possibilités sur le NFC, etc…)
  • Développer de nouveaux usages : en gros, nous pensons qu’une application de contrôle de maisons intelligentes doit elle aussi être intelligente :) (mais ça, on y reviendra une autre fois ;) )

 

Des feedbacks des feedbacks !

Et oui ! pour ceux qui souhaitent essayer l’appli, n’hésitez surtout pas à nous faire vos retours, positifs comme négatifs, bugs comme demandes de fonctionnalités : ça va beaucoup nous aider pour la suite car, comme vous l’avez compris : it’s only the beginning ;)

Le site web dédié : http://www.imperihome.com/

Le formulaire de contact, à utiliser pour les feedbacks ;) : http://www.imperihome.com/contact/

 

Et bien voila depuis novembre dernier que je n’avais rien posté ici, alors pour dissiper l’inquiétude de certains je me décide à donner quelques news de mes diverses geekeries récentes; oui parce-que contrairement aux apparences je n’ai pas QUE glandé pendant ces quelques mois ;) .

 

Sony SmartWatch

Ça n’aura pas échappé aux plus aware d’entre vous, la Sony SmartWatch est sortie il y a quelques semaines. J’avais déjà beaucoup hésité à prendre la montre RF de Texas Instruments il y a quelque temps puis j’avais renoncé; là je n’ai pas tenu, j’ai commandé la SmartWatch dès sa sortie.

Même si cette montre en elle même a un certain nombre de défauts (je détaillerai une autre fois si il y a des intéressés), le concept me semble vraiment intéressant et ouvrir plein de possibilités, notamment dans le domaine de la domotique encore une fois :) :

  • Etre notifié sur sa montre lorsqu’un évènement se produit dans la maison (quelqu’un sonne à la porte, alarme, inondation, appel en absence sur le fixe, plus de croquettes dans la gamelle du chat etc…)
  • Pouvoir agir sur son système domotique directement depuis sa montre. Et c’est là qu’il y a de nouveaux usages à développer, avec un vrai challenge : faire tenir des fonctionnalités domotique sur un si petit écran en restant pertinent et réactif : pas facile du tout ! (déjà qu’on a du mal à le faire sur une tablette ou un smartphone classique…). Et oui, on rejoint ce dont je parlais plus haut mais aucun intérêt si c’est pour mettre une liste de lumières à plat sur la montre, car il faudrait beaucoup trop de temps pour scroller et trouver la bonne qu’on souhaite allumer/éteindre; on a aussi vite fait d’aller direct à l’interrupteur sauf si on est vraiment une grosse feignasse mais c’est un autre problème.

Et donc, comme j’étais en plein dans le dev Android pour autre chose, j’ai aussi commencé à regarder ce qu’on pouvait faire avec la SmartWatch.

Premier besoin : les notifications génériques, première application en réponse : LiveNotifier (cf ci dessous)

 

LiveNotifier

Nous sommes nombreux à utiliser des systèmes de notifications push pour redescendre de l’information depuis notre système domotique vers nos précieux smartphones, fussent-ils Android ou iPhone. Parmi les applications offrant ce service on trouve par exemple Notifry, Notifo, NotifyMyAndroid, Pushme.to, etc etc…

Or il n’existe pas de telle application qui soit capable d’afficher ces notifications génériques directement sur la montre SmartWatch. J’ai donc développé LiveNotifier dans ce but.

Ca s’utilise un peu comme Notifry, ça permet de faire de la notification ‘normale’ comme le font les autres applis, à quelques différences près, notamment :

  • Quand on a une SmartWatch et ben c’est compatible et ça envoie aussi les notifications dessus (mais l’appli fonctionne aussi très bien si on a pas de smartwatch)
  • Ca permet d’associer une image à une notification (par exemple, je reçois la notification de sonnette au portail directement avec une photo prise par la camera qui va bien)

 

L’appli va continuer d’évoluer avec d’autre fonctionnalités (pas forcément que des fonctionnalités liés à la SmartWatch d’ailleurs) mais je vous garde la surprise :) (et d’ailleurs si vous avez des suggestions n’hésitez pas).

 

Pour les détails c’est sur le site dédié : http://www.livenotifier.net

Et le lien vers le play Store pour télécharger l’appli si vous voulez tester le tout :)

 

Aller à la prochaine ;)

 

 

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)…

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

  • HomeGuru 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
 Lien vers la demo Lien vers la demo d’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).

Cela faisait un moment que je souhaitais mesure la consommation d’eau de mon logement, mais j’avais été freiné par le coût de mise en place d’un système de télérelève pour intégration à mon installation domotiqe. En effet, il fallait acquérir le compteur d’eau à impulsions (75€), mais aussi le RFXMeter (70€) et RFXPulse (50 €), le tout devant être branché électriquement via un adaptateur secteur. Ca faisait quand même plus de 200€ le bazar pour suivre sa consommation d’eau… (sans compter évidemment le récepteur RFXCom que j’avais déjà)

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 !

J’en avais déjà parlé je crois dans un de mes précédents articles, j’ai développé pour mon système domotique une webapp.

Quoi que c’est donc une WebApp ? Et bien c’est à mi chemin entre un site web et une application pour device mobile (smartphone, tablette…). On peut le définir comme un site web qui se comporte comme une application, ou bien commune une application mais programmée avec les languages du web (HTML5/CSS/JavaScript).

 

Dans la pratique, ça fonctionne en allant sur l’URL depuis le browser de votre smartphone, et ça chargera la WebApp.

Probleme : évidemment, ça demande au browser de charger les fichiers (lent), et si vous n’avez pas de réseau WiFi ni de 3G, et bien votre webapp ne chargera pas.

 

Tout problème ayant sa solution, il existe un certain nombre de frameworks permattant de convertir un site web (ou webapp) en vraie application pour mobile. Celui que j’utilise s’appelle PhoneGap, et il comporte un certain nombre d’avantages :

  • il est entièrement opensource
  • il supporte 7 plateformes ! Ce qui vous permet de transformer votre WebApp (sans la modifier) en applications pour : iOS, Android, Symbian, BlackBerry, WindowsPhone, webOS et bada.
  • il supporte très bien le framework Sencha Touch (qui est celui que j’utilise)
  • il est simple d’utilisation et bien documenté

Voici ci-dessous une video d’introduction à PhoneGap :

 

Pour finir, un service proposé par PhoneGap que je trouve complètement génial : PhoneGap Build

Il s’agit d’un service hébergé sur les serveurs de Nitobi (l’éditeur de PhoneGap) et qui s’occupe pour vous de toute la partie compilation et packaging des applications (qui peut s’avérer très fastidieuse), tout ce qu’il faut faire c’est uploader le code de votre webapp et PhoneGap Build fait le reste et vous fournit les fichiers d’application (un apk pour android, etc…) !

 

Plus besoin d’avoir installé chez vous les environnements de compilation de chaque plateforme (et plus besoin d ‘avoir un XCode à disposition en permanence pour compiler pour iOS :D ) bref c’est vraiment confortable et ça marche plutot bien, malgré le fait que ce soit encore en beta.

 

A noter que Nitobi, la société créatrice de PhoneGap, a été rachetée récemment par la mastodonte Adobe. Cela ne semble pas remettre en cause l’ouverture de PhoneGap (et espérons que cela reste ainsi).

 

Et vous, vous utilisez ce genre de framework ?

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

Les premiers jours de pluie arrivant, il est temps de se replonger un peu dans son installation domotique, et d’y apporter les quelques modifications auxquelles on a pensé cet été !

De mon côté l’été s’est traduit par l’arrivée à la maison de mes premiers devices sous Android, et comme j’utilisais dans mon installation xPL les notifications push Prowl (Cf : http://www.poulpy.com/2011/02/les-notifications-push-prowl-et-pushme-to-en-xpl/), j’en ai été privé (et oui, Prowl et Pushme.to ne fonctionnent actuellement que sous iOS, pas sous Android).

 

Je me suis mis en quête de systèmes de notification pour Android et j’en ai trouvé deux :

 

Pour intégrer ces systèmes dans mon réseau xPL, j’ai donc fait évoluer mon agent xPL de notification (xPL-PushMsg) pour y ajouter le support de ces deux nouveaux systèmes, qui viennent donc s’ajouter à Prowl et Pushme.to.

 

Il s’agit de la version 0.3 de xPL-PushMsg (toujours en perl avec le framework xpl-perl). Téléchargement par ici !

 

Vous retours sont, comme toujours, les bienvenus !


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 possesseurs de Nabaztag l’auront bien remarqué : difficile ces derniers temps de « suivre le lapin blanc », et ce depuis plusieurs jours.

Ce fameux lapin qui fait partie de ma collection spéciale « inutile mais indispensable » reste désespérément inerte, il ne parle plus, et ne se connecte même plus à l’écosystème nabaztag… Le site web nabaztag.com est lui aussi complètement mort, tout comme les autres sites associés www.violet.net, my.violet.net…


N’ayant aucune nouvelle par e-mail, j’ai quand même fini par chercher un peu ce qu’il se passait, et il s’agit en fait d’une migration d’infrastructure qui s’est -très- mal passée chez Mindscape (pour rappel Mindscape avait en 2009 racheté Violet, société créatrice du nabaztag qui était alors en grande difficulté financière).

Mindscape communique assez régulièrement sur cet incident, mais ils le font sur le blog du Karotz (successeur du nabaztag). Vous pouvez aller voir les détails sur leur blog; mais grosso modo, lors du déménagement des infrastructures nabaztag, un des 25 serveurs n’a pas redémarré et ça a mis en rade la totalité ou presque de l’écosystème. Voila maintenant plusieurs jours que les techniciens de Mindscape tentent de remonter le service, et ce sans succès pour le moment. Mindscape a communiqué aujourd’hui que la réparation allait probablement au moins durer encore la totalité du weekend).

(pour les détails techniques : il s’agit apparemment d’un array RAID qui a fait pschiiit)


Outre le fait que ce lapin inerte fait vraiment peine à voir dans mon salon depuis quelques jours, quelles conclusions peut-on -tenter d’- en tirer ? :

  • Les objets communicants, et autres devices connectés en permanence c’est super et ça a plein d’avantages, mais quand on est à 100% dépendant de la connexion et de l’infrastructure en face, cela comporte des risques et on le voit bien là.
  • On comprend bien l’intérêt que les objets soient connecté à un écosystème, mais sa défaillance ne doit pas les transformer en vulgaire presse-papier ! Comment ? :
    • En diffusant le code du serveur nabaztag, ou en publiant le protocole de communication utilisé : vœux pieux peut-être mais cela permettrait à une communauté de développeurs de créer autour du lapin et d’offrir des alternatives. En dehors de ça, cela assurerait une survie des objets déjà vendus si jamais la société coule (ce que personne ne lui souhaite soyons clairs !)
    • En prévoyant ces pannes : l’objet, lorsqu’il est déconnecté (quelle qu’en soit la raison), devrait pouvoir fonctionner, même si c’est en mode dégradé, avec des fonctionnalités en moins. (Pour prendre un exemple dans le domaine de la domotique, une ZiBase, si elle était privée d’internet, continuerait de fonctionner sans problème, il n’y aurait que l’aspect configuration qui serait indisponible).


On peut comprendre que Mindscape ait eu des difficultés à reprendre les infras et architectures de Violet, même si il est difficilement compréhensible, dans le monde des services grand public sur le net, qu’on ne puisse pas du tout remonter un service en 1 semaine (pour moi… quand on a plus de 150.000 utilisateurs quotidiens, même si on a pas un zouli PRA bien huilé, on fait en sorte d’avoir au moins un backup exploitable et une machine de spare).

Cela ayant inquiété pas mal les futurs acquéreurs du Karotz, Mindscape communique également sur le fait que ce nouveau lapin fonctionnera sur des infrastructures complètement différentes, que l’on peut espérer être plus tolérantes aux pannes. Autre détail d’importance : nos ‘vieux’ nabaztag seront à terme migrés sur la nouvelle infrastructure Karotz, qui devrait offrir une meilleure qualité de service.


Aller je conclus : malgré une gestion de l’incident qui semble, vu de loin, très perfectible; on peut quand même saluer la transparence des communications de Mindscape (même si perso j’aurai préféré les recevoir par mail plutôt que de devoir aller chercher sur le net); et souhaiter bon courage aux tekos mobilisés, en espérant un retour au plus vite à la normale !