Standards domotique
Il existe de nombreuses normes de domotique. La plupart sont propriétaires, ne permettant de monter que des équipements du même constructeur. Tous les équipementiers électriques s'y sont mis... et sans toujours se mettre d'accord. Résultat : un beau bordel ! Chacune aura des avantages et inconvénients. Il est du coup assez difficile de se retrouver dans cette jungle.
J'ai personnellement choisi la norme X10, principalement pour son cout. A noter que la norme KNX aurait pu également être un choix intéressant. Norme Internationale ("ISO/IEC 14 543-3") et promue par Konnex (http://www.konnex.fr/) elle est utilisée par de nombreux constructeurs (Siemens, Hager, Schneider, ABB, Hestia, etc...). Les couts restent toutefois plus élevés qu'avec X10.
Le standard X10
X10 n'est pas une norme, mais un standard industriel. Développé en 1975, en écosse, par la société Pico Electronics, il utilise principalement le courant porteur pour faire dialoguer les équipements, bien qu'il soit également possible de communiquer par radio. C'est d'ailleurs ce qui en fait sa simplicité lors de son déploiement. Les équipements compatibles X10 sont identifiés par le logo ci conte.
Il concurrence donc d'autres protocole qui communiquent exclusivement pas radio, ou par n bus propriétaire.
Le principal fabriquant de périphériques X10 est X10 ltd (sous les marques Marmitek en Europe et X10 Powerhouse aux US). Ils fabriquent des équipements en 110V / 60 hz pour le marché nord américain en très grand volume, et du 220V/50 hz pour le marché européen. Malheureusement, la grande diversité de prises secteurs en Europe et le relativement faible taux d'équipements des européens en X10 fait qu'il n'y a pas encore de marché de masse, et les couts restent beaucoup plus élevés pour les variantes européennes que pour les variantes américaines (de 2 à 3 fois plus cher).
Toplogie
Aute point fort du X10, sa topologie. Il existe 2 grandes familles d'équipements X10, qui vont permettre de faire une installation aussi bien dans un bien immobilier qui vous appartient, que dans un bien de location ou tout sera démonté en partant. Pratiquement chaque 'fonction X10' existera dans des modules de plusieurs formats, vous permettant de choisir ce qui vous ira le mieux :
- Des équipements 'amovibles' : Dans cette famille, les modules viennent s'insérer dans la prise murale, entre l'équipement à commander et le secteur. Rien à modifier, tout reste démontable.
- Des équipements fixes : Si vous êtes chez vous et désirez implanter la domotique de façon plus discrète, ces modules seront pour vous. Il en existe des variantes qui pourront être montées dans le tableau électrique (sur rail DIN), ou dans les interrupteurs eux même (modules miniatures, qui utiliseront l'interrupteur d'origine, mais ajouterons la fonction domotique)... L'installation se fera beaucop plus discrète...
Un énorme catalogue :
Il existe un très gros catalogues de modules X10. Le synoptique ci dessous vous donnera un aperçu des possibilités. Vous pourrez trouver plus d'infos sur ce protocole sur le site de wikipedia : http://fr.wikipedia.org/wiki/X10_(informatique) .
Constructeurs X10 :
- Marmitek : Système X10, norme X10, fonctonnant en radio ou CPL
- XDom (France)
- Xanura (Hollande) : http://www.xanura.nl
- Leviton (US, standard américain seulement..) : http://www.leviton.com
- Shangai Super Smart Electronics (chine, mais produit des modules pour l'europe) : http://www.x10bus.com
- Euro X10 (proDuits pour le marché européen) : http://www.eurox10.com/
Choix du matériel
Le calculateur :
Je ne sais pas si à ce stade on peut parler de choix. J'ai en effet trouvé sur un site d'enchères bien connu une carte de petite dimension, qui embarque toutes sortes de périphériques et un processeur à 400Mhz. La consommation étant de 10w, ceci m'a paru un bon choix pour ce type de système. Le prix aussi puisque j'en ai achetée 2 à 30 pièce... Il s'agit d'une carte LE363 de marque COMMELL.
Les choses qui m'ont le plus intéressées sont l'aptitude à mettre une carte Wifi (via l'interface mini-PCI), une carte Compact Flash (pour faire un système entièrement sans disque), une interface disque dur, et le grand nombre d'entrées sorties (USB, liaisons série, parallèle...)
Les caractéristiques de la carte sont les suivantes :
- Facteur de forme: Carte au format 3.5" sans ventilateur
- Processeur : AMD Geode GX533 à 400Mhz.
- Memoire: 128Mo DDR sur carte mère et 1 x 200-pin DDR SODIMM supportant jusqu'à 512 Mo (768Mo au total)
- Chipset : AMD Geode CS5535 .
- Real Time Clock : Chipset Integrated RTC avec batterie Lithium
- Watchdog Timer : Reset du système programmable à l'aide d'un watchdog timer avec 1 ~ 255 sec./min de valeur de timeout .
- Gestion de l'alimentation: ACPI 1.0 version et APM version 1.2
- IDE: Une interface IDE UDMA33 qui supporte jusqu'à 2 périphériques ATAPI. Connecteur intégré IDE 44-pin.
- VGA Interface: Controlleur VGA intégré : AMD Geode GX533 avec moteur 2D . Sortie sur conecteur VGA standard 15 broches.
- LCD Interface: Interface LCD intégrée 18/24-bit TTL/LVDS (simple canal)
- Réseau : 2 contrôleurs Realtek RTL8100B, Ethernet 10/100 Mb/s chacun avec sa prise RJ45.
- Audio: Realtek ALC201A AC97 Codec.
- Clavier / Souris : Interface PS2 pour clavier et souris.
- RS2323 : 2 ports RS232 sur sortie standard.
- USB: 2 ports USB 1.1.
- Imprimante : Port Parallèle standard.
- Floppy : Interface pour floppy (de portale)
- Infrarouge : E/S IRDA (en lieu et place d'un port série)
- Port Audio externe: Line -out , Line-in and MIC-in .
- Solid States Disk : Connecteur Compact Flash connector (utilise l'iDE slave)
- Interfaces étendues: 1 x Mini-PCI & 1 x PCMCIA type 1.
- Alimentation : DC 12V sur 1 jack ou connecteur Molex 4-pin (idem alimentation PC).
- Taille de la carte: 146 mm x 101 mm
Afin de la rendre pleinement fonctionnelle pour mon projet, j'ai donc ajouté à cette carte:
- Une interface Wifi Intel 2200 BG sur le port Mini PCI
- Une antenne de récupération d'un routeur Linksys (le mini connecteur U.FL-LP-066 se monte parfaitement sur la carte Wifi)
- Une mémoire 256Mo SoDimm de récupération, qui viendra s'ajouter aux 256Mo déjà sur la carte mère
- Un disque dur de portable (format 2,5'') de récupération (40Go, cela suffit largement...)
- Une alimentation 12V 2A de récupération
- Un lecteur CDRom de récupération (juste pour l'installation, il sera démonté ensuite...)
- Un clavier, une souris et un écran LCD (qui seront démontés après installation)
A ce stade, j'ai donc un calculateur complet, qui a 512Mo de Ram, 40Go de disque Dur, CD Rom, clavier, souris et son alimentation. Un PC quoi!
Les éléments domotiques :
Mon choix s'est porté sur un kit domotique de Marmitek, fonctionnant avec le protocole X10. Pour moins de 150 il est possible d'acheter sur le site Intellihome.be un 'X10 starter Kit' sous la référence CK15, qui permet déjà de faire pas mal de choses. Je noterai que tout ceci a été expédié en 48 heures, et que les frais de port sont offerts vers la France!
Le contenu du Kit est le suivant :
- CM11 : Interface PC et autonome, série et USB (via un adaptateur USB / série fourni). Livrée avec un logiciel sous Windows, que je n'ai personnellement pas utilisé.
- LM12 : Module gradateur pour lampe 300w
- AM12 : Module 'appliance', permettant de commuter n'importe quel type de charge sur relais (hifi, éclairage, radiateur,etc..)
- TM13 : Module récepteur d'ordre de télécommande radio ET commutation d'une charge fixe de 400w max.
- EasyControl 8 : Télécommande fonctionnant en radio (pour piloter n'importe quel périphérique X10 via la TM13) et infrarouge (7 circuits différents: Télé, DVD, etc..)
Eléments annexes :
Carte relais : J'ai acheté sur Ebay une carte relais, qui pour la modique somme de 35, permet de disposer de 8 relais 220V/10 ampères pilotés par USB (http://sigma-shop.com/product/8/eight-channel-usb-relay-controller-rs232-serial-controlled-12v.html ). Il en existe une à 18, qui ne dispose que d'un relais 220V, mais toujours de l'interface USB: http://sigma-shop.com/product/7/usb-relay-controller-one-channel.html. Le protocole est très simple puisqu'il suffit d'envoyer 3 octets sur la liaison série émulé par le port USB pour allumer ou éteindre un relais. Si la partie USB/série est auto alimentée par le port USB, Il est nécessaire d'adjoindre une alimentation 12V pour la commande des relais (sur la carte 8 relais, la carte mono relais étant totalement auto alimentée). Bonne nouvelle, c'est la même tension d'alimentation que la carte mère COMMELL. Et une alim en moins une!
Carte E/S USB: Achetée en kit pour une trentaine d'euros, la carte interface K8055 est pourvue de 5 canaux d'entrée numériques et 8 canaux de sortie numériques. En outre, vous avez à votre disposition deux entrées analogiques et deux sorties analogiques avec une résolution 8 bit et les 2 premières entrées sont raccordées chacunes à un compteur. En plus des entrées/sorties sur bornier, des boutons poussoirs permettent de déclencher les entrées digitales, des potentiomètres de régler les entrées analogique, et des LEDs affichent l'état des sorties analogiques et digitales. Le nombre d'entrées / de sorties peut être augmenté pour permettre la connexion d'un max. de 4 cartes aux connecteurs USB de votre PC. Elle est livrée avec des exemples de code pour Windows, mais il existe sur Internet plusieurs librairies développées pour l'interfacer avec Linux. Cette carte est alimentée par le port USB.
Choix du logiciel
Le système Linux
J'ai pas mal galéré sur le choix d'une distribution Linux. En effet, mes distributions fétiches (Redhat / Centos) ne sont plus livrées avec des noyaux compilés pour processeurs inférieurs au Pentium 4 (i686). Or le processeurs Geode GX533 n'est compatible que i586,soit la génération d'avant....
Après de multiples essais, j'ai finalement opté pour la dernière distribution Ubuntu 9.04 (sortie en Avril 2009), qui a le bon goût de fournir en option un noyau pour processeurs i386... Le support framebuffer (graphique) pour le chip graphique intégré est défaillant, mais cela fonctionne par contre très bien avec des drivers VESA. Comme la partie graphique n'est nécessaire que lors de l'installation, cela ira bien... En effet, ensuite la carte ne sera gérée que par interface web, ssh et webmin. Le manque de performance de VESA ne sera donc pas un problème. De plus, le système de packaging Debian, allié au dynamisme de la communauté Ubuntu, me permet de disposer d'un système riche et maintenable sans 'recompiler le noyau'.
Le logiciel domotique
J'ai essayé pas mal de choses afin de voir les fonctionnalités. Voici une petite synthèse sur mes essais.
Misterhouse : Déjà un vieux projet (>10 ans), il a ses adeptes, principalement aux US. Il supporte l'interface CM11 de Marmitek. Il est assez bizarrement fait (appréciation toute personnelle), et un peu complexe à prendre en main. Lors de mes essais, la boucle principale prenait 20% de CPU sur ma petite carte... C'est beaucoup! L'interface web livrée est assez moche, bien que tout soit personnalisable. Il existe une interface graphique linux (en TK) également moche. La carte K8055 de Velleman est supportée via une contribution livrée avec le logiciel. Le protocole Xpl serait également supporté, bien que je n'ai pas essayé. Mes conclusions : trop mal architecturé (touffu et bordélique!) et trop lour pour moi.
Domogik : Ecrit en Python, ce projet est probablement le plus prometteur du lot. Il supporte le protocole xpl(natif), X10 (via heyu), et dispose d'une interface Web sympa. Par contre, pour qui veut le faire évoluer, maitrise du Python indispensable. C'est d'ailleurs une des raisons pour lesquelles je ne l'ai pas retenu. Heyu ne supportant que l'interface CM11 de Marmitek, c'est donc la seule interface supportée.
Priscilla : Ecrit en PHP avec le framework MVC Codeigniter, ce n'est malheureusement seulement qu'un bon début. Trouvant l'initiative intéressante, j'ai contacté l'auteur pour lui proposer ma collaboration au projet, mais il ne m'a recontacté qu'au bout d'un mois... J'ai décliné l'offre, ayant trouvé chaussure à mon pied entre temps.
Xpl Project : Pas à proprement parler un projet, mais plus un ensemble de bibliothèques dans des langages variés pour gérer le protocole XPL, XPL Project ne gère exclusivement que ce protocole (http://wiki.xplproject.org.uk). Il est par contre la source d'inspiration de nombreux projets qui intègrent le protocole xpl.
LinuxMCE : Non évalué, car je ne voulais pas installer une distribution orientée domotique, mais un logiciel de domotique dans une distribution standard.
Heyu : Vieux projet également (>10 ans), et grand classique Heyu (http://www.heyu.org/) est développé en C et fonctionne en ligne de commande. Il est porté sur de nombreux systèmes unix (xBSD, MacOS, linux...). Son aptitude à communiquer avec d'autres logiciels, fait qu'il a souvent été intégré, pour servir de base à la transmission X10 dans des systèmes écrits en perl, python, php... Plusieurs frontend existent et notamment un écrit en PHP : domus.Link (http://domus.link.co.pt/). C'est finalement sur ce logiciel que mon choix s'est porté. Léger, performant, et ouvert, il offre de nombreuses possibilités. L'interface web associable (domus.link) est simple et efficace et dispose d'un skin iphone du meilleur effet, qui s'active automatiquement lors de la connexion d'un iphone. Tout accès par une interface web standard rappelant le skin par défaut.
Autres solutions libres, mais sous Windows (pour mémo) :
- http://www.eventghost.org/
- http://www.cebotics.com/
Installation du système
Comme cet article n'est pas fait pour expliquer comment installer Ubuntu (largement documenté par ailleurs), je ne m'étendrai pas sur le sujet. Il a été nécessaire d'ajouter les paquets suivants pour que le système soit fonctionnel :
- Apache
- Php
- MySQL (juste pour l'authentification apache avec mod_auth_mysql)
Étant plutôt familier de Redhat/Fedora/Centos, j'ai un petit peu galéré pour avoir du Wifi sans faire appel à NetworkManager (qui ne s'active que sous X, et je n'avais pas besoin de l'interface graphique...). Autre point de discorde, le boot. En effet, j'ai opté pour la version 09.04 (Ubuntu Fertsy), qui nativement n'aurait tendance à booter que sur des processeurs i686. Or celui de ma carte est un 586... Fort heureusement,il existe un paquet qui fournit un noyau compilé pour i386, et qui m'a permis de régler le problème. En Enfin, dernier point de discorde, le lancement de heyu en tant qu'utilisateur apache. Il m'a fallu créerun script de démarrage quelque peu tweaké pour que cela fonctionne. Il est documenté plus loin dans cet article.
Heyu : Logiciel de pilotage X10
Heyu a été téléchargé (dernière version) à partir du site internet officiel. Il a ensuite été compilé et installé de façon standard. Les fichiers de config sont dans /etc/heyu. L'interface de commande x10 'CM11' ayant été raccordée en ttyS0 (1er port série), le paramétrage a été effectué en fonction. Seuls quelques paramètres ont vu leurs réglages par défaut modifiés :
- TTY /dev/ttyS0 : le port série auquel est rattaché la CM11
- SCHEDULE_FILE x10.sched
- LOG_DIR /etc/heyu : pour disposer d'un fichier de log pour les actions
- HOUSECODE A : A renseigner avec le housecode choisi.
- LONGITUDE Ex:xxx Mettez ici la lattitude / longitude de votre installation pour calcul automatique lever/coucher de soleil.
- LATITUDE Nyy:yyy
Les premiers essais devraient pouvoir être faits en ligne de commande. Pour ce faire il faut :
- Configurer le house code et le device code des différents devices. J'ai personnellement laissé le housecode A, et configuré les périphériques en fonction
- Lancer les services heyu
heyu - Faire un test en ligne de commande :
heyu on A1pour allumer le device A1...
A noter que la commande heyu monitor permet d'afficher un moniteur des commandes reçues sur Heyu. Bien évidemment, lancer dans un shell séparé... et quitter avec CTRL+C.
domus.link : Interface Web pour heyu
Domus Link (http://domus.link.co.pt/) a été installé en /var/www/domus.Link. Le fichier config.php a ensuite été édité pour préciser :
- Le type d'interface :
$config['pc_interface'] = 'CM11A' - La localisation du fichier de config d'Heyu:
$config['heyu_base'] = '/etc/heyu/'; - La localisation du binaire d'Heyu :
$config['heyuexec'] = '/usr/local/bin/heyu'; - Le niveau de sécurité de l'interface (ici pas de sécurité, car l'authentification se fera directement avec Apache):
$config['seclevel'] = '0'; - La langue
$config['lang'] = 'French';
Comme domus.Link va manipuler les fichiers de configuration directement depuis apache, il va être nécessaire de changer les droits sur les fichiers de config d'heyu pour qu'apache puisse les lire et écrire. Mais tout ceci est expliqué dans la doc. Curiosité : Il utilise des des commentaires derrière la ligne de description d'un actionneur X10 pour connaitre l'onglet et la localisation de l'actionneur dans x10.conf. C'est intelligent car cela permet d'ajouter des infos dans les fichiers de config, sans être oblié de patcher heyu, qui les ignorera. Il sera donc toutefois nécessaire de copier les fichiers exemples livrés avec comme indiqué dans la doc d'installation : http://domus.link.co.pt/documentation/installing/ pour bénéficier d'un exemple de config.
C'est assez bien vu, car cela évite d'ajouter des directives de configurations à Heyu et permet une compatibilité totale des fichiers de config, que domus.Link soit installé ou pas...
Par exemple, le commentaire dans la ligne ci dessous précisera que le device sera à placer dans l'onglet Light et sera associé au salon :
ALIAS lumiere_de_lecture A1 StdAM # Light,Salon
Bien sur, il faudra penser à recopier les lignes que nous avons paramétré dans le chapitre précédent : configuration de Heyu.
Après avoir utilisé l'interface web pour configurer le plan et le nom des modules, cela devrait personnaliser le fichier x10.conf avec quelque chose ressemblant aux lignes ci dessous.
ALIAS lumiere_de_lecture A1 StdAM # Light,Salon ALIAS guirlandes A2 StdAM # Light,Salon ALIAS lampe_bleue A3 StdLM # Light,Salle a Manger ALIAS lampe_dessus_meuble A4 StdLM # Light,Salle a Manger ALIAS volets_sam A5 StdAM # Appliance,Salle a Manger ALIAS lumiere_principale A6 StdLM # Light,Chambre parentale ALIAS television_lcd A7 StdAM # Appliance,Chambre parentale ALIAS lumiere_piscine A15 StdAM # Light,Jardin ALIAS pelouse_haut B1 RAIN8 # Irrigation,Jardin ALIAS pelouse_bas B2 RAIN8 # Irrigation,Jardin ALIAS goutte_a_goutte B3 RAIN8 # Irrigation,Jardin ALIAS pompe_piscine B4 StdAM # Appliance,Jardin ALIAS libre5_jardin B5 StdAM # Appliance,Jardin ALIAS libre6_jardin B6 StdAM # Appliance,Jardin ALIAS libre7_jardin B7 StdAM # Appliance,Jardin ALIAS volets_salon A16 StdAM # Appliance,Salon ALIAS tt_lumieres_salon A1,2 StdAM # Light,Salon ALIAS tt_lumieres_sam A3,4 StdLM # Light,Salle a Manger
Et oh miracle, l'interface web se peuple de vos modules X10 :
Ajout d'une carte d'interface USB Velleman K8055
Tout ceci est bien beau, mais il serait sympatique de piloter autre chose que des périphériques X10. Heyu fournit une commande formidable, qui permet de déclencher un script shell à la réception d'un ordre X10 sur une adresse donnée. Il est même possible de filtrer ces ordres pour les prendre en compte en fonction de leur provenance.La doc de x10 (man x10config et man x10scripts) est assez détaillée sur le sujet.
Il ne restait donc plus qu'à trouver une solution pour piloter la carte Velleman. La réponse est venue non pas d'heyu mais de Mister House. En effet, une contribution de Matthew Williams ajoute à Mister House un démon et un client écrits en C++, qui permettent d'envoyer et recevoir des commandes vers la carte. Le démon gérant la mise en attente de commandes, il devient même possible d'envoyer plusieurs commandes 'simultanément'. Ceci peut en effet se produire, soit avec 2 utilisateurs simultanés de l'interface web, ou 2 télécommandes ou 1 télécommande + l'interface web...
Ce démon et la commande associée communiquent en réseau sur le port 9999 par défaut (changeables...) permettant de commander la carte via réseau ethernet. Royal, car l'interface n'a même pas à résider sur le même PC! Il suffit de mettre la carte et le serveur sur un poste, et le client sur un autre... Un autre intéret est que le démon et sa commande n'ont pas à fonctionner sous le même utilisateur. Ainsi Heyu, Apache ou n'importe quel autre programme peuvent envoyer des ordres dès lors qu'ils ont le droit de lancer le client... et de dialoguer avec le port considéré.
Il est possible de trouver ce code soit sur le post original sur Nabble (http://www.nabble.com/K8055-mh-interface-tt2497406.html) ou tout simplement en téléchargeant la dernière version de Misterhouse (http://misterhouse.sourceforge.net/) et en regardant dans le /mh/bin/k8055d.tar.bz2.
Après décompression de cette archive, il suffit de la compiler (make), de lancer le démon (./k8055d) et de jouer avec l'interface de commande qui est très bien documentée :
k8055 <parameters> help: show help debug: show debug info host: connect to <host>, default is 127.0.0.1 port: connect to <port>, default is 9999 pid: show server PID kill: kill server and all clients read: <analogue|digital|counter|all> <port number> write: <analogue|digital> <port number> <value> reset: <counter number> debounce: <counter number> <debounce in ms>
Par exemple ; ./k8055 write digital 1 1 allume la sortie digital une... et ./k8055 write digital 1 0 l'éteint. Trop simple.
L'intégration avec heyu est simple, puisqu'il suffit d'ajouter quelques lignes dans le fichier de config :
- Une pour déclarer l'alias (adresse X10)
- Une pour associer un script sur ordre d'allumage
- Une pour associer un script sur ordre d'extinction.
L'adresse X10 pourra être la même que celle d'un périphérique X10 déjà assigné (et dans ce cas les 2 seront asservis en même temps) ou une adresse libre (et dans ce cas seule la carte relais sera commandée).
Voici un exemple (lignes prélevées de x10.conf) :
ALIAS pelouse_haut A1 StdAM # Irrigation,Jardin SCRIPT pelouse_haut on anysrc :: /usr/local/src/k8055d/k8055 write digital 1 1 SCRIPT pelouse_haut off anysrc :: /usr/local/src/k8055d/k8055 write digital 1 0
A noter qu'ici, la source anysrc a été ajoutée pour que les ordres soient pris en compte dans tous les cas de figure (par l'interface web, via une commande envoyée par la télécommande...). Si on laisse la source par défaut, tous les ordres ne fonctionneront pas...
On peut aussi remplacer 'on' par 'gon' et 'off' par 'goff', ce qui permettra de répondre aussi aux ordre globaux d'extinction.
Ajout d'une carte relais pilotée en USB
La carte Velleman est intéressante, mais a l'inconvénient de ne pas pouvoir piloter du 220V sans ajouter un peu d'électronique pour commander des relais. Ayant trouvé sur un grand site d'enchères en ligne des cartes relais à interface USB, je me suis mis en quête de l'interfacer avec Heyu. Plusieurs solutions s'offraient à moi. Bien sur il est simple d'envoyer des commandes vers une liaison série (en fait cette carte est vue comme un câble série USB à base de composant FTDI232) à partir d'une simple ligne de commande ou petit script en perl, python ou bash. Mais le caractère multitache de Heyu aurait fatalement posé problème. En effet, un port série ne peut être ouvert que d'un process, et si d'autres tentaient de l'ouvrir alors qu'il est occupé, il sortirait en erreur. Il convenait donc d'utiliser la même technique que pour le pilotage Velleman : un démon qui pilote la carte et un logiciel de commande qui émet les ordres.
Le programme de Matthew Williams étant bien écrit, j'ai entrepris de le modifier afin de :
- Supprimer la partie USB
- Supprimer les commandes qui ne m'intéressaient pas (ex : Read ..., Write analog, etc...)
- Ajouter la gestion RS232.
- Changer le port par défaut pour qu'il puisse fonctionner en même temps que k8055d (9998)
Le résultat est le démon relayd associé à l'interface ligne de commande relay. Les sources sont téléchargeables sur http://www.civade.com/images/domotique/relayd.zip.
Les avantages de cette architecture sont les mêmes que pour le driver de la carte k8055: possibilité de mettre la carte sur un autre PC, pas de problèmes de droits avec heyu ou apache pour le pilotage.... J'ai toutefois changé le numéro de port
Le démon tente par défaut d'ouvrir le port ttyUSB0, mais ce réglage peut être changé en passant des paramètres lors du lancement du démon :
Usage : relayd [serial port] [tcp port]
Fork a daemon to drive relay board.
Arguments :
[serial port] optional, default value = /dev/ttyUSB0
[tcp port] optional, default value = 9998
Le client quand à lui dispose des paramètes suivants :
relay <parameters> help: show help debug: show debug info host: connect to <host>, default is 127.0.0.1 port: connect to <port>, default is 9998 pid: show server PID kill: kill server and all clients read: <digital|status> <port number> write: <digital> <port number> <value>
Du coup, l'interface avec Heyu a d'étranges similitudes avec celle de la carte Velleman. Voici un extrait du x10.conf pour une commande (toujours les 3 lignes par ordre...):
ALIAS lumiere_piscine A15 StdAM # Light,Jardin SCRIPT lumiere_piscine on anysrc :: /usr/local/src/relayd/relay write digital 8 1 SCRIPT lumiere_piscine off anysrc :: /usr/local/src/relayd/relay write digital 8 0
/etc/heyu/x10.conf
J'ai mis ici le fichier x10.conf, pour référence. Pas de complexité ou d'astuce particulière. Les coordonnées GPS ont été masquées... vous comprendrez aisément pourquoi.
TTY /dev/ttyS0 HOUSECODE A #LOG_DIR NONE LOG_DIR /etc/heyu SCRIPT_MODE SCRIPTS SCHEDULE_FILE x10.sched MODE COMPATIBLE PROGRAM_DAYS 366 COMBINE_EVENTS YES COMPRESS_MACROS NO LONGITUDE Ex:xxx LATITUDE Nyy:yyy DAWN_OPTION FIRST DUSK_OPTION FIRST MIN_DAWN OFF MAX_DAWN OFF MIN_DUSK OFF MAX_DUSK OFF REPORT_PATH ./ REPL_DELAYED_MACROS NO WRITE_CHECK_FILES NO DEFAULT_MODULE StdLM START_ENGINE AUTO HEYU_UMASK 0000 MAX_PPARMS 8 STATUS_TIMEOUT 2 SPF_TIMEOUT 3 RCS_DECODE OFF ACK_HAILS NO AUTOFETCH YES ALIAS lumiere_de_lecture A1 StdAM # Light,Salon ALIAS guirlandes A2 StdAM # Light,Salon ALIAS lampe_bleue A3 StdLM # Light,Salle a Manger ALIAS lampe_dessus_meuble A4 StdLM # Light,Salle a Manger ALIAS volets_sam A5 StdAM # Appliance,Salle a Manger ALIAS lumiere_principale A6 StdLM # Light,Chambre parentale ALIAS television_lcd A7 StdAM # Appliance,Chambre parentale ALIAS lumiere_piscine A15 StdAM # Light,Jardin ALIAS pelouse_haut B1 RAIN8 # Irrigation,Jardin ALIAS pelouse_bas B2 RAIN8 # Irrigation,Jardin ALIAS goutte_a_goutte B3 RAIN8 # Irrigation,Jardin ALIAS pompe_piscine B4 StdAM # Appliance,Jardin ALIAS libre5_jardin B5 StdAM # Appliance,Jardin ALIAS libre6_jardin B6 StdAM # Appliance,Jardin ALIAS libre7_jardin B7 StdAM # Appliance,Jardin ALIAS volets_salon A16 StdAM # Appliance,Salon ALIAS tt_lumieres_salon A1,2 StdAM # Light,Salon ALIAS tt_lumieres_sam A3,4 StdLM # Light,Salle a Manger SCRIPT pelouse_haut on anysrc :: /usr/local/src/relayd/relay write digital 1 1 write digital 2 0 write digital 3 0 SCRIPT pelouse_haut off anysrc :: /usr/local/src/relayd/relay write digital 1 0 write digital 2 0 write digital 3 0 SCRIPT pelouse_bas on anysrc :: /usr/local/src/relayd/relay write digital 1 0 write digital 2 1 write digital 3 0 SCRIPT pelouse_bas off anysrc :: /usr/local/src/relayd/relay write digital 1 0 write digital 2 0 write digital 3 0 SCRIPT goutte_a_goutte on anysrc :: /usr/local/src/relayd/relay write digital 1 0 write digital 2 0 write digital 3 1 SCRIPT goutte_a_goutte off anysrc :: /usr/local/src/relayd/relay write digital 1 0 write digital 2 0 write digital 3 0 SCRIPT pompe_piscine on anysrc :: /usr/local/src/relayd/relay write digital 4 1 SCRIPT pompe_piscine off anysrc :: /usr/local/src/relayd/relay write digital 4 0 SCRIPT libre5_jardin on anysrc :: /usr/local/src/relayd/relay write digital 5 1 SCRIPT libre5_jardin off anysrc :: /usr/local/src/relayd/relay write digital 5 0 SCRIPT libre6_jardin on anysrc :: /usr/local/src/relayd/relay write digital 6 1 SCRIPT libre6_jardin off anysrc :: /usr/local/src/relayd/relay write digital 6 0 SCRIPT libre7_jardin on anysrc :: /usr/local/src/relayd/relay write digital 7 1 SCRIPT libre7_jardin off anysrc :: /usr/local/src/relayd/relay write digital 7 0 SCRIPT lumiere_piscine on anysrc :: /usr/local/src/relayd/relay write digital 8 1 SCRIPT lumiere_piscine off anysrc :: /usr/local/src/relayd/relay write digital 8 0
Industrialisation
L'industrialisation du montage est assez simple, puisqu'il faudra :
- Le placer dans un boitier étanche, et réaliser le cablage vers les périphériques
- Mettre les bon droits sur les devices (notamment /dev/ttyS0, car il doit être accessible par apache)
- Lancer les démons k8055d et relayd
- Lancer Heyu en tant qu'utilisateur apache (www-data sur Ubuntu)
- Lancer Apache
- Mettre en place des crons pour que l'arrosage auto arrose, que la pompe de la piscine pompe, etc...
- Mettre en place des crons de sécurité pour remettre à zero les sorties de la carte relay régulièrement
Le boitier étanche :
J'ai acheté un boitier électrique de grande taille dans une grande surface de bricolage pour 39. Il possède des sorties obturées d'un opercule percutable pour conserver l'étanchéité. Un jeu de lamages avec un préperçage permet de fixer une platine au fond du boitier. J'ai donc réalisée une platine en plastique, que j'ai percée pour fixer :
- l'alimentation 12V
- La carte mère (au dessus de l'alim)
- Un fusible de protection de l'alim 12V
- L'interface CM11
- La carte relais
- La carte d'adaptation usb/série vers carte relais
La capot a également été aménagé pour mettre 2 leds (HDD & Power) et un interrupeur fugitif à 3 positions :
- Reset
- Repos (rien)
- Power
Des photos du boitier fini et monté suivront...
Le boitier a ensuite été monté dans lmon local piscine, et les électrovannes de l'arrosage raccordées aux sorties relais 1 à 3, le moteur piscine à la sorite 4, et la lumière de la piscine à la sortie 8. Il reste donc encore 3 sorties relais libres pour extensions futures (éclairage jardin, etc..).
Les scripts :
Script de démarrage de heyu (SysV). Il sera chargé de la mise en place des droits sur l'interface série (ttyS0) et du lancement d'Heyu en tant que user apache (www-data).
#!/bin/sh -e
### BEGIN INIT INFO
# Provides: heyu
# Required-Start: $local_fs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/stop heyu server
### END INIT INFO
#
# heyu This init.d script is used to start heyu.
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
. /lib/lsb/init-functions
#. /etc/default/rcS
# For heyu, will be launched as apache, so needs access to serial port
/bin/chmod o+rw /dev/ttyS0
case "$1" in
start)
log_daemon_msg "Starting heyu" "heyu"
start-stop-daemon --start -c www-data:www-data --make-pidfile --pidfile /var/run/heyu.pid --exec /usr/local/bin/heyu start
exit 0
;;
stop)
log_daemon_msg "Stopping heyu" "heyu"
start-stop-daemon stop exec /usr/local/bin/heyu stop
exit 0
;;
reload)
if [ ! -f /var/run/heyu.pid ] ; then
log_daemon_msg "Starting heyu" "heyu"
start-stop-daemon --start -c www-data:www-data --make-pidfile --pidfile /var/run/heyu.pid --exec /usr/local/bin/heyu start
exit 0
else
log_daemon_msg "Restarting Heyu" "heyu"
start-stop-daemon --stop --exec /usr/local/bin/heyu stop
start-stop-daemon --start -c www-data:www-data --make-pidfile --pidfile /var/run/heyu.pid --exec /usr/local/bin/heyu start
exit 0
fi
;;
esac
Script /etc/rc.local (lancement des démons k8055 et relayd)
# rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. # Launch relay daemon /usr/local/src/relayd/relayd # Launch k8055 daemon /usr/local/src/k8055/k8055d exit 0
Les crons
Tous les crons de gestion d'heyu ont été regroupés dans /etc/cron.d/heyu. En voici le listing : e
# /etc/cron.d/heyu: crontab entries for the heyu package SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin ######################################################################### ## Sécurité : provoque des coupures sur les relais à intervalle régulier ######################################################################### # a 3h00 coupe toutes les vannes d'arrosage, tous les jours 00 3 * * * root heyu off B1 00 3 * * * root heyu off B2 00 3 * * * root heyu off B3 # a 22h00 coupe la pompe de la piscine tous les jours 00 22 * * * root heyu off B4 # a 0h00 coupe les voies inutilisées 00 0 * * * root heyu off B5 00 0 * * * root heyu off B6 00 0 * * * root heyu off B7 # a 1h00 coupe la lumière piscine (mise en A15 pour être commandable par la télécommande HF) 00 1 * * * root heyu off A15 ######################################################################### ## Attention a veiller à ce que les cycles ne soient pas interrompus ## par les extinctions de sécurité (voir ci dessus). ## Nota: les scripts associés ferment les autres électrovannes lorsque ## l'on en allume une nouvelle. La pression d'eau ne permet en effet pas ## d'arroser les 3 zones en même temps. ## Ceci n'est vrai que pour les voies B1/2/3 (ev d'arrosage). ## Les autres voies (A15,B4 à B7) sont indépendantes. ######################################################################### # Pelouse haut de 2h00 à 2H10 00 2 * * * root heyu on B1 # Pelouse bas de 2h10 à 2h20 10 2 * * * root heyu on B2 # Goutte à Goutte de 2h20 à 2h40 20 2 * * * root heyu on B3 # Fin d'arrosage 40 2 * * * root heyu off B3 ######################################################################### # Cycle piscine ######################################################################### # heures creuses de nuit : 6 heures 00 1 * * * root heyu on B4 00 7 * * * root heyu off B4 # heures creuses de de midi : 2 heures 00 12 * * * root heyu on B4 00 14 * * * root heyu off B4 # Plage additionnelle 00 15 * * * root heyu on B4 00 17 * * * root heyu off B4
Reste à faire
- interface web pour l'administration des taches programmées - Intégration des volets roulants : modules reçus, à poser.....
