Sommaire
Préambule
Il y a quelques deux ans de ca, j'ai parlé de mon système domotique maison à base d'API REST et de client Web avec plein de JQuery dedans.
Depuis, j'ai continué ce projet avec entrain, et il en est maintenant dans sa 3e génération: Angharad sur Github
Pourquoi 3e génération et pas version 3.0 ? Parce que au début c'était pas mal un serveur autonome, mais avec le temps c'est devenu un d'ensemble de logiciels qui forment un écosystème et se parlent entre eux via des protocoles ad hoc.
Pourquoi j'ai pas parlé de la 2e génération ? Surtout parce qu'elle n'est pas venue en une seule fois, les idées et les améliorations sont venues petit à petit pendant l'année qui a suivi mon premier journal. Les principales améliorations ont été l'ajout du support de Z-Wave, l'ajout de webservices en PHP pour gérer les photos et les flux d'une instance Motion et les lecteurs de musique avec mpd.
Cheminement
Puis je voyais Angularjs, et je voyais aussi que mes API REST étaient quand même pas super propres: que du status 200, même en cas d'erreur, et je me disais que supporter une autre base de données, normaliser par ci, uniformiser par là aurait été pas mal.
Et puis je me demandais si les service annexes, caméra et musique, pouvaient être intégrés facilement à mon idée de serveur d'API REST en C, parce que j'aime bien le C.
Et j'ai commencé un nouveau module pour brancher un capteur de température à un RPi et y accéder avec une API REST, et j'ai trouvé que même en réutilisant mon code, c'était long et fastidueux pour coder un simple webservice.
J'en ai donc commencé par faire des lirairies qui me faciliteraient la manipulation des requêtes HTTP (celui-là j'en ai déjà parlé y'a pas long), les logs, ou encore les requêtes SQL.
J'ai pas inventé l'eau chaude non plus, mais quand je cherchais des librairies existantes, j'en trouvais pas qui me paraissaient simples, efficaces, et pas trop lourdes.
Angharad, ca fait quoi concrètement ?
Ca gère les lumières, les thermostats, les interrupteurs, les capteurs, les images des caméras, la musique. Ca automatise tout ca avec des scripts et des tâches planifiées, ca gère des alertes, et ca monitore les données aussi.
Domotique pure
Pour la partie domotique pure (lumières, interrupteurs, thermostats, capteurs), ca gère le protocole Z-Wave via la librairie Openzwave et une clé usb Z-Wave.
Ca gère aussi le protocole Taulas qui est une évolution du protocole de communication que j'avais mis en place avec les Arduinos du début. Donc en utilisant des Arduinos ou autre chose, du moment que ca respecte le protocole, ca parle avec serveur.
On peut rajouter d'autres protocoles domotiques si ca nous chante, il "suffit" de programmer sa librairie qui implémente les bonnes fonctions, on la compile, on la copie dans le répertoire dédié, on recharge les modules avec l'API kivabien, et hop, on a un nouveau type de device sans même avoir à relancer le serveur grâce à la magie de dlopen/dlsync.
Autres services
There is no IOT, just devices dedicated to a simple task.
Pour les autres services (caméras, musique, etc.), on utilise un principe similaire avec des librairies compilées et chargées pendant l'exécution. Là, le système est plus permissif et autorise à créer ses propres API et faire ses propres accès à la BD.
Motion
Ca permet d'accéder au flux temps réel et aux images enregistrées par un service motion.
Pour accéder aux images, il faut que le serveur Angharad puisse accéder au répertoire sur lequel sont les images motion, donc un répertoire réseau ou quelque chose du genre.
Pour accéder au flux, on y accède directement grâce à l'url qu'on a fournie au service. J'ai essayé de proxyfier le flux MJPEG mais sans grand succès…
MPD
Chez moi, j'ai placé des Raspberry pi dans pas mal de pièces, branchées sur des haut-parleurs. La plupart du temps, j'y fais jouer une webradio locale que j'ai créé via liquidsoap et icecast. J'ai donc limité les commandes MPD à stop/play/pause, changer le volume, et lancer une playlist. Mais bon, lister les artistes, albums, chansons, fichiers serait pas hyper compliqué à gérer.
Liquidsoap
D'ailleurs, ladite webradio est un peu gérable elle aussi, on a accès aux infos des dix derniers morceaux joués, et on peut faire play/pause/stop/next sur la radio.
Application cliente
On gère sa maison via Sagremor qui est une application AngularJS 1.5 avec du Bootstrap dedans. Elle permet de manipuler toutes les API. Je ne suis pas très fort en ergonomie et encore moins en design eye candy, mais l'interface a l'air assez intuitive, au moins pour les commandes de base (allumer, éteindre, etc.), pour que ma blonde ou un invité s'en serve sans que j'ai à expliquer.
Pour le coté pratique, j'ai deux tablettes android Ubislate 7Ci, j'y ai collé un Firefox qui fait tourner l'application cliente, et je les ai placées à chaque entrée chez moi juste à coté de la porte.
J'ai toujours le projet de faire une application cliente Android, et maintenant que j'ai une machine un peu plus récente, j'ai pu m'y mettre. Parce que développer des applications Android quand on peut pas lancer l'émulateur Android sur sa machine, c'est pas facile…
Essaye donc!
C'est tout libre, les librairies sont LGPL, les programmes serveur GPL v3, l'appli client est sous licence MIT.
Je n'ai pas la prétention de faire mieux que les autres comme Domoticz ou Jeedom, juste d'avoir un serveur domotique qui réponde à mes besoins, et puis c'est un bon moyen d'apprendre des nouvelles technos et de tester des concepts.
J'aimerais bien fédérer des amateurs autour de ce projet, mais je ne sais pas trop par où commencer. Si il y a des curieux pour tester et participer, c'est avec plaisir!
# De quoi ca a l'air
Posté par Babelouest (site web personnel) . Évalué à 10.
Exemple d'écrans
# Avoir un serveur domotique qui réponde à MES besoins
Posté par vlad59 (site web personnel) . Évalué à 1.
Je viens de jeter un coup d'oeil et en fait je pense beaucoup de personnes se sont développées leur système de domotique à eux pour répondre à LEUR besoin spécifique.
J'ai commencé à développer le mien avec deux amis il y a 3 ans environ et maintenant nous avons 3 bases de code qui commencent à devenir très différentes car au final nous avons des besoins différents. Pourtant nous avions commencé en basant le tout sur du MQTT qui centralise tous les appels et de faire un maximum de micro service pour optimiser la réutilisation.
Dans mon cas j'ai démarré avec des arduinos + RFM12 maintenant c'est des ESP8266 ou des Moteino (pour les modules avec batterie) et le serveur est un joli Banana Pi qui héberge le serveur MQTT et les différents services (gestion de l'ampli yamaha, des Kodi, de la Freebox via l'API, de la détection de présence dans les différentes pièces, etc).
Par contre pas de caméra, de mpd ou d'autres choses.
En tout très bon boulot, bravo !
# intéressant
Posté par nouknouk (site web personnel) . Évalué à 3.
super initiative,
perso, je suis en plein démarrage d'une rénovation de maison, et la domotique y représentera une grosse partie. Côté 'hard', je pars sur du zwave (+serveur, redondance, etc…) + audio multiroom (rpi ?) + caméras ip + tout le reste pour le réseau, stockage, et multimédia.
Et justement côté soft, j'ai pas trouvé chaussure à mon pied en l'état. J'utilise bien Jeedom pour mes test préliminaires, mais même si la solution propose déjà beaucoup de choses qui prendraient un temps infini à vouloir refaire (rien que le support des spécificités des modules zwave….), elle ne me convient que moyennement, entre autre:
par son aspect qui me semble trop monolithique: pas de 'backend' totalement indépendant du frontend (web) apparemment.
par les possibilités en matière de 'scripting' (graphique) de scénarios qui semblent accessibles au grand public, mais foutrement pas efficientes comparé à la possibilité de se coder ses scénarios quand on code un peu.
J'envisage donc de partir sur un solution homemade mais perso je compte plutôt opter pour une base principalement en NodeJS, plutôt que du C:
parce qu'après 20 ans de c, c++, java, php et autres joyeusetés, moi j'aime bien m'amuser avec nodejs en ce moment.
parce que les besoins en ressources sont faibles, et les besoins en perfs sont pas critiques et que de ce côté là nodejs est très largement suffisant.
parce que l'existant en libs tierces chez node devient assez énorme: tu parlais de besoins d'outils pour faire (vite et bien) du REST, de la couche de persistance, etc… il y a du lourd maintenant chez eux).
et surtout parce ça apporte JS sur un plateau pour des possibilités de scripting de scénarios, y compris complexes (pour l'utilisateur qui sait un peu coder, évidemment).
Bref approche similaire, mais ma solution technique retenue sera sans doute un peu différente. Ta solution est tout de même très intéressante (et chapeau pour le taf accompli au passage). Je prendrai largement le temps de m'y plonger quand le moment sera venu.
Merci pour le partage.
[^] # Re: intéressant
Posté par Babelouest (site web personnel) . Évalué à 4. Dernière modification le 30 septembre 2016 à 15:07.
Bonne idée aussi,
En ce qui concerne les scénarios, je me souviens avoir voulu faire une gestion de scénarios au début, à base de séries d'actions à lancer itérativement, et le résultat d'une peut conditionner l'exécution du reste du scénario. Sauf que c'était pas facile à implémenter, et pour ne jamais l'utiliser aussi finement au final.
J'ai préféré changer d'approche et gérer la notion de scénarios en scripts qui lancent une série d'actions atomiques itérativement, et des événements qui sont déclenchés soit de manière programmée (tous les matins le réveil se met en marche), soit déclenchés par un événement extérieur (la lumière s'allume quand le détecteur de présence se déclenche).
Dans la dernière version, j'ai aussi ajouté des conditions optionnelles aux événements. Par exemple, le détecteur de présence déclenche l'événement, l'événement mesure la luminosité et lance le script si la luminosité est inférieure à un seuil -> quand je rentre chez moi la nuit, la lumière s'allume toute seule.
Peut-être que plus tard j'aurai besoin de scénarios plus complexes, mais je sais qu'à l'utilisation, ces fonctionnalités-là me suffisent amplement.
Pour le choix du langage, c'est une question de goût personnel, et de confort d'utilisation pour moi. Même si mon serveur domotique est un Odroid C1, je l'ai testé avec succès sur un Rpi Zero, vu que le programme serveur ne bouffe que 5 à 6 Mo en utilisation régulière. Je sais que plein d'autres langages fourmillent de frameworks que je n'aurais pas eu à redévelopper, mais c'est dans mon langage de prédilection qu'il manque d'outils comme ca.
Nodejs est une plateforme sympa, en cherchant vite fait, j'ai vu un add-on pour openzwave, donc les outils sont là, yapluka, bon courage :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.