GuiguiAbloc

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 3 litres 78 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

En voila du titre bien décousu

En fait, j’ai passer quelques semaines a mettre en place différentes solutions dans mon environnement domotique et plutôt que d’en faire plein de petits billets, j’ai décidé de tout regrouper en un, à vous de piocher dedans

Pour résumer la situation, je voulais d’abord que mon serveur Domotique « parle » (ça c’est plutôt simple), que lorsque j’allume mon portable au sous-sol, j’entende les messages audio du serveur (la ça se complique, si comme moi, vous ne souhaitez pas faire du multicast dans votre LAN), et enfin, comble du geekissime domotique, je voulais récupérer en temps réel les alarmes Zoneminder dès la détection d’un mouvement dans le champ de la caméra et que mon serveur Domotique me l’annonce de sa douce voix (la, ça se complique beaucoup, vous verrez…)

Bref, après plusieurs semaines, tout cela fonctionne, voyons comment.

• SYNTHESE VOCALE ou comment faire parler une machine

Pour l’installation d’un synthèse vocale sur un serveur Linux, rien de plus simple.

Plutôt que de refaire un énième billet a ce sujet, je vous renvoie vers le blog de Christophe Nowicki dont je vous avez déjà parler, qui explique très bien la façon de le faire :

http://www.csquad.org/2009/08/27/text-to-speech-avec-espeak-mbrola-et-speech-dispatcher/

Il existe bien sûr d’autre tutos, mais Christophe a beaucoup travailler sur le « son » en Domotique et son blog regorge d’infos intéressantes.

Bilan après installation, un système de synthèse vocale installé sous /opt/mbrola

et bien sûr, les commandes essentielles à la création et gestion des « voix » :

(ps : fr4 est une voix française féminine, bizarrement je préfère :-p )

(NB: a l’attention de Fred, je n’arrive pas a reproduire la voix de Karen Cheryl… Désolé… (ou tant mieux pour nous…)

- Convertir le texte écrit dans le fichier « texte » en un phonème compréhensible par Mbrola

espeak -x -v mb/mb-fr4 -f texte > texte.pho

- Faire parler le serveur en lisant le phonème

mbrola -t 1.0 -e -C « n n2″ /opt/mbrola/fr4/fr4 texte.pho -.au | aplay

- Convertir la phrase lue par mbrola en un fichier Wav

mbrola -e -C « n n2″ /opt/mbrola/fr4/fr4 texte.pho texte.wav

(pour les options mbrola que j’utilise, t = la vitesse de lecture, voir la doc officielle)

Pour lire le wav en ligne de commande, mplayer est votre ami.

• PULSEAUDIO ou le son en réseau

Voila la partie où j’ai passer le plus de temps.

Je souhaitais récupérer le son émis par mon serveur sur mon portable connecté en Wi-Fi.

Le premier serveur de son qui m’est venu a l’esprit fut bien sur Pulseaudio.

C’est là que les complications sont arrivées…

Pulseaudio peut fonctionner en multicast, comprendre que le son est diffusé dans tout le LAN, il peut même s’intégrer a Avahi (le mDNS type « Bonjour »).

Sauf que moi le multicast, j’aime pas ça (va comprendre Charles…) et qui plus est, j’ai un LAN segmenté par VLAN et centralisé par du Cisco, et la conf multicast sous Cisco, ca me fait mal au crâne

Donc, out le multicast, je veux de l’unicast TCP (bah oui, j’aime bien les trames réseaux bien proprettes )

L’installation de Pulseaudio sous Debian Lenny passe par un apt-get install tout simple (n’oubliez pas pulseaudio-utils)

Côté configuration sur le serveur Domotique :

srvdomotique:/etc/pulse# cat default.pa
#!/usr/bin/pulseaudio -nF
.nofail
load-sample-lazy pulse-hotplug /usr/share/sounds/startup3.wav
.fail
.ifexists module-hal-detect.so
load-module module-hal-detect
.else
load-module module-detect
.endif
### Load several protocols
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix socket="/tmp/.esd/socket"
.endif
load-module module-native-protocol-unix
load-module module-esound-protocol-tcp auth-anonymous=1
load-module module-native-protocol-tcp listen=192.168.43.100 auth-anonymous=1
load-module module-tunnel-sink server=192.168.8.201 sink_name=copie
load-module  module-combine sink_name=combined master="copie" slaves="alsa_output.pci_10de_3f0_alsa_playback_0"
.ifexists module-gconf.so
.nofail
#load-module module-gconf
.fail
.endif
### Automatically restore the volume of playback streams
load-module module-volume-restore
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-suspend-on-idle
.ifexists module-x11-publish.so
.nofail
load-module module-x11-publish
.fail
.endif
set-default-sink combined

Petite explication.

La ligne : « load-module module-native-protocol-tcp listen=192.168.43.100 auth-anonymous=1″ signifie que vous écoutez sur l’ip 102.168.43.100 et que vous autorisez les connexions anonymes (on va filter au niveau ACL du cisco)

La ligne : « load-module module-tunnel-sink server=192.168.8.201 sink_name=copie »

désigne le « client » qui va écouter les sons émis par le serveur domotique (en fait le client est le serveur domotique qui va émettre le son vers un serveur pulseaudio distant à l’ip 192.168.8.201…)

La ligne : « load-module  module-combine sink_name=combined master= »copie » slaves= »alsa_output.pci_10de_3f0_alsa_playback_0″ »

génère un « sink » (une destination audio si vous préférez), qui comprend ET le pc a l’adresse 192.168.8.201 (alias copie) ET la carte son du serveur Domotique.

Flux par défaut : set-default-sink combined

Ce qui veut dire que tout son émis doit être diffusé simultanément sur la carte son du serveur Domotique (je peux donc l’entendre par les enceintes branchées dessus) et sur les enceintes du PC client.

C’est clair ?

Sur le serveur Domotique, dont le système de son est géré par ALSA, je spécifie que tout les sons doivent être envoyés au démon PulseAudio grace au fichier /etc/asound.conf

srvdomotique:/etc# more asound.conf
pcm.pulse {
type pulse
}
 
ctl.pulse {
type pulse
}
 
pcm.!default {
type pulse
}
 
ctl.!default {
type pulse
}

Reste à lancer pulsaudio (ou par la commande pulseaudio -Cvvv pour voir ce qui se passe ou par la commande pulseaudio -D pour le daemoniser en arrière plan).

Les sons émis par votre serveur doivent être audible sur les enceintes de celui-ci.

Sur le PC client (mon portable en l’occurence), installation de pulseaudio normale, puis un default.pa comme suit :

#!/usr/bin/pulseaudio -nF
.ifexists module-hal-detect.so
load-module module-hal-detect
.else
load-module module-detect
.endif
.ifexists module-esound-protocol-unix.so
.endif
load-module module-native-protocol-unix
load-module module-esound-protocol-tcp auth-anonymous=1
load-module module-native-protocol-tcp listen=192.168.8.201 auth-anonymous=1
.ifexists module-gconf.so
.nofail
.fail
.endif
load-module module-volume-restore
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-suspend-on-idle
.ifexists module-x11-publish.so
.nofail
load-module module-x11-publish
.fail
.endif

Rien d’autre (pas de fichier /etc/asound.conf, pas de données dans client.conf)

Lancer pulseaudio sur le client puis lancer pulseaudio sur le serveur Domotique. Les sons émis par le serveur domotique arrive sur le pc portable (même dans KDE pour ma part…)

Oui, MAIS !!!

Le gros problème est que si le PC portable se connecte APRES le démarrage de PulseAudio sur le serveur Domotique et bien, cela ne fonctionne plus !!!!

J’ai passé des jours a chercher et je n’ai pas réussi a comprendre pourquoi le serveur Domotique ne voyait pas le portable se connecter… J’ai tourner dans tout les sens, impossible de le faire marcher comme cela donc si vous avez une solution, je suis preneur !!!

Mais je n’allais pas en rester la et donc pour réussir ce tour de force, j’ai décider de forcer l’enregistrement du pc portable sur le serveur son Domotique via quelques scripts.

Alors, un peu de compassion pour moi, je ne suis pas développeur et c’est sûrement très crado comme code mais au moins ça marche :-p

- Technique d’enregistrement d’un client PulseAudio via socket en Python.

Sur le serveur Domotique, on va faire tourner un petit serveur codé en Python qui écoute sur le port tcp 12345 :

srvdomotique:~# cat pulseserver.py
#!/usr/bin/python
import socket
import subprocess
import sys
import os
servsock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
 
try:
    servsock.bind(('',12345))
 
except socket.error:
        print "Relance Pulse"
        pidpulse = subprocess.Popen("ps acx | grep pulseaudio | awk '{print $1}'", shell=True, stdout=subprocess.PIPE)
        pid = pidpulse.stdout.read()
        print pid
        os.kill(int(pid), 9)
        pidpulse.stdout.close()
        subprocess.call(["pulseaudio -D"],shell=True)
        servsock.bind(('',12345))
 
servsock.listen(1)
while True:
sock,addr = servsock.accept()
echo = sock.recv(1024)
subprocess.call(["/home/scripts/enregistrement_station.sh"],shell=True)
sock.send(echo)
sock.close()

Quand le client se connecte, le serveur domotique lance le script enregistrement_station.sh :

#!/bin/bash
PIDPULSE=` ps acx | grep pulseaudio | awk '{print $1}'`
kill -9 $PIDPULSE
pulseaudio -D
sleep 2
mplayer /opt/sound/notify.wav
mbrola -t 1.1 -e -C "n n2" /opt/mbrola/fr4/fr4 /opt/mbrola/enregistrement_station.pho -.au | aplay

Dans /etc/rc.local, vous n’avez plus qu’a rajouter la ligne :
/cheminduscript/pulseserver.py &
pour le lancer au boot du serveur.

Côté PC portable, le script de connexion.sh :

#!/bin/bash
PIDPULSE=` ps acx | grep pulseaudio | awk '{print $1}'`
# On allume le haut-parleur a 80%
amixer -q set Master 80%,80%  unmute
if  test -n "$PIDPULSE"
then
echo "pulseaudio actif"
else
pulseaudio -D
fi
sleep 1
python /home/guiguiabloc/pulseclient.py
exit 0

Et le client en python (pulseclient.py)

#!/usr/bin/python
import socket
client = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
host = 'srvdomotique'
port = 12345
print 'Connexion sur ', host, port
client.connect((host, port))
client.close

Je vous le conçois, c’est bourrin…
Quand le portable lance le script « connexion.sh », il lance pulseaudio en local, se connecte au serveur domotique sur le port 12345 qui kill son pulseaudio et le relance, puis fait dire au serveur domotique une phrase annonçant l’enregistrement de la station.
Mais au moins ça marche…

Donc si vous avez d’autres solutions, je suis à votre écoute

• ZONEMINDER et xAP (avec un soupçon de SEC)

Dernière étape de mon travail, mon zoneminder.

ZoneMinder, c’est « vachement » bien, ça fait plein de truc par défaut mais il me manquait une fonction essentielle.

Quand l’on positionne ses caméras en mode « Modect », il détecte les mouvements dans la zone que vous avez définie et enregistre la séquence. Une fois achevée, il vous envoie un email pour vous prévenir d’un mouvement et vous donne le lien vers le « film ».

Super, mais entre le moment où ZoneMinder déclenche l’enregistrement, l’achève après un temps pré-défini (j’utlilise un buffer de 10 secondes avant et 30 secondes après), et vous envoie le mail, bah il se passe plusieurs secondes, voir minutes.

Ce que je voulais c’est que dès qu’un mouvement était détecté par la caméra, ZoneMinder me prévienne d’une manière ou d’une autre. Dans mon cas, en me l’annonçant de sa douce voix (via mbrola).

Ce n’est pas natif dans les fonctions de ZoneMinder et mon bonheur je l’ai trouvé (après moults recherches je vous l’avoue), chez xAP.

Pour résumer, xAP est un protocole open dédié a l’automatisation. C’est la première fois que j’en entendais parler et les fonctionnalités sont nombreuses et puissantes.

Et l’une de ses nombreuses fonctionnalités justement, c’est sa possibilité d’intégration avec ZoneMinder, via un script perl nommé ZMXAP.

En fait, au fin fond du WiKi Zoneminder, on trouve un article dessus :

http://www.zoneminder.com/wiki/index.php/Zmxap

Ni une ni deux, on se télécharge le bazar ici :

http://www.limings.net/xap/zmxap/zmxap-v0.9.tar.gz

La conf est trivial, juste a spécifier nohub=1 dans le zmxap.conf et surtout, pour le besoin que j’avais, générer un fichier de log avec la variable log_file = /tmp/zmxap.log

Car  zmxap est capable d’intéragir directement avec Zoneminder et donc de recevoir en temps réel les informations qui en découlent.

Petit test pour le vérifier :

On lance Zmxap.pl avec la variable du path :

/opt/scripts/zmxap/zmxap.pl -path=/opt/scripts/zmxap &

On passe la caméra en mode « Modect », on passe devant elle et on regarde ce qui se passe dans le fichier /tmp/zmxap.log

24.08.2010 19:32:08 [INFO] (main::loadMonitors): Loading monitors
######## in sendAlarmEvent
####### state=2 and cause=Motion
###### starting fetch of event_data
###### completed fetch of event_data
######## completed sendAlarmEvent
24.08.2010 19:36:03 [INFO] (checkState) Sous_Sol - initiating alarm state
######### completed sendTrackingEvent
24.08.2010 19:36:18 [INFO] (checkState) Sous_Sol - resuming idle state
######## in sendAlarmEvent
####### state=0 and cause=Motion
###### starting fetch of event_data
###### completed fetch of event_data

Magique !!!

ZMXAP a détecté immédiatement le passage (initiating alarm state) puis on voit l’enregistrement se faire.

Ne reste plus qu’a analyser ce fichier de log en temps réel pour remonter l’info.

Et qui a-t-il de mieux pour analyser un fichier de log temps réel ? hein ? Pourtant je vous en avez déjà parler :

http://blog.guiguiabloc.fr/index.php/2009/03/18/interception-des-erreurs-applicatives-dans-nagios-avec-sec-et-prelude-lml/

SEC bien sûr !!!

Allez hop, on se configure notre sec.conf :

type=single
ptype=RegExp
pattern=Sous_Sol(.+)alarm
desc=$0
action=shellcmd  /opt/scripts/AUDIO_alarme_soussol.sh

le script AUDIO_alarme_soussol.sh ne fait que lire une phrase disant « attention y’a un méchant monsieur au sous-sol » (ou autre chose hein…)

Ne reste qu’a lancer tout cela ensemble :

#!/bin/bash
/opt/scripts/zmxap/zmxap.pl -path=/opt/scripts/zmxap &
/usr/local/bin/sec/sec.pl -conf=/usr/local/bin/sec/etc/sec.conf -input=/tmp/zmxap.log -log /var/log/sec.log &

Et voilà, désormais, en plus d’enregistrer les mouvements détectés, ZoneMiner vous prévient immédiatement dès qu’il détecte un mouvement !

C’est pas beau ça ?

Voila un tour de ce que j’ai mis en oeuvre ses dernières semaines, j’avoue que pulseaudio m’a beaucoup coûter en temps, essayant de lui faire recharger sa configuration quand il voyait le portable mais sans succès.

En tout cas, désormais, tout fonctionne à merveille et après tout, c’est tout ce que l’on en attend.

Amusez vous bien

Aujourd’hui je vais vous parler d’un sujet qui me trottiner dans la tête depuis bien longtemps, mais pour lequel je n’avais jamais pris le temps de me lancer sérieusement : la Domotique.

Pour ceux, les plus jeunes d’entre-vous certainement, qui se pose la question de la relation tordue avec le titre de ce billet, je vous invite à visionner cette vidéo…

Pour les puristes geeks de ma génération, bien évidemment, vous aurez reconnu la cultissime phrase du doux HAL9000 dans 2001, l’Odyssée de l’espace

Donc forcément, cause a effet, intelligence artificielle perverse, ordinateur… domotique…

Ok, je suis toujours « abloc », même en 2010

Ma première approche de la domotique remonte a plusieurs années, avec un logiciel désormais culte : « MisterHouse« .

J’en garde un souvenir amusé des possibilités pourtant énormes mais n’ayant aucun équipement domotique, et n’ayant pas de besoin à ce sujet, j’étais vite passé à autre chose.

2010, le sujet domotique me titille et je décide de jeter un oeil à ce qu’il se fait et a réfléchir à son intégration avec mon bazar informatique…

D’abord soyons clair, pour moi la Domotique ne se limite pas a allumer ou éteindre une ampoule, ou a régler mon chauffage, j’ai une vision beaucoup plus large, incluant tout ce que mon environnement extérieur peut offrir a être controlé et géré par un ordinateur.

En ce sens, j’utilise déjà la domotique pour plusieurs choses :

• la Vidéosurveillance à mon domicile avec ZoneMinder
• La VoIP avec Asterisk et un boitier PAP2T
• Le contrôle électrique de certains équipements par sms/mail
• Le suivi de la stabilité de mon courant électrique via Nut et Cacti
• Une centrale d’alarme avec transmission téléphonique
• etc… etc…

Bref, j’utilise en quelque sorte déjà la domotique pour me faciliter la vie.

Au fil de ma remise à niveau, j’ai étais surpris de découvrir une communauté francophone très active et surtout, chose primordiale à mes yeux, de nombreux projets OpenSource dont certains très avancés.

Donc je vous propose au fil de certains billets de vous montrer l’avancement dans ma démarche « domotique » avec mes yeux de novices, de vous faire part des spécificités que je pourrais rencontrer (dans le sens ou je ne veux aucun logiciel propriétaire), de mes déboires ou réussites et surtout, car l’argent est le nerf de la guerre, combien tout cela m’a coûter

• Un nouveau serveur

Tout d’abord, afin de centraliser tout cela, j’ai décider de m’installer un nouveau pc (encore !) qui sera mon « serveur domotique ».

Un tour chez Cybertek à Brest et, délesté de 194,00 euros, je suis reparti avec :

- un boîtier « moyen tour » Advance Triolus avec une alim 480w (39,00 euros)

- une carte mère Gigabyte M61PME-S2 (41,00 euros)

- un processeur AMD Athlon 64 5200+ 2,6Ghz (58,00 euros)

- un disque dur Maxtor de 160go Serial ATA II (34,00 euros)

- 1 Go de RAM DDR2-800 (22,00 euros)

Une petite heure de construction « mécano » et d’installation d’une Debian Lenny toute fraîche et voila un serveur domotique silencieux (avis très personnel ) et une puissance largement suffisante.

• Vidéosurveillance

Je me suis empressé de réinstaller ZoneMinder en dernière version depuis les sources (relire mon ancien billet à ce sujet, d’ailleurs la version 1.24.2 gérant v4L2 ma webcam a fonctionner sans recours a aucun artifice) et suite a la récupération de 2 caméras exterieures noir et blanc, j’en ai profiter pour acheter une nouvelle carte d’acquisition vidéo certifiée ZoneMinder.

Cette carte je l’ai trouvée chez Bluecherry et j’ai choisi le modèle PV-149 que vous trouverez ICI .

Côut de l’acquisition : 198,45 $ livraison par DHL soit 143,59 euros (+29 euros de taxe à l’arrivée… )

Livraison ultra-rapide ! (commandée le 29 décembre au soir, reçue le 04 janvier matin…), comme quoi un paquet venant du Missouri (USA) par DHL à destination de la Bretagne va plus vite qu’une lettre Paris -> Bretagne Bravo la poste :p , vous vous remarquez par votre lenteur, comme d’habitude (vengeance très personnelle, s’il y avait un service publique le plus pitoyable a élire, pour moi, bien en tête, arrive La Poste.)

On colle la carte et hop :

[   14.982461] bttv0: detected: Provideo PV150A-1 [card=98], PCI subsystem ID is aa00:1460
[   14.982461] bttv0: using: ProVideo PV150 [card=98,autodetected]

Détectée et reconnue sans aucun problème et création dans la foulée de 4 périphériques /dev/video (notée de 1 à 4).

On branche les caméras (usb en /dev/video0 et les filaires en RCA/BNC sur /dev/video1, /dev/video2) et reconnaissance immédiate sous ZoneMinder, aucun soucis.

Une carte que je vous conseille donc les yeux fermés si vous utilisez ZoneMinder.

Côté vidéosurveillance, je suis prêt.

• Le matériel Domotique

La, ca se complique…

Après avoir fouillé le net et lu des centaines et des centaines d’articles, j’en retire un constat simple.

En France, avec la distribution existante, les logiciels OpenSource existant ou en voie de développement et le coût des équipements, il n’existe pas de centaines de solutions, surtout, si comme moi, vous partez d’une maison déjà construite, avec un existant électrique et/ou filaire.

Je ne vais pas tergiverser a ce sujet (d’ailleurs je suis ouvert a toutes vos critiques sur les commentaires), mais je me suis ciblé sur 2 architectures.

Le X10 et le RF (via RFXCOM).

Alors oui le PCLBUS c’est mieux (outch les prix… ), le 1wire c’est fun (super je vais tirer du cablâge partout), le ZigBee (oui mais ils sont fachés avec la GPL… et cela ca me plait moyen), etc, etc…

Bref, j’ai un peu fait le tour avec mes pré-requis de facilement adaptable, pas trop cher et déjà intégrer a la communauté du libre et j’en suis retombé sur les deux technos pré-citées.

Puisque des liens il faut, des liens il y aura, voici les sites que j’ai fouillé le plus :

-  http://www.csquad.org/ (excellent)

- http://slobberbone.free.fr/dotclear/index.php?post/2009/10/14/Domotique-Quelque-complements

- http://www.civade.com/2009/05/23/36-domotique-homeautomationx10-open-source-heyu
-linux-ubuntu-relais-usb-velleman-k8055

- http://slayer-zone.over-blog.com/article-17608316.html

- http://blog.locqueneux.com/ (très bonne source d’informations)

- http://www.macoda.com/index.php/Domotique:apport

etc…

Sans oublier les forums touteladomotique, La maison de la domotique etc… bref googlisez…

J’ai donc fixé mon choix pour commencer par un module CM11, qui est une interface de contrôle X10 reconnue sous linux que j’ai commandé chez Domadoo et expédié en vitesse record ! bravo a eux pour la rapidité.

Le module se branche tout simplement a une prise électrique et le port USB, sur le serveur domotique qui est reconnu immédiatement en tant que périphérique /dev/ttyUSB0

[   14.442321] usbserial: USB Serial support registered for pl2303
[   14.442341] pl2303 2-4:1.0: pl2303 converter detected
[   14.464989] usb 2-4: pl2303 converter now attached to ttyUSB0
[   14.464989] usbcore: registered new interface driver pl2303
[   14.464989] pl2303: Prolific PL2303 USB to serial adaptor driver

J’y ai rajouté un transmetteur RF/X10 (TM13) et une douille X10 (LM15) pour m’amuser.

Coût de l’opération : 107,85 euros

• La partie logicielle

Sous Linux, pour la gestion de tout cela, il existe plusieurs projets et l’un des plus connu est Heyu.

L’installation est triviale et en quelques minutes, vous devez être en mesure de contrôler vos modules.

Côté interface Web, j’ai eu un petit faible pour Domus Link :

Mais mon gros coup de coeur va sur un projet des plus prometteurs : Domogik.

Outre le fait que le projet est français, leur approche se base sur le projet  xPL en tant que « centralisateur » des différentes technos existantes (plus d’infos ICI ) et la future interface graphique est de toute beauté.

Bien entendu le projet est actuellement en plein développement mais l’équipe promet de livrer une première version exploitable ce semestre.

En attendant vous pouvez toujours tester l’existant a partir des sources disponibles (voir ICI ) et discuter si vous le souhaiter avec l’équipe très sympa sur le canal irc #domogik sur le reseau Freenode.

Voila ma première approche « Domotique » a la maison dont je risque, certainement, de revenir vous en parler au fur et a mesure de mes découvertes et expériences à ce sujet.

Amusez-vous bien