ha-bridge howto (Alexa, la suite !)

De quoi on parle ?

L’idée ici et de pouvoir faire faire n’importe quoi (ou presque) à n’importe quoi. Autrement dit, interconnecter des systèmes domotiques qui ne savent nativement pas dialoguer ensemble.

Le principe est de simuler un équipement simple, commun, et reconnu par la majorité des équipements domotique, à savoir une lampe Phillips Hue. Alexa, Google home, Siri, un hub Harmony etc… Tous ces équipements savent piloter une lampe Hue. Mais ils ne sauront pas forcément piloter votre aspirateur, votre vidéo projecteur, vos volets roulants ou certains équipements hi-fi.

Comment ?

Bien évidement, et avant même de penser à interconnecter quoi que ce soit, vous devez déjà disposer d’un moyen de contrôler votre équipement « cible ». Soit parce que vous avez une box domotique* avec les bons plugin soit parce que vous avez lu la doc, et que vous connaissez la bonne commande (http ou autre) à envoyer à l’équipement pour lui faire faire ce que vous désirez.

*Jeedom dans mon cas, ce logiciel est génial. Si vous ne savez pas quoi choisir en matière de domotique opensource, ne cherchez plus, c’est ce logiciel qu’il vous faut. Je n’ai jamais rien vu de plus complet, ce truc peut vraiment s’interfacer avec n’importe quoi.

Dans la suite de ce howto je partirai du principe que vous souhaitez lancer un scénario Jeedom. Mais encore une fois, n’importe quelle autre action pourrait être effectuée (lancement d’un script shell etc). La documentation d’installation est très bien faite, je ne vais donc pas trop passer de temps dessus. Juste vous montrer une astuce pour le lancer sans soucis sur un serveur sur lequel vous avez déjà des trucs qui tournent. (Même un un raspberry suffira très largement). La ou j’ai trouvé la doc un peu légère, c’est sur la partie « administration graphique via l’IHM web ». C’est donc sur ce point que je détaillerai un peu plus.

Installer ha-bridge

ha-bridge est un logiciel java monolithique, utilisant peu de mémoire (le processus utilise 72 Mo de mémoire chez moi) et vraiment rien en cpu. Le binaire est téléchargeable ici. Je vous invite aussi bien sur à jeter un coup d’œil à la doc la.

Si vous n’avez pas java sur la machine qui fera tourner ha-bridge, vous savez ce qu’il vous reste à faire… (java version 8 minimum).  Si rien d’autre ne tourne sur cette machine (pas de serveur web ou autre, alors pas de soucis, il suffira de lancer le logiciel pour qu’il se mette en écoute sur le port 80. Toute la configuration se fait ensuite au travers d’une interface web.

En revanche, si comme moi vous avez déjà des processus en écoute (jeedom…) alors il va falloir commencer par faire quelques modifications réseaux. Même s’il est possible de faire écouter ha-bridge sur un autre port, j’ai trouvé beaucoup plus propre de lui créer une interface réseau spécifique, avec une nouvelle adresse IP. Ainsi, le logiciel peut se mettre en écoute sur n’importe quoi, sans déranger les autres processus qui tourne sur l’IP principale du serveur. (Je ne connais pas forcément tous les ports utilisés par Philips Hue, et ha-bridge est aussi amené à évoluer donc… C’est plus de travail maintenant, mais beaucoup moins d’ennuis potentiels par la suite).

La première chose à faire et d’assigner une nouvelle adresse IP à votre interface réseau. Chez moi j’ai fait au plus simple, en ajoutant simplement à la fin du fichier /etc/rc.local la ligne suivante :

 ip addr add 192.168.30.248/24 dev eth0

Une ligne qu’il faudra évidement adapter en fonction de votre configuration réseau. Ici j’ajoute l’IP en .248, sachant que bien sur cette IP n’existe nul part ailleurs dans mon lan.

Une fois cette IP existante vous devrez modifier la configuration des logiciels qui tournent déjà pour les restreindre à utiliser l’ip principale de la machine (la première), et a ne surtout rien « binder » sur celle ci. Pour apache par exemple, c’est dans le fichier /etc/apache2/ports.conf qu’il faudra remplacer les * par l’IP sur laquelle vous voulez que le serveur écoute. Ainsi la directive Listen *:80 deviendra par exemple:

Listen 192.168.30.247:80

Une fois cette modification effectuée pour tous vos logiciels (et que tout à bien redémarré) vous pouvez maintenant lancer ha-bridge… Sans oublier de lui indiquer à lui aussi quelle IP il doit utiliser (la seconde donc, celle en 248… Tout le monde suit ?)

Pour ça rien de plus simple, il suffit de lire la doc:

java -jar -Dserver.ip=192.168.30.248 ha-bridge-W.X.Y.jar

Si tout s’est bien passé vous aurez alors accès à son interface web sur http://192.168.0.248. Mais stopper le pour le moment et finissez le travail, en allant par exemple éditer le fichier de configuration qu’il à du créer dans data/habridge.config. Vous pouvez par exemple lui indiquer la bonne IP dans ce fichier, ainsi que plein d’autres chose (cf la doc, toujours…).

Vous devriez aussi créer un véritable service systemd, afin de pouvoir contrôler l’ensemble (start/stop/status) de façon beaucoup plus propre qu’avec des kills ou des control-c… Cela vous permettra aussi de faire en sorte qu’ha-bridge soit automatiquement lancé au boot de la machine. Pour ça… Oui bien sur ! La doc, comme d’habitude 🙂

Paramétrer ha-bridge

C’est cette partie la qui m’a demandé le plus de temps… Pas parce qu’elle serait compliquée, mais parce qu’il y a plein de boutons partout, et assez peu de documentation disponible je trouve…

Voyons donc l’interface:

Le premier onglet, Bridge Devices, liste les « lampes » actuellement configurées. (Cette liste sera bien sur vide au départ). Le second onglet permet de configurer le « bridge » (autrement dit le logiciel qui se fait passer pour un « pont » Philips). L’onglet « logs » se passe de commentaire. Quand à « Add/Edit » il permet de créer une nouvelle lampe.

Avant toute chose il est très important de sécuriser cette interface. En effet, elle permet de lancer des scripts avec les droits du processus, donc root. (les droits root étant nécessaires pour se mettre en écoute sur les ports <1024). Bref, quiconque ose défier la puissance de dieu accède à cette interface est immédiatement root sur votre serveur ! Pour sécuriser un minimum, aller dans l’onglet Bridge Control, et appuyer sur « update Security Setting ». Choisissez un login et un mot de passe.

Ici vous trouverez tous les paramètres globaux du pont, ainsi que la possibilité d’indiquer l’IP de chacun de vos équipements (Harmny, Hue, Fibaro, Somfy, Nest, LifX, Domoticz, Alexa, Vera etc, etc). Personnellement je n’ai absolument rien rempli de tout ça. Et surtout pas la ligne « Hue » dont l’existence est pour moi un vrai mystère. Apparemment l’idée est de pouvoir utiliser ha-bridge comme une sorte de proxy relai… Un équipement quelconque enverrai une commande à ha-bridge pensant avoir à faire au véritable pont Philips, et ha-bridge pourrait alors effectuer des actions (scripts shell etc) puis transférer la commande au véritable pont Hue pour finaliser l’exécution (et allumer la bonne lampe par exemple).  Je doute que beaucoup de gens aient besoin de cette fonction mais bon.. C’est possible 🙂

Globalement les seules choses que j’ai modifié dans cet écran sont :

  • UPNP IP Address : Indiquer l’IP sur laquelle écoute ha-bridge
  • Use UPNP Address Interface Only TRUE (pas question de se mettre en écoute sur l’autre IP)
  • Use Rooms for Alexa : TRUE (car je l’utilise et que cela permet de localiser les équipements)
  • Web Server IP Address : Encore la même IP
  •  My Echo URL (tout dernier paramètre): alexa.amazon.com/spa/index.html

Ce dernier ne sert pas à grand chose, juste à modifier l’url qui sera ouverte si vous cliquer sur l’onglet « My echo » dans le menu du haut de ha-bridge. Aucun intérêt bien sur si vous n’avez pas d’enceintes Amazon chez vous (et même si vous en avez… bref).

Ajouter un nouvel équipement virtuel

Il est temps d’entrer dans le vif du sujet, et de créer un équipement. Prenons ici l’exemple de volets roulants. Je dispose donc d’au moins deux scénarios sous Jeedom. Un pour ouvrir tous les volets de la pièce, et un autre pour les fermer. (On parlera sûrement de Jeedom dans un autre billet, la ce n’est pas le sujet). Bref, l’appel d’une simple URL avec les bons paramètres permet d’effectuer ces actions.  Appuyer sur le bouton Add/Edit (pour tous les équipements suivants vous pourrez beaucoup plus simplement dupliquer un équipement déjà existant).

Donner un nom à votre nouvel équipement. Par exemple « volets-salon ». Puis tout en bas de la page, vous pouvez définir les actions à effectuer pour répondre aux quatre type de commandes reconnues par les lampes Hue :

  • Allumer la lumière
  • Régler la puissance lumineuse (DIM)
  • Éteindre la lumière
  • Changer la couleur

Dans « MAP Type », vous pouvez indiquer HTTP Device (je ne suis même pas sur que ce soit indispensable). Ensuite, vous pouvez indiquer vos URL, après avoir bien choisi le type « HTTP Device ». Absolument tout est paramétrable, mais dans mon cas les options par défaut (commande de type GET etc) conviennent parfaitement.

Dans cet exemple, j’ai indiqué l’url permettant d’ouvrir les volets dans deux cas : Sur la commande ON et sur la commande DIM, pour la raison suivante :

Si on ouvre les volets « allume la lumière » une première fois, l’état de cette « lampe » est conservée dans Jeedom. Et si l’équipement qui pilote (Alexa ou autre) demande un status, il verra donc que la lampe est déjà allumé. Une nouvelle demande risque donc de ne pas se traduite par l’envoi de la commande ON, mais par le simple envoi par exemple d’une mise à jour de l’intensité (Commande Dim). Le plus simple est donc d’envoyer le scénario dans les deux cas.

Souvent vous n’aurez besoin que d’une seule commande. Par exemple si vous voulez changer la source de votre ampli audio-vidéo. Il n’y a pas de « on » ou de « off ». Juste une commande à lancer sur un « on ».

Une fois que votre équipement (votre « fausse lampe ») est logiciellement active, vous pouvez alors la détecter à partir de votre équipement « pilote ». Dans mon cas une enceinte Alexa sur laquelle je lance une nouvelle détection des équipements connectés. Une nouvelle lampe appelée « volets-salon » est très vite trouvée dans l’application. On peut alors facilement la tester : Si on l’allume, les volets se montent. Si on l’éteint, les volets se baissent. Ce n’est pas magique… Mais presque.

La touche finale

La bien sur, vous aller me faire la remarque : Avec le contrôle vocal c’est forcément tout pourri, ça veut dire que tu dois demander « Alexa, allume la lumière Volets-Salon » pour ouvrir les volets !?.

Alors oui, mais non. A la base, oui, c’est l’idée… Pour Alexa, c’est une lampe et rien d’autre. Et oui, forcément, devoir dire « Alexa, allume la lumière Ampli-sur-DVD » pour passer l’ampli sur DVD, c’est n’importe quoi. Mais c’est (entre autre) à ça que servent les « routines ». Il est ainsi possible de faire faire n’importe quoi à Alexa sur des phrases clefs précises. Comme par exemple de lui faire « allumer la lumière Volets-Salon » si elle entend la phrase « Ouvre les volets du salon ». Beaucoup mieux non ?

4 commentaires

  1. contant Répondre

    Bonjour,

    malgré tes conseilles quand je lance la commande java -jar -Dserver.ip=192.168.30.248 ha-bridge-W.X.Y.jar je suis toujours en erreur a cause du port 80.

    • hoper Auteur de l’articleRépondre

      Bonjour,

      L’ip que j’ai donné n’était évidement qu’un exemple…
      Quelle addresse IP utilise tu ? Que donne par exemple le résultat de la commande : ip addr show
      Y a t-il d’autres logiciels lancés en écoute sur le port 80 ? (apache, nginx…)
      Quel est le message d’erreur exactement ?

  2. Ping : Alexa et le pilotage local des lampes Hue – ATDC

  3. Ping : Test des prises connectées DiO – ATDC

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.