Version du Mardi 22 mai 2001

Domotique

par R. Suinot et D. Laigle

Gestion de convecteur

Utilisation d'une machine Linux pour le chauffage

R. Suinot et D. Laigle

Mon Oct 16 02:24:51 2000

Ce document décrit le but, l'installation et l'utilisation d'une application de domotique.

Table des matières

1. Introduction
2. Installation
3. Utilisation
4. Reste à faire
5. Demande d'aide
6. Conclusion
7. Revision 1
8. Revision 2

1. Introduction

Au début, était le vide. Puis vint le ciel, la Terre, et le reste... (je vous passe les détails), jusqu'au jour ou j'ai fait construire ma maison, sans possibilité de choisir la méthode de chauffage. Seule l'électricité m'a été proposée. Je suis donc équipé de convecteurs standards dont la particularité est d'être pilotable par un fil relié au réseau électrique, en plus de l'alimentation. Ce fil pilote permet de "dire" à chaque convecteur dans quelle position de chauffage il doit se mettre.

Ainsi, chacun peut être dans 4 états :

1) Arrêt : bon, là il n'y a rien à dire, c'est juste avec le bouton M/A du convecteur:
2) Marche :
2-a) marche en mode chauffage normal : la température est réglée grâce à une molette sur l'appareil;
2-b) marche en mode économie : le convecteur se met en route UNIQUEMENT si la température passe en dessous d'un seuil, prédéfini en usine (typiquement: 10°);
3) Hors gel : réglage avec la molette de température au minimum.

Le point qui nous intéresse, c'est cette régulation mode chauffage/mode économie. Dans le reste du document, je parlerai de mode confort et de mode éco. Avec tout ça, je dispose d'un petit appareil, muni d'une horloge et de zones horaires préprogrammées, afin de mettre les convecteurs en mode confort ou éco selon mes besoins. Pour cela, la maison a été artificiellement coupée en deux zones. Zone jour : qui se constitue de la cuisine, du salon/salle à manger, et de la salle de bains ; Zone nuit : les chambres, bien sûr. Ainsi, je peux chauffer une partie de la maison, pendant le temps qu'il me faut, à partir de l'heure que je veux, mais en fonction des programmes prédéfinis, le tout sur 7 jours uniquement. Bien me direz vous, sauf que l'on ne peut pas couper les pièces autrement qu'en deux zones, et que la préprogrammation a une "forte tendance" à avoir été pensé pour des personnes travaillant aux horaires de bureau (je n'ai a priori rien contre les gens travaillant pendant ces horaires).
Dès le début, ce type de programmation m'a un peu "déplu". Je travaille de nuit, et mes jours de repos sont parfois dans la semaine, et aucune des zones préprogrammées ne convenaient à mes horaires de boulot. Et pour couronner le tout, notre tarification EDF est en 6 parties :

Une partie heures pleines 'pas chères' (6h -> 22h) \
Une partie heures creuses 'pas chères' (22h -> 6h) / Heures bleues
Une partie heures pleines 'plus chères' (6h -> 22h) \
Une partie heures creuses 'plus chères' (22h -> 6h) / Heures blanches
Une partie heures pleines 'très chères' (6h -> 0h) \
Une partie heures creuses 'très chères' (0h -> 6h) / Heures rouges

J'ai donc commencé à réfléchir au moyen de modifier cette programmation. A cette époque, je commençais à connaître un peu Linux (première installation sur un Atari Falcon 030). De là m'est venue l'idée d'une gestion du chauffage par une machine sous Linux, via une carte à relais. J'ai demandé à Dominique Laigle , son avis, sachant qu'il connaissait (très) bien Linux. Nous sommes donc partis sur cette base, et comme il avait des facilités pour la partie électronique, il a pu réaliser la carte à relais. Dans la foulée, il a aussi créé l'application de programmation pour chaque jour de la semaine, toute l'année !

2. Installation

Voyons comment cela se présente.

La partie électronique est une "bête" carte à 8 relais, que l'on connecte à la prise imprimante. Les relais ont un état on/off sur le fil pilote, c'est tout.
La partie logicielle se constitue d'une appli en mode texte pour mettre les relais ON/OFF (/usr/bin/chauffage), d'une appli en mode texte pour connaître l'état des relais (/usr/bin/radiateur), d'une appli graphique pour créer la programmation sur l'année (/usr/X11R6/bin/programmateur), et d'un script perl qui permet de modifier l'état des groupes immédiatement (/usr/bin/immediat.pl). La compilation ne pose aucun problème, avec en plus un script avant compilation et un script post-installation.

ATTENTION !

J'utilise, dans le script perl, un programme externe appelé "beep". Il permet de modifier le son du haut-parleur de votre machine (en fréquence et durée). Il a été écrit par Jonathan Nightingale .

L'application de chauffage repose sur la séparation artificielle en quatre zones (au lieu de deux, avant). Chacune de ces zones est représentée par un groupe contenant 2 relais (nous avons donc 4 groupes de 2 relais chacun, soit 8 relais en tout). La programmation se fait donc pour chaque groupe, chaque jour de la semaine.

3. Utilisation

Branchement

J'ai réparti physiquement, chez moi, les groupes ainsi :

groupe 1 : Cuisine + salon/salle à manger ;

groupe 2 : Salle de bains ;

groupe 3 : chambres enfants/amis + bureau ;

groupe 4 : chambre où je dors la journée.

Les applications sont :

'/usr/X11R6/bin/programmateur'

C'est elle qui me permet de définir les plages horaires de fonctionnement, pour tous les jours et tous les mois. C'est, en gros, la plus utile : on définit une fois pour toute la programmation du chauffage pour l'année, et hop, on n'y touche quasiment plus ! (sauf en cas de vacances non prévues...)

'/usr/bin/chauffage'

Ce programme attend :
- soit une valeur décimale entre 0 et 256, pour basculer un relais d'un état à un autre, selon le schéma binaire: bit n°x = relai n°x ;
- soit deux valeurs : le numéro du groupe et l'état voulu (ON ou OFF).
Il permet de "jouer" avec chaque relais (mais il faut bien savoir ce que l'on fait), ou avec chaque groupe. Pratique en cas de changement de programmation immédiatement !

'/usr/bin/radiateur'

Ce programme n'attend aucun paramètre en entrée. Il fournit l'état des groupes en fonction du fichier d'état /opt/qchauffage/chauffage.status.

'/usr/bin/immediat'

Ce programme n'attend aucun paramètre en entrée. C'est grâce à lui que l'on pourra exécuter des changement de programmation à la volée.
On le lance sur une console, sans le placer en background. Il attend une touche d'action sur l'un des groupes de chauffage.

4. Reste à faire

Malgré tout, il reste encore beaucoup de travail, puisque l'appli graphique ne prend en compte qu'une semaine de programmation par mois, et non chaque jour de chaque mois, ni les changements de programmation "à la volée". J'entends par là les changement de programmation sur l'instant, quand on sait que l'on part pour la journée par exemple.
Donc,il faut améliorer l'application "programmateur".
J'ai commencé un petit script en perl qui permet de changer la programmation immédiatement. Il me faut encore le perfectionner, voire le passer en mode graphique, mais là, ce n'est pas une priorité.
... puis déboguer ?

5. Demande d'aide

Si vous avez d'autres idées et/ou voulez apporter votre contribution aux codes, n'hésitez pas !
Dom ayant abandonné (provisoirement ?) le développement, j'en suis le repreneur (quoique j'en sois l'instigateur... je ne reprends donc pas vraiment le projet...) Vous connaissez mon adresse: Rémi Suinot

6. Conclusion

Comme vous avez pu le remarquer, je ne suis pas un rédacteur hors pair de document technique. Si vous désirez des précisions sur quelques points précis, n'hésitez pas à me les demander.
Les sources sont disponibles chez moi, ainsi qu'une doc complète du projet.

7. Révision 1

A ce jour, Wed Nov 1 21:17:03 2000, le projet est en cours de réécriture/amélioration. En premier, l'application en mode console fonctionne, mais doit être améliorée, bien sur. Pour l'application graphique (la partie programmation du chauffage pour toute l'année), elle est en cours de réécriture complète sous gnome (glib, gtk, gdk) par Dominique Laigle, le programmeur initial. Il va inclure quelques modifications, sous mes conseils, et en premier, le choix du nombre de relais dédiés à chaque groupe (sans dépasser 8, puisqu'il n'y en a que 8 sur la carte). Ensuite, la possibilité de programmer plus complètement les cycles arrêt/marche. En effet, la première version ne permettait que de programmer qu'une semaine par mois, celle-ci étant répliquée ensuite sur tout le mois.

Donc, le projet avance...

8. Révision 2

Apres une accalmie de de quelques mois, le projet revient avec quelques améliorations:

l'application graphique a été réécrite avec GTK, et dispose d'un calendrier, plus quelques autres amélioration (choix des relais pour chaque groupe par exemple);
l'application de gestion via le clavier, qui doit fonctionner 24 h/24 peut (et doit) être lancé à la place d'un terminal (modification du fichier /etc/inittab). Ainsi, même si le serveur redémarre, après une coupure de courant par exemple, l'application redémarrera aussi!
les scripts de passage en tarification Blanc (vs Rouge) fonctionne correctement, et détecte automatiquement s'il faut rester en blanc (vs rouge) ou pas. Seul impératif, appuyer sur une touche du clavier dès que l'on connaît la tarification du lendemain.
Voilà, je crois que c'est tout...

À ce jour, 22 mai, nous avons donc utilisé le projet chez moi. D'après la facture d'EDF reçue récemment, nous avons :

consommé plus en tarification bleue ;
diminué de moitié la consommation en tarif blanc (nuit comme jour) ;
diminué de moitié la consommation en tarif rouge (nuit comme jour).

Mais je pense pouvoir améliorer un peu, car étant utilisé pour la première fois, j'ai parfois commis quelques erreurs, eu de petits soucis de script (surtout pour la commutation Bleu vers Rouge), et que nous n'avons pas encore le système bien en main. Rendez-vous l'an prochain, même date, pour une nouvelle mise au point des économies réalisées.
D'ici là, je pense quand même donner d'autre nouvelles !

Pour info : passage du serveur de Mandrake 7.1 vers Debian, en cours.

Et en bonus track : nous avons quelques bonnes volontés qui proposent leur aide. Elles sont toutes les bienvenues!

Retour en Gaule

La présente page est hébergé chez Linux-France. Un forum est par ailleurs ouvert sur Linux-Doc.

La Gaule était envahie par Crimo$oftus... Toute la Gaule ? Non, car un petit
village du nom d'Essonnix résistait... Linux était son libérateur !