GuiguiAbloc

Quitte à tripoter ma chaudière fioul, autant en profiter pour la domotiser un peu

Quand je dis domotiser, je parle bien évidemment de la régulation/programmation du chauffage.

Pour les chauffages électriques, c’est de la rigolade, puisque dans la plupart des cas, c’est natif (fil pilote, thermostat d’ambiance, que sais-je encore…)

Pour les chaudières Gaz, mon « confrère » bloggeur, Abavala (je peux t’appeler confrère Hervé ? :p ), a écrit un excellent billet à ce sujet que je vous invite à lire de suite :

http://www.abavala.com/2011/10/24/ma-chaudiere-a-lapproche-de-lhiver/

Quand au chaudière fioul, bah y’avait pas grand chose…

Alors tout d’abord, petit rappel de fonctionnement.

Ma chaudière est une « vieille » chaudière (comme Karen Cheryl) (spécial clin d’oeil à Fred qui se lamentait de ne plus avoir de lien vers sa chanteuse favorite) (pardon Karen).

Elle n’a donc aucun dispositif de thermostat d’ambiance.

(Vous me direz, je pourrais en changer et mettre un truc de la mort qui tue avec toutes les options, mais bon, c’est comme mes PCs ou ma femme, je suis assez basique la dessus, tant que ça marche, pourquoi en changer ?..)

C’est une chaudière qui produit de l’eau chaude (nommée ECS dans les milieux autorisés, pour Eau Chaude Sanitaire).

Donc elle est composée d’un brûleur (qui brûle le fioul ah ah ah) et chauffe l’eau du ballon incorporé pour me permettre de prendre ma douche dans des conditions acceptables en hiver (et en été aussi d’ailleurs…) et également l’eau qui est envoyé dans le circuit d’eau des radiateurs par un Circulateur.

Ce circulateur est une sorte de pompe qui ne fait que faire « circuler » (d’où son nom, comme quoi la nature est bien faite) l’eau dans le circuit.

Alors un circulateur, c’est ça :

En mode « été », on coupe le circulateur d’eau chaude qui donc n’envoi plus d’eau dans le circuit des radiateurs (magique hein ?).

Sous ce circulateur, nous avons un gros thermostat d’avant guerre qui permet de « régler » la température de l’eau chaude envoyée dans le circuit (en fait une simple vanne qui permet de doser le volume d’eau chaude envoyé).

Vanne qui ne me sert à rien puisque tout mes radiateurs (sauf 1 bien sûr (obligatoire!)), sont équipés de robinets thermostatiques, c’est pour quoi elle est ouverte à fond.

Je peux donc, individuellement, contrôler la température de chaque « pièce/radiateur » (si je met le robinet thermostatique a 21°, le robinet coupe l’arrivée d’eau chaude dans ce radiateur une fois cette température atteinte dans la pièce).

Bon je ne vous expliquerais pas le fonctionnement du robinet, on s’en moque un peu.

Alors déjà ça c’est bien, mais le matin, quand on quitte la maison, on se voit mal faire le tour de tout les radiateurs (j’en ai 13 !) pour baisser la température de 2°.

Donc bilan, on laisse tel quel et dans la journée, quand personne n’est la (à part le lapin), ben ça chauffe pareil que quand on est la…

D’où l’idée de gérer un peu tout cela par le serveur Domotique.

De quoi dispose t’on pour traiter de sujet ?

La majorité des pièces de mon domicile sont équipées de sondes de température, mon système domotique « connait » donc la température de chaque pièce.

On ouvre la chaudière et on regarde un peu les branchements électriques :

Alors oui, c’est très old-school… Nous avons le fil d’alimentation du circulateur qui arrive sur un bornier et donc qui est alimenté quand la chaudière est mode Hiver et coupé quand elle est en mode été.

Ne reste plus qu’a se greffer la dessus.

Pour cela, rien de plus simple, il nous faut un contacteur on/off 1000w Chacon (RF 433Mhz)

Un interrupteur va-et-vient (pour passer en mode normal si le système domotique venait à ne plus fonctionner), un voyant rouge 220v (pour faire zoli et voir quand le circulateur est alimenté) et une boiboite pour mettre tout ca dedans.

Soudure, domino et tadammmmm :

The Chaudiere-Controler made by GuiguiAbloc.

Essentiel pour la compréhension, un schéma électrique bien pourri (PS: Pour ceux qui aurait dormi en cours d’électricité P = Phase (ou aussi L comme « Live ») et N = Neutre):

(Quizz a mes amis du réseau : De quel équipement est tiré l’oreille qui sert de support à mon domino ? )

Maintenant que l’on peut contrôler l’arrêt/marche du circulateur, comment on programme cela ?

Alors vous allez voir c’est assez basique.

Tout d’abord, on se créé un template crontab qui sera chargé tout les jours de la semaine de 8h à 18h.

Comme mon serveur domotique « plotte » nos agendas, si nous sommes en RTT/Vacances/Pas envie d’aller bosser , il ne charge pas la crontab dans ce cas là.

Une fois cette crontab chargée, il exécute un script tout les quart d’heure qui vérifie les consignes qui lui sont données dans un fichier YAML. Si la température est au-dessus de ses consignes, il coupe le circulateur, sinon il le relance. Par contre, si une des températures de la maison venait a descendre en dessous du seuil minimum, il relance le circulateur.

La commande on/off du module Chacon est envoyée sur le bus xPL et transmise par mon boîtier RFXCOM.

J’ai donc écrit un script en python qui est lancé toutes les 15 minutes :

NB: C’est une version allégée de celui que j’utilise

Exemple fichier YAML de consigne :

SALON: 18.0
SDB : 20.0
MINITEMP : 17.0

Le script :

#! /usr/bin/python
# -*- coding: cp1252 -*-
 
import MySQLdb, sys
import yaml, socket
 
# YAML
fichieryaml = open('consigne.yaml')
consigne = yaml.load(fichieryaml)
fichieryaml.close()
 
# ALIMENTATION VARIABLE
consignesalon =  consigne['SALON']
consignesdb = consigne['SDB']
minitemp = consigne['MINITEMP']
hostname = socket.gethostname()
 
# CONNECTEUR UDP XPL
UDPSock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
UDPSock.setsockopt(socket.SOL_SOCKET,socket.SO_BROADCAST,1)
 
# fonction Message XPL
def xplmsgcmnd(ordre):
  msg = "xpl-cmnd\n{\nhop=1\nsource=guigui-chauffage." +hostname+"\ntarget=*\n}\nhomeeasy.basic\n{\naddress=0x1111bb\nunit=1\ncommand=" +ordre+ "\n}\n"
  xpladdr = ("255.255.255.255",3865)
  UDPSock.sendto(msg,xpladdr)
 
 
# Connexion MySQL
try:
  db = MySQLdb.connect(host="localhost", user="sonde", passwd="sonde", db="sondes")
except :
  print "connexion refusée"
  sys.exit(1)
 
c = db.cursor()
c.execute("SELECT sensorValue from sensor where sensorType='TempSalon' ORDER BY idx DESC limit 1")
 
rows = c.fetchall()
for row in rows:
    tempsalon = float(row[0])
 
c.execute("SELECT sensorValue from sensor where sensorType='TempSdb' ORDER BY idx DESC limit 1")
 
rows = c.fetchall()
for row in rows:
    tempsdb = float(row[0])
 
c.execute("SELECT sensorValue from sensor where sensorType='TempAutre' ORDER BY idx DESC limit 1")
 
rows = c.fetchall()
for row in rows:
    tempautre = float(row[0])
 
c.close()
 
if tempsalon < minitemp or tempsdb < minitemp or tempautre < minitemp :
  ordre = "on"
  xplmsgcmnd(ordre)
  sys.exit(0)
 
if tempsalon <= consignesalon or tempsdb <= consignesdb:
  ordre = "on"
  xplmsgcmnd(ordre)
 
if tempsdb > consignesdb and tempsalon > consignesalon:
  ordre = "off"
  xplmsgcmnd(ordre)

Et voila, un thermostat d’ambiance beaucoup plus fin que ceux que l’on trouve dans le commerce (car il prend en compte plusieurs températures et non pas seulement la température de la pièce de référence) et comble du luxe, comme je connais également la température extérieure, je peux peaufiner ma demande (inertie des radiateurs, baisse plus ou moins rapide de la chaleur de la pièce etc…)

C’est très DIY je l’avoue, mais c’est très amusant à faire (et en plus ça permet de faire des économies )

Amusez vous bien

Aujourd’hui je vous propose une « petite » technique pour suivre sa consommation de fioul quand on dispose d’une chaudière de ce type pour chauffer son habitation.

En domotique, le suivi de consommation est quand même l’un des axes principal  sur lequel se tourne rapidement les gens qui s’y mettent.

Autant suivre sa consommation d’eau ou d’électricité est relativement simple et aisé, autant suivre une consommation de fioul, c’est beaucoup plus complexe…

Je trouve d’ailleurs étonnant qu’il n’existe pas de solution proposée par les pétroliers et/ou les chauffagistes/vendeurs de fioul pour suivre ce genre de consommation.

Quand j’ai commencé a me pencher sur le sujet, la seule solution que j’ai trouvée était une sonde a incorporer sur la cuve qui, par ultrason, donnait le niveau de fioul restant.

Cet appareil envoi un signal pour dire « y’a presque plus de fioul, faut en recommander », super…

Certains geeks de la domo ont pondu deux, trois trucs toujours axés sur le niveau de fioul dans la cuve, mais je trouve la méthode moyennement fiable.

Moi ce que je voulais, c’est la même chose que mon compteur d’eau, a savoir, le nombre de litres consommé.

Alors les plus avertis d’entre vous me diront, bah t’installe un débitmètre sur le tuyau ! Mouais, et des débimètres « communicants » ça court pas les rues… (si vous avez une piste…)

De plus, je me voyais mal jouer avec les flexibles de fioul dans le sous-sol…

Donc, quand on se fixe un objectif, la première chose à faire c’est de comprendre comment marche le bouzin (parce qu’une chaudière à fioul, on dirait pas, mais c’est une sacré usine à gaz (ah ah ah, ça fait rire que moi, désolé :/ )

Après « quelques » heures passées à éplucher les docs techniques de Geminox, harceler mon gentil technicien qui me fait la révision de ma chaudière, j’ai trouvé une solution plutot pas mal…

• Ou sort le fioul ?

(je sais DTC…)

Plus sérieusement, d’un… gicleur.

Et au cas où vous ne le sauriez pas, un gicleur est calibré pour envoyer la même dose de fluide constamment.

Et cette « dose » est justement marquée dessus (ou si vous avez de la chance, sur le rapport d’entretien annuel de votre chauffagiste quand il vous le remplace).

Par exemple pour mon cas personnel, mon gicleur est un Danfoss 0,60. Ce qui veut dire que le gicleur envoit 0,60 US Gallon de fioul à l’heure.

L’unité nous étant plutôt lointaine, il faut savoir qu’ 1 gallon = 3,78541178 litres.

Donc, toute les heures de fonctionnement, le gicleur envoit 2 litres 27 de fioul (vous commencez a comprendre où je veux en venir ? non ?…)

Continuons.

L’appareil qui contrôle l’envoi de fioul dans le gicleur, c’est le Brûleur (il fait pas que ça hein :p )

Le mien ressemble à ca :

Un coup de nain ternet et magique, les docs des brûleurs sont disponibles sur le site du fabricant.

Fabricant qui nous donne en plus, gros cadeau, le principe de fonctionnement d’un brûleur :

http://www.bentone.net/formation/forma2.htm

Chapeau pour cette page toute simple qui éclaire n’importe quel néophyte

Donc vous avez maintenant compris où je veux en venir, si on connait le temps de fonctionnement électrique de la pompe ou de l’électrovanne, on peu en déduire le temps de fonctionnement du gicleur et donc combien de litres de fioul il a envoyé

Première piste pour savoir cela, un compteur horaire tel qu’on en trouve chez Conrad :

http://www.conrad.fr/compteur_horaire_c_53207_53709_53719

Sauf que pareil que le débitmètre, je n’en ai pas trouvé de « communicant » :/

Je me prend la tête quelque temps et là, mon pote Nico (aka le Dino Barbu) me souffle une idée de génie : la pince ampèremétrique.

TILT ! le CM119

Et bien sûr, je m’en sers déjà pour récupérer ma consommation électrique de la maison

Cet appareil est en fait une pince ampéremétrique que vous clipsez autour d’une phase d’alimentation et qui vous donne en temps réel l’intensité consommée sur cette phase.

L’information est émise toutes les 15 secondes sur la fréquence 433Mhz et donc récupérable avec un récepteur compatible tel le RFXCOM.

(le fil jaune qui sort de mon boîtier RFXCOM est en fait une deuxième carte « émettrice » à l’intérieur, je peux donc aussi envoyer des ordres en 433Mhz, promis je poserais une antenne plus tard )

Ne reste plus donc qu’a relier une deuxième pince sur le boîtier de contrôle, et la « greffer » sur la phase du moteur du brûleur.

A partir de maintenant, par simple script bash sur le bus xPL qui me remonte les informations de mes équipements domotique, quand une intensité est détectée via le CM119 sur la sonde 2, je déclenche un compteur jusqu’a ce que l’intensité retombe à 0. Donc en gros, quand la pompe/électrovanne (tout dépend où vous vous branchez) marche, je calcule son temps de fonctionnement.

A la fin de la journée, un simple calcul tout bête (automatique bien sûr) :

-Temps de fonctionnement 4h30 minutes

- Débit du gicleur : 2,27 l/h (0.60 de 3,7854 l/h)

- Consommation de fioul du jour : 12 litres en gros

Sympa non ?

Il y a une petite marge d’erreur de quelques litres par mois du a la latence d’émission du boitier  CM119 mais bon, c’est ridicule.

J’avoue c’est très bidouille, bidouille, mais pour comptabiliser sa consommation de fioul, je n’ai rien trouvé de mieux.

A vous lire de vos propres bidouilles

Amusez-vous bien

Tout d’abord, je vous souhaite à tous une excellente année 2012

Qu’elle vous apporte plein de petits plaisirs et de grand bonheur qui font la joie de notre vie de tout les jours

Je vous propose une petite bidouille rigolote dont je me suis servie dernièrement en l’absence d’accès web sur mon serveur domotique.

Comme nombreux parmi vous je me sers de Dropbox entre mes serveurs, pcs, téléphone Android etc..

Bien évidemment, mon serveur domotique dispose d’un répertoire partagé avec mes autres équipements.

Il m’est arrivé de devoir ouvrir la porte de mon garage à distance (chose courante qui se gère par différents accès SSH, API ou interface Web) mais je n’avais pas accès à ses environnements depuis le lieu où je me trouvais. A part un accès a mon Dropbox…

Et là, j’ai eu une idée farfelue, controler par Dropbox l’interaction avec les équipements domotique

Hop, c’est parti, comment j’ai mis cela en place.

Tout d’abord, bien sûr, il faut sur votre serveur domotique un Dropbox qui tourne

Ensuite, on va utiliser l’excellentissime INCRON

Quoi que c’est INCRON ?

Et bien, c’est une sorte de crontab mais qui se base sur la librairie Inotify du noyau.

En gros, le démon INCRON détecte tout changement sur un ou des fichiers dans un répertoire défini, et exécute une action en conséquence.

Magique

On installe donc INCRON sur notre serveur

apt-get install incron

Dans le fichier /etc/incron.allow on ajoute les utilisateurs autorisés.
On se configure dans le répertoire /etc/incron.d/ deux petites actions, l’un en cas de création ou de copie de fichier dans le répertoire cible, l’autre en cas de suppression de ce fichier.

cat /etc/incron.d/lumieres
 
/home/guiguiabloc/Dropbox/domodrop IN_CREATE,IN_MOVED_TO /usr/local/bin/heyu on $#
 
cat /etc/incron.d/lumieresoff
/home/guiguiabloc/Dropbox/domodrop IN_DELETE,IN_MOVED_FROM /usr/local/bin/heyu off $#

Petite explication :

D’abord, le répertoire à surveiller : /home/guiguiabloc/Dropbox/domodrop

Ensuite l’évènement à surveiller (création, déplacement dedans, suppression, déplacement en dehors etc..)

La liste de tout les évènements possibles est visible en tapant :

$ incrontab -t
 
IN_ACCESS,IN_MODIFY,IN_ATTRIB,IN_CLOSE_WRITE,IN_CLOSE_NOWRITE,IN_OPEN,
 
IN_MOVED_FROM,IN_MOVED_TO,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_CLOSE,
 
IN_MOVE,IN_ONESHOT,IN_ALL_EVENTS,IN_DONT_FOLLOW,IN_ONLYDIR,IN_MOVE_SELF

Enfin, l’action a effectuer, dans le cas de ce test, j’appelle l’utilitaire HEYU ( contrôle X10) et je lui passe en paramètre le nom du fichier par la variable $#.

Et voila, maintenant, par un simple copier-coller, si je dépose le fichier nommé « A2″ dans le répertoire domodrop de mon Dropbox, la lumière référencé par le module A2 s’allume, si je supprime le fichier, elle s’éteint (bien évidemment avec le temps de décalage de synchronisation de Dropbox)

Pour voir ce que cela donne, je vous ai même fait un petit film !

Marrant  

Alors je ne sais pas si cela va vous servir, en tout cas, c’est bien fun :p

Amusez vous bien

Si vous suivez ce blog et ses derniers billets (grand bien vous en fasse ), vous savez que je me consacre de plus en plus à la domotique (pour diverses raisons dont vous trouverez l’explication dans cet historique justement).

En plus de cette passion pour la domotique, je me suis pris d’un grand intérêt pour le protocole xPL.
(et de nouveau je vous invite à lire l’excellent billet de Thibault sur son blog).
Qui dit xPL, dit forcément une lecture soutenue des différentes pages du projet xPL et de la rencontre avec ses différents acteurs.
D’ailleurs, mon engouement sur le sujet vient aussi beaucoup de l’activité française dans ce domaine et des contacts enrichissants et passionnants avec les passionnés de Domotique en France, que je salue au passage, dont le dévouement et l’implication font que cette communauté est a elle seule, une raison de les rejoindre.

Bref, comme vous l’avez vu, j’ai commencé a poindre mon nez en fournissant un premier client xPL écrit en python, qui, à ma grande surprise, a reçu un accueil très favorable et enthousiaste (au point d’être référencé dans les développeurs xPL du projet sur la page d’accueil !!!).
J’avoue avoir était grandement surpris et je remercie les agitateurs du projet pour leur soutien.
D’un autre côté, cela vous met une pression grave (en plus d’une demi-molle je l’avoue…)

Dans cette progression personnelle que j’ai, j’ai donc commencé à pondre du code (et là, les gens qui me connaissent bien doivent halluciner ).
Le langage de développement qui m’a très vite attiré est bien sûr Python (loin de moi l’idée de lancer un troll sans fin sur les remarques « mais t’es nul Java c’est mieux! », parce que bon, java, euh, comment dire… (bah non je vais rien dire mais j’en pense pas moins :p ))
Alors attention, je ne suis pas développeur du tout, mon métier c’est le système/réseau (plutôt réseau d’ailleurs), et donc je conçois totalement d’être hué, haï, conspué et dénigré par des « vrais » développeurs (quand ils existent), et si j’ai fait le choix de Python comme langage de prédilection, c’est qu’il répond à mes attentes, qu’il est très puissant, et que j’aime bien les serpents.
S’tout.

Cela étant dit, pour en revenir à nos moutons, dans une architecture xPL, un des éléments qui peut s’avérer important est ce que l’on appelle le xPLHal.
Vous en trouvez l’explication ici .
C’est un « moteur » central xPL, il écoute les messages transitant dans les hubs xPL et exécutent des actions en conséquence de ses messages ou suivant une programmation horaire définie par l’utilisateur.
Pour contrôler ce moteur, il y a un xPL-HalManager qui est l’interface entre l’utilisateur et le xPLHal.
Alors bien évidemment, cet xPL-Hal n’est pas obligatoire, beaucoup utilisent des scripts maison (surtout dans le monde Linux), ou autres bidouilles.
Sous windows, vous trouverez votre bonheur, mais sous Linux, c’est un peu le désert, a part un XPLHAL java plus maintenu depuis 2008.

Et en python, rien… (a part le projet Domogik bien sûr).
Parent pauvre de la domotique, Linux est durement supporté par une poignée de personnes face aux mastodontes Windoziens (aka Homeseer bien sûr) et c’est bien dommage au regard des gens qui sont actifs dans ce milieu.

Je me suis donc mis en tête et en cheval de bataille sur ses prochains mois, d’écrire un xPLHal en python.
La charge du projet est importante si l’on considère les pré-requis, et peut-être même insurmontable, mais après tout pourquoi pas.
Déjà cela m’obligera a me familiariser avec python, avec xPL, et surtout, le plus important à mes yeux, d’essayer d’offrir quelque chose de plus à la communauté.

Dont acte, début du projet xPL-pyHAL.

J’espère vous donner une première ébauche de ce que j’ai écrit, mais les premiers pas sont encourageants surtout quand on apprend le langage en même temps
Je suis parti pour l’instant sur une configuration à base de fichiers YAML (un simple fichier typé par module à surveiller dans lequel vous spécfifiez les règles a déclencher quand une action sur le module est détectée) et qui pour les premiers tests marchent plutôt bien (action de type HEYU, stockage dans un Memcached ou message de type Notifry (clin d’oeil a Thibault au passage pour son excellent xPL-PushMsg ) etc…) bref, ça avance et j’espère vous détailler plus tard un peu plus de ce projet qui me tient à coeur pour 2012.

Le projet sera hébergé ici : http://code.google.com/p/guiguiabloc/ (avec la création d’un nouveau logo pour l’occasion )

En attendant, je vous souhaite à tous d’excellentes fêtes de Noël et de fin d’année