#The Dollhouse Challenge

Tout Papa (ou maman!) d’une petite princesse s’est un jour demandé s’il pouvait lui fabriquer un maison de poupée et les exemples ne manquent pas.

Au début de l’année, ma princesse a reçu comme cadeau une toute petite maison Sylvanian Families, ainsi que beaucoup trop de meubles…du coup je me suis demandé si je pouvais aussi me lancer dans l’aventure et fabriquer une modeste maison moi aussi.

Planification, achats et premières découpes

En bon ingénieur geek, après avoir consulté de multiples blogs, j’ai commencé par tracer les plans et à réunir les matériaux.

J’ai prévu une maison modulable en deux parties: une en longueur avec une mezzanine et l’autre en hauteur pour donner un peu de relief avec un petit balcon. Une terrasse extérieure complétera le tout.

Pour gagner du temps, j’ai décidé de réutiliser des caisses en bois de vin pour faire les différentes pièces de la maison et j’ai complété avec des jouets de récupération (le célèbre chalet en bois de JeuJura pour les fenêtres notamment) et quelques produits de bricolage (colle, peinture…)

Création des fenêtres

La découpe des fenêtres se fait classiquement avec la perceuse afin d’avoir des trous suffisants pour passer une scie sauteuse…et une mauvaise surprise avec le bois des caisses trop dur et friable…les constructeurs de caisse à vin n’ont sûrement pas anticipé cette utilisation !

Entrée du “terrier”

Une maison sans entrée ce n’est pas une maison (dixit les enfants)…

Fondations posées

Le gros œuvre est terminé, il ne reste “plus” qu’à peindre et comme pour une maison taille réelle c’est ce qui prend le plus de temps…

Peintures & Sols

Chaque pièce est finalement peinte d’une couleur différente, avec des sols en carton collés et de l’herbe synthétique pour la terrasse.

Place à l’action

Une fois les meubles et différents éléments de décoration posés dans la maison, ma petite princesse peut jouer et s’inventer son monde.

#A bot to rule them all

Un Anneau pour les gouverner tous

Un Anneau pour les trouver

Un Anneau pour les amener tous […]

– J. R. R. Tolkien, Le seigneurs des anneaux

Pour des raisons de sécurité, j’ai décidé de n’avoir aucun accès de l’extérieur vers mes éléments de domotique, avec toutefois un inconvénient majeur: aucun moyen de consulter les diverses données ou de lancer des actions.

Pour résoudre ce problème j’ai tenté plusieurs approches à base de tableaux de bord dashing ou de solutions maison comme proxana mais qui ne m’ont jamais vraiment convaincues pour mon cas d’usage.

De l’usage d’un bot pour la domotique

Et j’ai commencé à m’intéresser aux bots de type Hubot et à leur utilité pour finalement créer mon propre bot nomméGoule.

Goule est un service écrit en langage Go, basé sur mon système domotique déjà en place (InfluxDB et NodeRed) et utilisant l’infrastructure de Telegram pour me permettre de lancer des actions domotiques, du type “quelle est la température chez moi?”, sans risque sur la sécurité de mon système.

Une capture d’écran étant toujours plus simple que des mots, cela donne donc:

Dans les coulisses de Goule

Pour développer Goule en langage Go (décidemment j’aime beaucoup ce langage), je me suis appuyé de façon classique sur des librairies existantes notamment telegram-bot-api pour se connecter à Telegram ainsi que la librairie native pour influxdb. La seule difficulté rencontrée a été le formatage des données renvoyées par influxdb, qui nécessite de fouiller un peu dans les API.

const (
    username = "grafana"
    password = "paint"
    addr = "http://obelix:8086"
)
# Crée la requete et l'envoie à InfluxDB, renvoie le résultat
func queryDB(cmd string, MyDB string) (res []client.Result, err error) {

    log.Printf("Connection à influxDB")
    clnt, err := client.NewHTTPClient(client.HTTPConfig{
        Addr: addr,
        Username: username,
        Password: password,
    })
    if err != nil {
        log.Fatalln("Error: ", err)
    }
    q := client.Query{
        Command:  cmd,
        Database: MyDB,
    }
    response, err := clnt.Query(q)
    if err != nil {
        log.Fatalln("Error: ", err)
    }
    if response.Error() != nil {
        log.Fatalln("Error: ", response.Error())
    }
    res = response.Results
    log.Println(response.Results)
    return res, nil
}
# Récupère la consommation électrique dans influxDB
func getConsoElectrique() string {
    q := fmt.Sprintf("SELECT * FROM energy ORDER BY time DESC LIMIT 1")
    res, err := queryDB(q,"electricity")
    if err != nil {
        log.Fatal("Error: ",err)
    }
    day_energy := res[0].Series[0].Values[0][1].(json.Number).String()
    instant_energy := res[0].Series[0].Values[0][2].(json.Number).String()

    return fmt.Sprintf("Actuellement la consommation instantanée est de *%sW* et le cumul est de *%skW*.",instant_energy,day_energy)
}

Le point d’attention étant sur la manipulation des résultats, avec des tableaux dans tous les sens, et des transformations JSON à faire comme pour récupérer la consommation quotidienne: day_energy := res[0].Series[0].Values[0][1].(json.Number).String()

Containers are the new black

Finalement pour faire tourner tout cela simplement (et tenter quelque chose de différent), j’ai utilisé un container docker construit directement à partir du container Golang officiel et en m’appuyant sur l’article de Jérôme Petazzoni, avec les commandes suivantes:

# téléchargement de l'image et des librairies + compilation de goule
docker run golang go get -v github.com/jraigneau/goule
# Transformation en image docker nommé goule
docker commit $(docker ps -lq) goule
# Lancement du programme goule dans l'image goule en mode "daemon" à partir du containter goule
docker run --restart=always --name goule -it -d goule goule

Cela me permet d’avoir un “service” qui tourne sur ma VM principale dédiée aux containers, isolée des autres containers, avec une relance automatique en cas de problème (notamment coupure intempestive de ma ligne internet, ce qui est arrivé).

J’utilise ce système depuis un mois environ, et étant donné sa fiabilité je vais surement l’étendre à d’autres fonctions de ma domotique dans le futur.

#Godillot, une alternative à M/Monit

Suite à une coupure de courant le mois dernier, suffisamment longue pour vider la batterie de l’UPS, mes systèmes ont tous redémarrés automatiquement - ou du moins je le croyais jusqu’à ce que je me rende compte quelques jours plus tard que la base influxDB ne tournait plus, plantée suite à la coupure.

Après avoir réparé cette base de donnée (et avoir mis en oeuvre un vrai système de backup sur les data influxdb…), j’ai décidé d’installer un système de monitoring simple des processus avec Monit.

Monit. est un agent qui vérifie régulièrement les processus (Existence, Consommation, Code erreur), et envoie des alertes en cas de problèmes…bref rien de plus que Nagios ou New Relic, sauf que Monit. peut aussi lancer des actions comme relancer les processus en cas de problèmes ou de dépassement de seuil. Dans le cas d’une infrastructure peu administrée/monitorée comme la mienne cela devient très intéressant pour automatiser et se faciliter la vie.

Toutefois, Monit a un inconvénient majeur: pour avoir une vision globale de l’état de l’ensemble des serveurs il faut utiliser M/Monit qui est payant.

Aussi, j’ai développé en langage Go une mini application appelée Godillot qui récupère les informations Monit de chaque serveur et les agrège dans un fichier html simple à lire comme vous pourrez le voir en exemple. Godillot n’a pas vocation à remplacer M/Monit qui est très complet mais permet d’assurer un minimum de surveillance via u tableau de bord.

Godillot est bien entendu disponible en open-source (Licence Apache), directement sur Github, pour utilisation, modification (je ne suis pas fier du template html) et commentaires à votre convenance !

#Remplacement de emoncms par Grafana+influxDB

Utilisateur de emoncms comme solution de métrologie de mon installation domotique depuis quelques mois, j’ai décidé dernièrement de basculer sur une solution moins spécialisée et beaucoup plus ouverte, basée sur influxDB pour la partie stockage des données et sur le superbe Grafana pour la partie affichage des indicateurs.

InfluxDB est une base de donnée permettant de stocker des données chronologiques (Time series en anglais), avec intégration de fonctions mathématiques simples (min/max, moyenne…), et un langage de requêtage proche du SQL et simple à utiliser.

Grafana est, quant à lui, un visualiseur de données, pouvant se connecter à Graphite, influxDB, openTSDB…afin de créer des tableaux de bord composés de graphiques ou de données brutes avec des possibilités avancées de corrélation.

L’installation de ces deux outils se fait très facilement (le classique `sudo apt-get sur ubuntu) et le paramétrage est aussi simple (du moins pour une installation comme la mienne) - aussi je ne n’épiloguerai pas dessus (en bref utilisation de nodered ou de scripts bash pour récupérer les données puis envoi en POST via l’API influxDB, rien d’exotique).

Ainsi en quelques minutes, j’ai pu obtenir des tableaux de bord sur différents types de données, tant domotique qu’informatique, eg:

Consommation électrique

Traffic internet sur ma box

Pour conclure, ce qui me satisfait le plus dans cette solution c’est la possibilité de mettre n’importe quelle donnée en très peu de temps: utile parfois pour du troubleshooting.

#Premiers pas en domotique

J’ai décidé l’année dernière de me lancer dans l’aventure de la domotique, avec pleins d’idées en tête sur la sécurité et la détection, les mesures de température, l’optimisation de la consommation de l’énergie, le contrôle des lampes et autres, et plus globalement l’automatisation.

Étude préalable

En m’intéressant à ce domaine, j’ai découvert d’une part sa richesse et d’autre part le nombre très important de protocoles, les différentes box domotiques plus ou moins compatibles, les prix (élevés) des différents composants.

Par ailleurs, ce domaine est à la fois très récent et assez ancien et nécessite des connaissances en électronique, électricité, informatique avec une notion forte d’intégration de composants et systèmes entre eux… ce qui rend le sujet d’autant plus intéressant.

J’en ai tiré plusieurs postulats et décisions sur la suite des événements.

Postulats / Choix

Le matériel de contrôle de la bureautique pouvant être envahissant, j’ai décidé en premier lieu de me créer mon propre espace pour le matériel.

Utilisateur heureux de l’open-source depuis plusieurs années, j’ai choisi de faire ma propre box domotique open-source en me basant sur l’application domoticz pour le cœur du système et en rajoutant au fur et à mesure des applications dédiées par fonction (Surveillance, Graph, Ordonnancement).

Toutes ces applications sont installées sur des machines virtuelles Ubuntu/Linux sur un ESX VMware. L’ESX est le seul élément non open-source, choisi par rapport à mes expériences professionnelles, mais j’aurai pu (dû?) choisir à la place XEN.

Le dernier choix important a été pour moi d’isoler complètement la maison: aucun des systèmes domestiques n’est accessible de l’extérieur afin d’éviter tout piratage qui pourrait être particulièrement grave.

Mesurer pour contrôler

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it — Dr. H. James Harrington

Un premier point important de la domotique est la mesure, selon l’adage On ne contrôle que ce qu’on peut mesurer. Il faut donc prévoir les capteurs (avec par exemple les mesures de température via des Oregon Scientific THN 132) et surtout l’infrastructure de collecte des données.

Dans mon cas, j’ai choisi de mettre en œuvre emoncms, qui me permet d’agréger l’ensemble des données et d’en tirer des tableaux de bord très lisibles.

Évidemment, ces tableaux de bord ne sont pas accessibles de l’extérieur comme définit précédemment: j’ai donc mis en œuvre une copie des données temps réel vers l’extérieur, via un simple push vers un tableau de bord type dashing hébergé chez Heroku.

Intégration des systèmes

Pour bien gérer “l’internet of things” et mixer les services logiciels, les objets connectés, et les différents capteurs, j’ai par ailleurs installé node-red, qui est développé par IBM.

Node-red permet de créer des workflows entre objet pour les faire interagir entre eux simple, le tout via une IHM web. Ces workflows permettent via un peu de développement très simple en javascript d’analyser des flux de données venant de sondes ou de services, de les transformer avant de les renvoyer vers d’autres sondes ou services.

Ainsi, j’ai pu créer des flux pour récupérer les données de la box domotique avant de les envoyer vers emoncms et d’en faire des graphiques et des premières analyses.

Réalisations actuelles - plutôt orientées mesures

Ces derniers mois, je me suis attaché à mettre en œuvre les différents points de mesure, avec notamment:

• Mesures de la température dans toutes les pièces de vie (Chambres, Salon) via des sondes Oregon Scientific
• Récupération de la consommation électrique directement sur le compteur avec une pince ampérométrique de chez OWL

J’ai par ailleurs commencé à installer des caméras intérieures pour la vidéosurveillance, avec motion et motioneye pour gérer les détections et l’enregistrement des films. Ces films sont enregistrés à la fois en local et sur une DropBox dédiée en cas de coupure (ou disparition du disque dur…)

Réalisations à venir ou qui reste à étudier

Le champ des possibles de la domotique est impressionnant et j’imagine par exemple mettre en œuvre d’autres activités comme:

• Contrôle automatique des lumières du jardin selon l’heure de la journée.
• Mise en œuvre d’un contrôle vocal type S.A.R.A.H
• Extension de la vidéo surveillance à l’extérieure, avec déclenchement d’actions suite à des événements
• Mesure de l’humidité dans la salle de douche pour allumer/éteindre la VMC
• Contrôle des radiateurs via boutons électroniques
• Détection des lumières laissées allumées par les enfants
• Automatisation des fermetures de volets
• envoi d’information via SMS
• …. Bref, de quoi s’occuper quelques temps !