La domotique du pauvre

Publié le 18 août 2010 par Olivier

Il y avait bien longtemps que je n’avais pas publié d’article sur ce blog, mais j’étais occupé entre autre à la réalisation d’une solution domotique pour la maison. Je vais donc vous présenter cette solution qui est le fruit d’une volonté écologique (réduire la consommation d’énergie, réutiliser des biens) et dont l’inspiration se situe entre la revue Système D et la série télé Mac Gyver.
Les clés d’entrées de ce projet étaient :
- La commande des volets roulants motorisés en fonction des heures de lever et de coucher du soleil.
- Le pilotage de prise électrique programmé ou à distance.
- La surveillance de la consommation générale d’électricité.
- Un système peu gourmand et autonome.
- Le cout le plus bas possible.
Les orientations technologiques :
- La lecture du signal de télé-information sur le compteur EDF permet d’obtenir des données intéressante pour la surveillance de la consommation d’électricité (La puissance instantanée, les compteurs Heures Pleines, Heures Creuses …). Ce signal est de type asynchrone à 1200 baud.
- Les volets roulants ont été motorisés au cours du printemps 2009, et la commande est centralisée par un dispositif composé de relais et commandé actuellement soit par un interrupteur Montée/Descente ou soit par un programmateur quotidien 2 canaux. (La description complète de cette installation fera sans doute l’objet d’un prochain article). Donc je m’oriente vers la commande par une carte relais qui sera mis en parallèle des 2 sources de commande actuelles.
- Pour le pilotage des prises de courant, c’est le cout qui va m’orienter technologiquement. Le CPL (X10) étant hors de prix, environ 60 euros par prise, je décide donc d’utiliser une solution répandue, les prises radiocommandées que l’on trouve un peu par tout au prix de 15 euros les trois prises avec leur télécommande soit 5 euros par prise. L’astuce consistera à insérer la télécommande dans le dispositif et connecter les boutons de la télécommande à des relais.

Le cœur du dispositif :
Pas facile de résoudre l’équation d’un système autonome, peu gourmand, ouvert et pas cher. Après des recherches sur internet, je suis tombé sur un Routeur Linksys WRT54G sur lequel on peut implanter un firmware Linux nommé OpenWRT.
Sur le plan hard, le routeur est doté de 5 interfaces Ethernet, 1 interface WIFI et de 2 interfaces série (TTL mais pas RS232) pour la partie communication et de 1 processeur/chipset Broadcom cadencé de 125 à 200 Mhz en fonction des versions, de 16 Mo de RAM et de 4 Mo de Mémoire Flash pour le traitement. (Voir http://fr.wikipedia.org/wiki/WRT54G).
Sur le plan soft, OpenWRT est un OS Linux adapté au matériel (voir http://fr.wikipedia.org/wiki/OpenWrt). Il existe plusieurs variantes et versions, pour les besoins de ce projet je suis parti sur la version « Kamikaze 8.09 ». Cette version intègre de base, entre autre, un serveur HTML, une interface web d’administration et le service cron permettant la programmation de tache. Il existe une librairie non négligeable de packages additionnels, ne disposant pas d’une place importante sur la mémoire Flash, il faut installer le strict nécessaire et désinstallé l’inutile (facile à dire, moins facile à faire).
Le routeur Linksys WRT54G n’est plus au catalogue du fabricant et les dernières versions étant limitées en taille mémoire, je suis parti à la recherche sur le marché de l’occasion. Cela n’est pas pour me déplaire (cout moins élevé et réutilisation de bien). J’en ai donc trouvé un premier sur leboncoin en V2 au prix de 15 euros, puis d’un second (au cas où) sur ebay en V2 au prix de 16 euros. Au final ce matériel est assez répandu et la multiplication des box FAI pousse les propriétaires à la revente dans les meilleurs des cas ou à la poubelle dans le pire .
Une fois la bête entre les mains, je procède à l’installation et au paramétrage de base d’OpenWRT. Je décide d’utiliser l’interface WIFI en client et je donne une adresse IP fixe. Cette opération n’est pas sans risque en cas de mauvais paramétrage, vous risquez de ne plus pouvoir utiliser le routeur, j’en ai fait la triste expérience, mais il existe des moyens peu orthodoxe de récupérer la situation. Une fois le paramétrage réalisé, vous pouvez placez votre WRTbox ou vous le souhaitez d’autant que la double antenne procure une bonne qualité de réception. J’ai porté une attention particulière, sur le réglage horaire de l’OS, pour l’ordonnancement des programmes c’est primordiale :
- la timezone (CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00)
- installation et paramétrage du package ntpd sur le serveur de temps de l’université de Caen.

L’interface Relais :
Compte-tenu du besoin de relais pour commander les volets roulants (2 relais 1 pour la monté et le 2ème pour la descente) et la télécommande des prises radio (4 relais pour les boutons ON/OFF des canaux 1 et 2 + 1 relais pour le sélecteur A et D) soit une total de 7, je me mets à la recherche d’une carte multi-relais d’au moins 8 relais, en kit ou déjà montée, avec une interface serie pour le lien avec la WRTbox. Le résultat de ma recherche est le suivant :
-    http://virtualvillage.com/ à Hong Kong
-    http://fcelectronics.ecrater.com/ au Canada
-    http://www.sigma-shop.com en Bulgarie
Les prix étant assez proches, je décide de commander auprès de nos compatriotes Européens une carte 8 relais/rs232 pour 35 euros et un adaptateur TTL/RS232 pour 8 euros. Le paiement est sécurisé et la livraison à été rapide. J’ai donc commencé par installer l’adaptateur TTL/RS232 dans la WRTbox avec le connecteur DB9 en façade, le détail du câblage du port série sur le WRT54G est disponible ICI. Sur openWRT, j’ai installé le package minicom pour disposer d’un terminal série et j’ai paramétré l’interface serie /dev/tts/1 en 9600 8N1. J’ai ensuite fais quelques tests de commande de relais en m’inspirant de l’exemple fourni à la fin de la doc PDF de la carte.
Ainsi la séquence \xFF\x01\x01 active le relais 1 et la séquence suivante \xFF\x01\x00 le désactive. La partie centrale de la séquence correspond au n° de relais et la fin à l’activation ou désactivation. En dehors de l’outil minicom, la commande echo sur le port serie correspondant donne le même résultat et est la base de mon développement en shell. Pour le moment j’utilise le port série 1, car le port 0 est utilisé pour la console Linux. Ci-dessous un exemple :
# cat relay.sh
while true
do
echo -e "\xFF\x00\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x00\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x00\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x00\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x00\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x01\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x02\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x03\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x04\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x05\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x06\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x07\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x08\x01" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x01\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x02\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x03\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x04\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x05\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x06\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x07\x00" > /dev/tts/1 ; sleep .1
echo -e "\xFF\x08\x00" > /dev/tts/1 ; sleep .1
done

La commande de volets roulants :
J’ai connecté la commande de montée sur le relais 1 et la descente sur le relais 2. Puis j’ai crée 2 scripts shell correspondant pour chacun des sens :

down_volet.sh
echo -e "\xFF\x02\x01" > /dev/tts/1
sleep 45s
echo -e "\xFF\x02\x00" > /dev/tts/1
up_volet.sh
echo -e "\xFF\x01\x01" > /dev/tts/1
sleep 45s
echo -e "\xFF\x01\x00" > /dev/tts/1

Une fois les scripts crées il faut les ordonnancer dans la crontab avec une heure de montée et de descente variable en fonction des heures de lever et coucher du soleil. Pour cela j’ai crée une table dans un fichier plat contenant les horaires en UTC du 1er janvier au 31 décembre à partir du site http://ptaff.ca/soleil . Et chaque jour à 3h05 je reprogramme les entrées dans la crontab en fonction des horaires du soleil du jour inscrits dans la table auxquels j’ajoute 1 ou 2 heures en fonction de l’heure d’hiver ou d’été.
DIRSH=/root/voletr
TODAY=`date '+%m-%d'`
LINE=`grep $TODAY $DIRSH/cal_h_sun.txt`
H_UTC=`date -u '+%H'`
H_CET=`date '+%H'`
DELTA=$((H_CET-H_UTC))
H_SUNR=`echo $LINE | awk '{print $2}' | awk '{FS=":";print $1}'`
H_SUNRISE=$((H_SUNR+DELTA))
M_SUNRISE=`echo $LINE | awk '{print $2}' | awk '{FS=":";print $2}'`
H_SUNS=`echo $LINE | awk '{print $3}' | awk '{FS=":";print $1}'`
H_SUNSET=$((H_SUNS+DELTA))
M_SUNS=`echo $LINE | awk '{print $3}' | awk '{FS=":";print $2}'`
if [ "${M_SUNS}" -lt 10 ]
        then
                M_SUNS=`echo $M_SUNS | awk '{FS="0";print $2}'`
fi
if [ "${M_SUNS}" -lt 30 ]
        then
                echo "$M_SUNS"
                M_SUNSET=$((M_SUNS+30))
        else
                M_SUNSET=$((M_SUNS-30))
                H_SUNSET=$((H_SUNSET+1))
fi
cp $DIRSH/crontab.base $DIRSH/crontab.var
echo "#--------Programmation des prises radio--------" >> $DIRSH/crontab.var
cat /root/remotep/crontab.var >> $DIRSH/crontab.var
echo "#--------montee descente variable des volets--------" >> $DIRSH/crontab.var
crontab $DIRSH/crontab.var

Voila le résultat dans la crontab :
root@OpenWrt:~/voletr# crontab -l
#--------definition du lever et coucher du soleil--------
05 03 * * * /root/voletr/voletr.sh 1> /dev/null 2>&1
#--------montee descente variable des volets--------
55 6 * * * /root/voletr/up_volet.sh 1> /dev/null 2>&1
36 21 * * * /root/voletr/down_volet.sh 1> /dev/null 2>&1
root@OpenWrt:~/voletr#

Le pilotage des prises radiocommandées :
Comme expliquer précédemment, le principe retenu est d’intégrer la télécommande radio dans la solution auprès de la carte relais. Les connections dépendent bien sur du type de télécommande, celle que je dispose fonctionne de la manière suivante. 4 boutons (1 ON et 1 OFF pour le canal CH1 et 1 ON et 1 OFF pour le canal CH2) et un sélecteur ABCD. Les récepteurs ont une étiquette indiquant CH1 ou CH2 et un sélecteur ABCD. Je peux donc adresser 8 prises, mais le packages ne contient que trois récepteurs (réglage des récepteurs 1A, 2A et 1D). La télécommande quand à elle a subit quelles que transformation, j’ai ôté le boitier, j’ai remplacé la pile de 12v par un régulateur 78L12 (60 cts d’euros) alimenté par l’alimentation commune au WRT54G et à la carte relais/RS232, j’ai connecter les boutons sur les relais 5, 6, 7 et 8 et le sélecteur pour la sélection A ou D (ne disposant pas de 8 récepteurs, le câblage de B et C n’étaient pas nécessaire) sur le contact ouvert et fermé du relais 4. Quand le relais 4 est au repos cela correspond à la sélection A et quand il est actif, à la sélection D. Concernant la sélection il a fallu comprendre la logique du sélecteur par rapport au circuit de la télécommande et donc jouer du cutter pour couper certaine piste et souder les liens avec le relais aux endroits adaptés.
Maintenant que les relais sont interfacés avec la télécommande, je procède à la vérification fonctionnelle en envoyant sur le port série une séquence du même type que celles utilisées pour la commande de volet. La temporisation entre l’activation est la désactivation est de 1 seconde. Toutefois si je souhaite commander la prise 1D, il faut penser à activer le relais 4 pendant le temps d’actionnement du relais connecté au bouton voulu.
echo -e "\xFF\x04\x01" > /dev/tts/1
echo -e "\xFF\x06\x01" > /dev/tts/1
sleep 1
echo -e "\xFF\x06\x00" > /dev/tts/1
echo -e "\xFF\x04\x00" > /dev/tts/1

J’ai crée 6 scripts shell pour commander l’allumage et l’extinction des 3 prises. Ces scripts peuvent ensuite être utilisés en programmation dans la crontab mais également par d’autres moyens.
L’OS OpenWRT intègre un serveur de page HTML permettant l’exécution de CGI (Common Gateway Interface - http://fr.selfhtml.org/cgiperl/introduction/cgihtml.htm). Après une initiation rapide, j’ai donc crée 6 autres fichiers cgi simples faisant appel aux scripts précédemment écrit.
prise1a_down.cgi
#!/bin/sh
echo "Content-type: text/html"
echo
/root/remotep/prise1a_down.sh
echo '<BODY style="background-color: black">'
echo '<meta http-equiv="refresh" content="0; URL=/index.html" />'
echo "</BODY>"
Ces fichiers CGI sont lancés depuis une page html, sous forme de boutons actions encadrant une image qui indique le statut (UP/vert, DOWN/rouge) le tout dans un tableau pour la mise en page.
Extrait du fichier html :
   <tbody>
   <tr>
   <td style="text-align: right; width: 206px;">
   <a style="color: white; text-decoration: none;">Prise 1A :</a></td>
   <td style="width: 45px;">
   <form action="/cgi-bin/domotic/prise1a_up.cgi">
   <p>
   <input type="submit" value="UP" >
   </p>
   </form>
   </td>
   <td style="width: 15px;">
   <img style="width: 15px; height: 15px;" alt=""src="/images/led_p1a.gif">
   </td>
   <td style="width: 65px;">
   <form action="/cgi-bin/domotic/prise1a_down.cgi">
   <p>
   <input type="submit" value="DOWN" >
   </p>
   </form>
   </tr>

Le code html est volontairement simpliste ce qui rend l’affichage sur un Smartphone confortable.

Lecture du signal de téléinfo :
Les compteurs EDF électronique sont pourvus d'une interface permettant de communiquer des informations à l'installation électrique du domicile. Ce signal, appelé téléinfo, est souvent utilisé pour le délestage pour éviter la disjonction pour dépassement de la puissance de votre abonnement.
Le signal est disponible sur les bornes I1 et I2 du compteur.
EDF recommande d'isoler électriquement l'utilisation du signal.
L'objectif est de mettre en forme le signal pour pouvoir l'utiliser sur une des interfaces série du WRT54G.
J'ai trouvé sur la toile plusieurs schémas autour d'un optocoupleur.
Le plus évident aurait été de reprendre le schéma de l'étude complète proposé sur le site
http://vesta.homelinux.net/wiki/demodulateur_teleinformation_edf.html
mais le nombre de le composant pour le réaliser me paraissait trop important (plus de 30 composants).
Je me suis donc mis à la recherche d'un schéma plus simple et suis tombé sur ce forum
http://www.chaleurterre.com/forum/viewtopic.php?t=5763&postdays=0&postorder=asc&&start=45
ou hd31 proposé plusieurs schéma simple autour d'un optocoupleur sfh6206-02.
Ces schémas ont pour point commun d'adapter le signal de téléinfo vers des niveaux RS232.
Le WRT54G quand à lui dispose d'une interface série exploitant des niveaux TTL. Une adaptation du schéma s'impose donc. Après plusieurs tentatives, je tombe un peu par hasard sur un résultat minimaliste avec uniquement 2 composants une résistance et la perle rare le sfh6206-02.

Cet optocoupleur n’est pas répandue et n’est pas disponible dans les boutiques de composant habituelles. Les grands distributeurs sur la toile le propose mais avec des frais de ports et/ou un montant minimum de commande importants en rapport du prix du composant. Le meilleur deal à été de passer une commande d’une douzaine d’unité pour ensuite faire profiter du surplus à d’autre. Ainsi le cout unitaire reste acceptable à 2,25 euros, si je trouve des acheteurs pour mon petit stock de sfh6206-02 (je les propose en paire au prix de 5 euros avec le port au tarif lettre compris, tous mes lots d'optocoupleur ont trouvé preneur dans les 6 mois qui ont suivis mon offre ).

Maintenant, pour pouvoir vérifier le bon fonctionnement du cablage, j'utilise l'outil Minicom (package disponible sur OpenWRT), avec les réglages présentés ci-dessous (image).

Toutefois, il faut au préalable désactiver la console système qui utilise par défaut le port 0 (attention, après cette modification, la console ne sera plus disponible sur aucun port). Pour cela modifier le fichier /etc/inittab en commentant la ligne "tts/0::askfirst:/bin/ash --login", puis rebooter le routeur.

Pour maintenir la configuration du port serie en dehors de minicom, il faut sortir sans "resetter" le port (ctrl-A-Q).

Les trames lues sont les suivantes :

AT 000000 BMCB

ADCO (serial number) NM
OPTARIF HC.. <M
ISOUSC 60 <M
HCHC 066661889 8M
HCHP 081299969 HM
PTEC HC.. SM
IINST 015 ]M
IMAX 053 GM
PAPP 03240 *M
HHPHC E 0M
MOTDETAT 000000 BMCB
ADCO (serial number) NM
OPTARIF HC.. <M
ISOUSC 60 <M

La trame est formée de 11 lignes (caractères blancs), les données qui me sont utiles sont soulignées. Une douxième ligne peut apparaitre lorsque votre consommation atteint le maximum permit par votre contrat (ADPS).

graph conso Concernant le soft. L’approche est la même que pour le hard : Simplicité. Je m’impose donc de gérer localement sur le WRT54G le traitement, le stockage et l’affichage des données de consommation. L’objectif est de pouvoir visualiser l’électricité consommée sur une journée, une semaine, un mois et une année et en différenciant les heures pleines et les heures creuse. Le traitement sera réalisé en script shell, quand au stockage et à l’affichage, ils seront réalisés par l’outil RRDTool disponible sous forme de package pour OpenWRT.

Pour cette partie logicielle je me suis inspiré grandement du travail de Macsat décrit dans le tutoriel.

http://wl500g.info/archive/index.php/t-2848.html

Le travail consiste ensuite à adapter le script pour remplacer la capture de l’information du trafic réseau par celle de la consommation d’électricité.

Avant tout il faut donc installer les packages nécessaire :
- rrdtool1 v1.0.50-1
- libfreetype v2.3.7-1.1
- librrd1 v1.0.50-1
- libpng v1.2.29-1.2

L’information de téléinfo est donc envoyée sur le port série 0 sans discontinuer. Parmi ces informations, la puissance instantanée et les compteurs hp et hc nous intéressent. Pour ne pas perdre une miette de l’information je décide donc capturer en continu les informations reçu sur le port /dev/tts/0 vers un fichier que je place volontairement sur le /tmp pour optimiser l’espace (Pour rappel le WRT54G ne dispose que de 4 Mo d’espace disque et 8 Mo de RAM, /tmp est un FS temporaire en RAM). J’ai donc placé dans le script de démarrage du routeur la commande :
cat /dev/tts/0 > /tmp/teleinfo.raw
A chaque lancement du traitement ce fichier est remis à zéro.
Le traitement consiste à récupérer et mettre en forme les informations souhaitées et à alimenter RRDTool avec ces valeurs. Le script proposé par Macsat est particulier car il réalise plusieurs fonctions différentes, Le création des pages HTML, la création des bases RRDTool, l’alimentation des bases RRDTool, la génération des fichiers images contenant les graphiques. L’exécution de ces fonctions est conditionnée soit par la présence de fichier ou par l’heure au moment de l’exécution. Ce script est lancé par le cron toutes les 5 minutes. Les explications générales étant présentées dans le tutoriel, je vais donc vous exposer uniquement les fonctions qui touchent directement au besoin.
Les bases RRDTool sont au nombre de 2 :
- Une pour la puissance instantanée, utilisée pour afficher les données journalière et hebdomadaire. Elle contient 2 types de valeur, les heures pleines et les heures creuses. Sa base de temps est de 5mn.

    rrdtool create WATTRRD \
    DS:HP:GAUGE:600:0:12500000 \
    DS:HC:GAUGE:600:0:12500000 \
    RRA:AVERAGE:0.5:1:576

Le script suivant permet l'alimentation des données(moyennes de la puissance instantanée) dans cette base.

pkill cat
sed '1d;$d' /tmp/teleinfo.raw > /tmp/teleinfo.tmp
cat /dev/tts/0 > /tmp/teleinfo.raw &
tail -12 /tmp/teleinfo.tmp > /tmp/teleinfo.ptec
TESTADPS=`grep ADPS /tmp/teleinfo.ptec | wc -l`
if [ "${TESTADPS}" = 0 ]
    then
        sed '$d' /tmp/teleinfo.ptec > /tmp/teleinfo.end
fi
PTEC=`grep ".." /tmp/teleinfo.end | grep PTEC | awk '{print $2}'`
NBPAPP=0
SUMPAPP=0
for LINEPAPP in `grep PAPP /tmp/teleinfo.tmp | awk '{print $2}' | sed s/^0*//`
do
    NBPAPP=$((NBPAPP+1))
    SUMPAPP=$((SUMPAPP+LINEPAPP))
done
PAPP=$((SUMPAPP/NBPAPP))
if [ "${PTEC}" = HP.. ]
    then
        WATTHP=${PAPP}
        WATTHC=0
    else
        WATTHP=0
        WATTHC=${PAPP}
fi
# Update the Databases
`rrdupdate "${WATTRRD}" -t HP:HC N:"${WATTHP}":"${WATTHC}"`

- La deuxième exploite les compteurs HP et HC pour afficher la consommation mensuelle et annuelle. Sa base de temps est de 1 heure.

    rrdtool create CWATTRRD --step 3600 \
    DS:CHP:COUNTER:4000:0:12500000 \
    DS:CHC:COUNTER:4000:0:12500000 \
    RRA:AVERAGE:0.5:1:336 \
    RRA:AVERAGE:0.5:24:730
Le script est plus simple que pour la base précèdente car le calcul de la moyenne n'est pas nécessaire.

CWATTHP=`grep HCHP /tmp/teleinfo.end | awk '{print $2}'`
CWATTHC=`grep HCHC /tmp/teleinfo.end | awk '{print $2}'`
`rrdupdate "${CWATTRRD}" -t CHP:CHC N:"${CWATTHP}":"${CWATTHC}"`

La génération des graphiques :
Pour la visualisation des consommations je souhaite disposer de plusieurs graphiques, quotidien, hebdomadaire, mensuel et annuel permettant la lecture de la consommation en heure creuse et heure pleine. L’esthétique générale choisie est un fond de couleur foncée presque noir, les heures pleines en rouge, et les heures creuse en vert, avec des courbes pleines, mais légèrement transparentes. Les graphiques sont accompagnés d’une légende contenant des données (min, max, moyenne et courante) pour chacune des courbes.
Comme pour les bases, j’ai créé 2 types de graphique permettant une lecture adaptée au type de données.
Pour le graphique quotidien, j’affiche les courbes avec le même niveau d’ordonnée. Car sur une journée avec un pas de capture de 5mn, les heures creuses et les heures pleines sont bien distinctes (sur une même pas la consommation est soit en HC ou soit en HP, pas les deux en même temps).
# $1 = ImageFile , $2 = Time in secs to go back , $3 = RRDfil , $4 = GraphText , $5 = Unite
CreateGraph ()
{
rrdtool graph "${1}.new" -a PNG -s -"${2}" -w 550 -h 240 -v "${5}" \
--color CANVAS#000000 \
--color BACK#101010 \
--color FONT#C0C0C0 \
--color MGRID#80C080 \
--color GRID#808020 \
--color FRAME#808080 \
--color ARROW#FFFFFF \
--color SHADEA#404040 \
--color SHADEB#404040 \
'DEF:ds1='${3}':HC:AVERAGE' \
'DEF:ds2='${3}':HP:AVERAGE' \
'AREA:ds1#008800' \
"COMMENT:${date}     Max       Min       Avg      Curr\n" \
'COMMENT:---------------- -------- -------- -------- --------\n' \
'LINE1:ds1#00FF00:Heures Creuses' \
GPRINT:ds1:MAX:"%6.2lf %s" \
GPRINT:ds1:MIN:"%6.2lf %s" \
GPRINT:ds1:AVERAGE:"%6.2lf %s" \
GPRINT:ds1:LAST:"%6.2lf %s\n" \
'AREA:ds2#880000' \
'LINE1:ds2#FF0000:Heures Pleines' \
GPRINT:ds2:MAX:"%6.2lf %s" \
GPRINT:ds2:MIN:"%6.2lf %s" \
GPRINT:ds2:AVERAGE:"%6.2lf %s" \
GPRINT:ds2:LAST:"%6.2lf %s\n" \
-t "${4}"
mv -f "${1}.new" "${1}"
}

Pour les autres graphiques (hebdomadaire, mensuel et annuel), j’affiche les courbes les unes au dessus des autres (ce mode s’appel « stack » dans l’outil RRDtool) et j’utilise une variable base de temps (btime) me permettant d’ajuster les données en fonction de l’unité de valeur voulue (watt/heure pour la semaine et watt/jour pour le mois ou l’année). Pour le graphique mensuel, l’effet de « bargraph » est obtenu volontairement, par le choix judicieux du niveau de moyenne fait leur de la création de la base (voir paragraphe précédent). Pour la légende, j’affiche en plus des 2 série de données HP/HC le total des 2 courbes.
CreateGraphStack ()
{
rrdtool graph "${1}.new" -a PNG -s -"${2}" -w 550 -h 240 -v "${5}" \
--color CANVAS#000000 \
--color BACK#101010 \
--color FONT#C0C0C0 \
--color MGRID#80C080 \
--color GRID#808020 \
--color FRAME#808080 \
--color ARROW#FFFFFF \
--color SHADEA#404040 \
--color SHADEB#404040 \
--alt-autoscale-max \
--lower-limit=0 \
'DEF:ds1o='${3}':CHC:AVERAGE' \
'CDEF:ds1=ds1o,'${btime}',*' \
'DEF:ds2o='${3}':CHP:AVERAGE' \
'CDEF:ds2=ds2o,'${btime}',*' \
'AREA:ds1#008800' \
'STACK:ds2#880000' \
"COMMENT:${date}     Max       Min       Avg      Curr\n" \
'COMMENT:---------------- -------- -------- -------- --------\n' \
'LINE1:ds1#00FF00:Heures Creuses' \
GPRINT:ds1:MAX:"%6.2lf %s" \
GPRINT:ds1:MIN:"%6.2lf %s" \
GPRINT:ds1:AVERAGE:"%6.2lf %s" \
GPRINT:ds1:LAST:"%6.2lf %s\n" \
'STACK:ds2#FF0000:Heures Pleines' \
GPRINT:ds2:MAX:"%6.2lf %s" \
GPRINT:ds2:MIN:"%6.2lf %s" \
GPRINT:ds2:AVERAGE:"%6.2lf %s" \
GPRINT:ds2:LAST:"%6.2lf %s\n" \
'CDEF:ds3=ds1,ds2,+' \
GPRINT:ds3:MAX:"          Total %6.2lf %s" \
GPRINT:ds3:MIN:"%6.2lf %s" \
GPRINT:ds3:AVERAGE:"%6.2lf %s" \
GPRINT:ds3:LAST:"%6.2lf %s\n" \
-t "${4}"
mv -f "${1}.new" "${1}"
}
Pour l’adaptation RRDTool des scripts de Macsat, je vous recommande la lecture des pages suivantes, qui m’ont été très utiles :
http://wiki.monitoring-fr.org/supervision/rrdtool
http://www.deimos.fr/blocnotesinfo/index.php?title=RRDtool_:_cr%C3%A9er_ses_propre_graphiques_avec_RRDtool
Dans la pratique les graphiques quotidien et annuel sont très intéressants. Le premier permet de repérer les moments de la journée ou la consommation est importante, on peut facilement y associer les appareils qui en sont à l’origine (ex. le fer à repasser, au moment du repassage, le ballon d’eau chaude au moment de basculement HP/HC, …). Le deuxième quand à lui permet de voir l’évolution de la consommation au fil des saisons. A l’inverse le graphique hebdomadaire n’est pas d’un grand intérêt, il n’est pas facile à interprété en parti a cause du mélange HP/HC.
J’espère que cet article vous donnera l’envi et l’inspiration pour développer votre propre outil de surveillance de la consommation (ou production) électrique. J’envisage maintenant d’aller plus loin dans les possibilités de mon routeur domotique, en y ajoutant la surveillance des températures intérieur/extérieur et pourquoi pas le pilotage des radiateurs.