URL: https://linuxfr.org/news/domotique-libre-ou-en-sommes-nous Title: Domotique libre, où en sommes‐nous ? Authors: RbN Davy Defaud, kYc0o, baud123, detail_pratique, Raoul Hecky, patrick_g, Benoît, Epy, Pierre Jarillon, Olivier Esver et jihele Date: 2012年09月22日T20:41:22+02:00 License: CC By-SA Tags: domotique, compteur_communicant, diy, franglais, alarme, sécurité et linky Score: 62 La [domotique](http://fr.wikipedia.org/wiki/domotique "Définition Wikipédia"), d’après Wikipédia, est l’ensemble des techniques de l’électronique, de physique du bâtiment, d’automatisme, de l’informatique et des télécommunications utilisées dans les bâtiments et permettant de centraliser le contrôle des différents applicatifs de la maison (système de chauffage, volets roulants, porte de garage, portail d’entrée, prises électriques, etc.). La domotique vise à apporter des fonctions de confort (gestion d’énergie, optimisation de l’éclairage et du chauffage), de sécurité (alarme) et de communication (commandes à distance, signaux visuels ou sonores, etc.) que l’on peut retrouver dans les maisons, les hôtels, les lieux publics, etc. La domotique est également très proche de la gestion technique du bâtiment (GTB) et de la gestion technique centralisée (GTC), cet ensemble de techniques est régulièrement mis en avant pour atteindre les buts de [ville intelligente](http://fr.wikipedia.org/wiki/Ville_intelligente) et de [réseau de distribution d’électricité « intelligent »](http://fr.wikipedia.org/wiki/Smart_grid), et est perçu comme un moyen incontournable pour atteindre une meilleure efficacité énergétique. Les plus curieux quant aux possibilités offertes se référeront au très bon article de Wikipédia : [_Domotique_](http://fr.wikipedia.org/wiki/Domotique "Définition Wikipédia"). Cette dépêche est une introduction à la pratique de la domotique avec des logiciels libres pour un public ayant de bonnes connaissances en informatique et réseau. La première partie contient un résumé des protocoles couramment utilisés dans le domaine, et permettra au lecteur de prendre connaissance des principes sous‐jacents et de l’empilement protocolaire mis en œuvre. La seconde partie traite des logiciels libres qui peuvent être utilisés pour contrôler une installation domotique. Elle traite également des briques logicielles libres permettant de réaliser une telle application pour un développeur. N.D.A. : Merci à _baud123_, _Benoît_, _detail_pratique_, _Epy_, _jihele_, _kYc0o_, _Olivier Esver_, _patrick\_g_ et _Raoul Hecky_ pour leur participation à la rédaction de cette dépêche. ---- [Le wiki francophone de la domotique](http://domotiki.fr/) ---- #Les protocoles L’essence même d’une installation domotique est la communication entre ses différents éléments. Pour cela, beaucoup de protocoles sont nés, car chaque constructeur a réalisé son protocole de communication, ce qui a conduit à une situation très complexe. Les protocoles présentés ci‐dessous ne sont pas des protocoles propriétaires : la plupart sont standardisés et/ou ouverts. ##Protocoles sans fil Les protocoles sans fil sont très appréciés actuellement, la grande liberté de placement des capteurs et interrupteurs qu’ils apportent leurs permettent d’être placés dans des endroits parfois improbables, bien souvent dans ce que l’on appelle les « derniers mètres », ces endroits depuis lesquels on a besoin d’informations, mais où il est relativement coûteux de câbler un bus de terrain dédié. Ils permettent en plus de ne pas avoir à câbler certaines parties, afin de pouvoir les rénover/ré‐agencer plus facilement dans le futur. Ces protocoles imposent parfois l’utilisation de piles, le principal défaut est donc la durée de vie de ces dernières, dans certains cas, elle chute à quelques mois, ce qui est évidemment très contraignant. La faible portée (espace libre : 300 m, habitat : environ 30 m) de ces équipements les réservent à des usages bien définis, mais dans le cas d’une maison individuelle, les limitations sont pour la plupart acceptables. Les protocoles présentés ci‐après utilisent les fréquences 868 MHz pour l’Europe et 315 MHz pour l’Amérique du Nord. ###EnOcean [_EnOcean_](http://fr.wikipedia.org/wiki/Enocean) est une technologie radio (868 MHz) normalisée IEC (ISO/IEC 14543-3-10) promue par l’[_EnOcean Alliance_](http://www.enocean.com/en/home/) et par la société [EnOcean](http://www.enocean.org/). Le but de ce protocole est de faire dialoguer divers appareils en utilisant la [récolte d’énergie](http://fr.wikipedia.org/wiki/Récolte_d'énergie) environnante. Les équipements _EnOcean_ sont donc sans fil et sans pile ! L’énergie récoltée dans l’environnement peut provenir de divers principes physiques : * effet [piézoélectrique inverse](http://fr.wikipedia.org/wiki/Effet_piézoélectrique_inverse "Définition Wikipédia") ; * effet [photoélectrique](http://fr.wikipedia.org/wiki/Effet_photoélectrique "Définition Wikipédia") ; * effet [Seebeck](http://fr.wikipedia.org/wiki/Effet_Seebeck "Définition Wikipédia"). Des recherches sont en cours, pour récupérer l’énergie provenant de vibrations, ou l’énergie du champ électromagnétique environnant. Il est bien sûr évident que l’optimisation énergétique qui a dû être menée est très poussée, afin de pouvoir soutenir des transmissions radio avec si peu d’énergie. Une super‐capacité est souvent ajoutée au sein de ces équipements, afin qu’ils puissent émettre même en cas de pénurie de leur énergie primaire ; et certains affichent plusieurs mois d’autonomie dans ces conditions. Le catalogue affiche, à ce jour, plus de mille références — normalement toutes inter‐opérables — afin de réaliser votre bonheur. La communication entre dispositifs se fait via un appairage manuel préalable ; ensuite, chaque dispositif peut adresser jusqu’à 20 autres dispositifs. Cette norme est libre en ce qui concerne l’implémentation, néanmoins, beaucoup d’acteurs intègrent l’_EnOcean Alliance_ afin de pouvoir bénéficier de licences des brevets concernant la récolte d’énergie détenus par l’Alliance. ###802.15.4 La norme [802.15.4](http://fr.wikipedia.org/wiki/802.15.4 "Définition Wikipédia") est une norme IEEE pour les réseaux sans fil de la famille des LR WPAN (_low rate wireless personal area network_). Sur le modèle OSI, ce protocole correspond aux couches physique et liaison, et permet de créer des réseaux sans fil de type maillé ou en étoile. Il est relativement aisé de trouver chez les revendeurs spécialisés des émetteurs‐récepteurs 802.15.4 incluant des micro‐processeurs et 128 kio de mémoire vive embarquée pour mettre en œuvre toute sorte d’applications au‐dessus de 802.15.4. ###6lowPAN [_6LoWPAN_](http://fr.wikipedia.org/wiki/6LoWPAN "Définition Wikipédia") est l’acronyme de _IPv6 Low power Wireless Personal Area Networks_. Ce projet de l’IETF vise à définir les mécanismes d’encapsulation et de compression d’en‐tête des protocoles IPv4 et surtout IPv6 pour la norme 802.15.4. Ce projet, bien que disposant déjà de produits commercialisés, n’est pas encore aussi mature que les autres solutions présentées plus haut. Il devrait arriver à maturité à moyen terme, et reçoit pour le moment un très bon accueil par les acteurs du milieu, ce qui devrait lui donner un avenir radieux. L’intégration de la pile 6LowPAN a été réalisée dans le noyau Linux depuis la version 3.3 et le travail continue sur ce sujet. ###ZigBee [_ZigBee_](http://fr.wikipedia.org/wiki/ZigBee "Définition Wikipédia") (dont le nom provient de l’analogie avec une abeille qui zigzague pour trouver son point d’arrivée) est un protocole libre régi par la [_ZigBee Alliance_](http://www.zigbee.org). Le protocole ZigBee fonctionne généralement au dessus de 802.15.4, il implémente les couches réseaux et applicatives du modèle OSI. Cette mise en œuvre permet de profiter des avantages de la norme 802.15.4 en termes de communication. Les principaux ajouts sont l’ajout des couches réseau et applicatives qui permettent, entre autres, de chacune réaliser du routage de messages ; l’ajout des ZDO (_ZigBee device object_) régis par la spécification ; et l’ajout des objets personnalisés par les constructeurs. Ce protocole souffre tout de même de certains problèmes, le plus important étant un problème d’interopérabilité. Comme vu précédemment, le protocole laisse aux constructeurs la possibilité de définir leurs propres objets applicatifs. Les constructeurs ne s’en sont bien sûr pas privés, ce qui cause des incompatibilités totales, certains constructeurs ayant ré‐implémenté leurs propres protocoles non documentés au‐dessus de ZigBee. Attention, donc, lors de l’achat de tels équipements (veuillez préférer un équipement prenant en charge un standard tel que [_Home Automation_](http://zigbee.org/Standards/ZigBeeHomeAutomation/Overview.aspx)). L’intégration de la pile ZigBee/802.15.4 est réalisée dans le noyau Linux depuis la version [2.6.31](https://linuxfr.org/news/nouvelle-version-2631-du-noyau-linux#802.15.4). ZigBee amorce sa mutation vers un réseau IP via la spécification [_Smart Energy Profile version 2.0_](http://www.zigbee.org/Standards/ZigBeeSmartEnergy/Version20Documents.aspx). Une fragmentation est peut‐être encore à prévoir à ce niveau. ##Courants porteurs Les protocoles utilisant les courants porteurs sont très prisés actuellement, car ils permettent de réduire le câblage et n’ont supposément pas recours aux radio‐fréquences. Ils présentent néanmoins des désavantages, ils sont très rapidement perturbés par l’environnement électrique (radiateurs, gradateurs...), ils ne franchissent pas, ou très mal, les transformateurs électriques, et le rayonnement électro‐magnétique des câbles dans lesquels ils passent en font de très bons émetteurs radio. ###X10 [X10](http://fr.wikipedia.org/wiki/X10_(informatique\)) est un protocole de communication ouvert pour la domotique, surtout utilisé sur le continent présent du côté ouest de l’océan Atlantique. Ce protocole est né en 1975 et utilise le principe du courant porteur. Ce protocole est peu recommandable, à l’heure actuelle, pour une nouvelle installation ; il offre des débits très faibles qui occasionnent des latences fortes (de l’ordre d’une seconde pour l’envoi d’un ordre). Beaucoup d’autres limitations sont présentes et détaillées sur le Web. ##Protocoles filaires Les protocoles sans fil sont souvent appuyés par un bus de terrain qui permet d’étendre les capacités globales de l’installation. On distingue parmi les protocoles filaires deux grandes familles, les centralisés, ceux qui utilisent un automate ou un serveur pour régir l’ensemble de l’installation ; et l’autre catégorie, les protocoles décentralisés où les capteurs et actionneurs dialoguent directement les uns avec les autres, sans point central. Chaque approche a ses avantages et inconvénients. ###ModBus [Modbus](http://fr.wikipedia.org/wiki/Modbus "Définition Wikipédia") est un ancien protocole placé dans le domaine public fonctionnant sur le mode de couche applicative maître‐esclave. Il fonctionne sur différents médias : RS-232, RS-485 ou Ethernet. Ce protocole impose une centralisation du fait de son utilisation d’un maître. Il supporte jusqu’à 240 esclaves. Son utilisation pour la domotique est maintenant anecdotique ou réservée aux projets économiques à la construction (i.e. Stade de France, ou locaux techniques Gaz de France). ###DALI [DALI](http://fr.wikipedia.org/wiki/Protocole_Dali) (_Digital Addressable Lighting Interface_) est un protocole standardisé IEC 60929 et IEC 62386 qui permet de gérer une installation d’éclairage par l’intermédiaire d’un bus de communication à deux fils. Il est le successeur du 0 - 10 V pour la variation de l’intensité lumineuse. Ses capacités sont limitées (64 luminaires répartis en 16 groupes au maximum par bus), mais on peut utiliser des gestionnaires pouvant interconnecter plusieurs bus (des automates, par exemple). Le DALI est souvent utilisé dans le tertiaire (bureau) ou, dans une moindre mesure, dans l’habitat résidentiel. ###DMX 512 Parmi les méthodes de contrôle d’éclairage, on retrouve plusieurs normes bien définies et utilisées depuis longtemps. C’est le cas du [DMX 512](http://fr.wikipedia.org/wiki/DMX_%28%C3%A9clairage%29), plus communément appelé DMX (_Digital Multiplexing_). Il est principalement utilisé dans le monde de la scène (concerts, plateaux télé, spectacles son & lumière), pour le contrôle de l’éclairage dynamique. Le DMX 512 est, à ce jour, le protocole le plus répandu et le plus universel, il est utilisé partout et par tous les fabricants de matériel d’éclairage scénique, ce qui permet de trouver des blocs de puissance gradateurs capables de varier plusieurs équipements, à des prix très abordables. Ces blocs peuvent aussi supporter des puissances supérieures à ce qu’on pourrait faire en DALI. Le DMX 512 utilise une liaison série RS-485 pour contrôler 512 canaux en leur affectant une valeur comprise entre 0 et 255. ###1-Wire [_1-Wire_](http://fr.wikipedia.org/wiki/1-wire) est un bus de communication, très proche dans le fonctionnement du bus [I2C](http://fr.wikipedia.org/wiki/I2C). Ce bus n’est actuellement plus beaucoup utilisé pour la domotique, bien que certaines installations subsistent. ###KNX [KNX](http://fr.wikipedia.org/wiki/KNX "Définition Wikipédia") est un standard ouvert (ISO/IEC 14543-3) né de la fusion de trois spécifications de protocoles : [EIB](http://fr.wikipedia.org/wiki/EIB "Définition Wikipédia"), EHS et Bâtibus. Il est surtout utilisé en Europe. KNX est décrit par une spécification écrite par les membres de l’[association KNX](http://www.knx.org/), qui se charge également de la promotion et du logiciel de configuration de référence (logiciel propriétaire ETS). Différentes couches physiques peuvent être mises en place pour KNX, la paire torsadée et Ethernet sont les plus répandues, mais d’autres peuvent également être rencontrées, bien que très marginales : infrarouge, courant porteur et transmission radio. Ces couches physiques sont en réalité très lentes (exceptée Ethernet) et pénalisent le protocole pour les réseaux conséquents. À l’utilisation, ce protocole se révèle décentralisé, les capteurs communiquent directement aux actionneurs qu’ils doivent régir, sans passer par un point central. La configuration d’un réseau se fait avec le logiciel propriétaire dédié ETS (conçu par l’association KNX), d’autres logiciels existent, mais ont une visibilté très faible comparativement au mastodonte ETS. Lors d’un changement dans le comportement du réseau, le fonctionnement du protocole impose un rechargement total du micro‐logiciel (_firmware_) du ou des équipements concernés (capteur ou actionneur). La mise en œuvre est relativement complexe et le protocole révèle des possibilités au final assez faibles et qui dépendent très fortement des micro‐logiciels des équipements. Là aussi, une installation n’ayant qu’une marque d’équipements est préférable, afin de profiter au maximum des possibilités de ceux‐çi. L’évolutivité d’une installation de ce type est très faible, à moins d’avoir conservé toute la configuration mise en place (micro‐logiciels compris, ce qui peut rapidement être lourd), et la logique de fonctionnement est assez complexe à appréhender pour un non‐habitué. ###LonWorks [LonWorks](http://en.wikipedia.org/wiki/LonWorks) est un réseau de bâtiment au niveau terrain historiquement créé par l’entreprise californienne Echelon, qui fournit maintenant le matériel de base (puces avec le protocole LonTalk embarqué). Ce réseau utilise comme protocole [LonTalk](http://en.wikipedia.org/wiki/LonTalk), standardisé ANSI/CEA-709.1-B, et de libre utilisation. Il est très utilisé comme bus de terrain pour commander des équipements CVC (chauffage, ventilation, climatisation), ainsi que pour la commande de l’éclairage. Géographiquement, il est principalement utilisé aux États‐Unis, en Angleterre, et dans plusieurs pays d’Asie ; ce qui en fait probablement le réseau de ce type avec le plus d’installations à travers le monde. De la même manière que KNX, LonWorks est un réseau du type décentralisé. Cela lui permet de communiquer à très longue distance avec une vitesse de 78 kb/s. La vitesse dépend de la couche physique utilisée, parmi lesquelles se trouvent : paire torsadée, courant porteur, fibre optique et ondes radio. LonWorks a plusieurs avantages, mais l’un des plus importants est l’interopérabilité. L’utilisation de SNVT (_Standard Network Variable Type_), variables de réseau standardisées, pour la communication entre nœuds, oblige les intégrateurs à réaliser des configurations propres. De plus, les fabricants sont fortement incités à créer leurs nouveaux produits en respectant l’utilisation des SNVT, ce qui assure une compatibilité maximale entre les marques. LonMark International est l’association dédiée à la promotion et à l’évolution des équipements compatibles avec LonWorks. Elle gère et maintient les normes liées au devéloppement entre les fabricants qui font partie de cette association ; elle gère également la publicité de la norme et des produits, les certifications, l’annulation/création de SNVT, etc. Il existe plusieurs logiciels pour mettre en œuvre un réseau LonWorks : NL220, LonMaker, entre autres. La flexibilité logicielle qu’offre LonWorks aux fabricants est telle, que n’importe qui peut devélopper un logiciel capable de mettre en marche un réseau de ce type, en se conformant aux documentations. Outre ces avantages, se trouve la possibilité de créer des _« LNS Plugins »_, logiciels qui permettent la configuration d’un produit ou d’un réseau au travers d’une interface graphique indépendament du logiciel utilisé pour créer le réseau. La configuration du réseau est sauvegardée dans la _« LNS Database »_, base de données de taille très modeste qui définit tout le réseau et qui est commune à tous les logiciels de configuration. Des projets sur LonWorks et Linux sont mis en œuvre, tels que [_lonworks4linux_](http://karl.hiramoto.org/lonworks4linux/), mais ils ne sont pas encore bien définis. ###Télé‐information client ou TIC La [télé‐information compteur](http://www.planete-domotique.com/blog/2010/03/30/la-teleinformation-edf/), spécialité française, est fournie par ERDF aux clients EDF, afin qu’ils puissent avoir accès à leurs informations de consommation. De cette manière, le client pourra avoir accès à l’adresse du compteur, l’option tarifaire choisie, l’intensité souscrite, la puissance apparente instantanée et beaucoup d’autres informations. L’ensemble des données et le moyen d’y accéder est disponible sur la [documentation mise à disposition par ERDF](http://www.erdfdistribution.fr/medias/DTR_Racc_Comptage/ERDF-NOI-CPT_02E.pdf). Afin de récupérer sa TIC, le client doit connecter sur son compteur bleu électrique (CBE) ou sur son Linky, un appareil dédié. Un schéma de carte électronique simple est disponible à [cette adresse](http://bernard.lefrancois.free.fr/del1.htm). De nombreuses variantes existent sur le Web pour votre bonheur, l’utilisation ce de protocole est libre. ###Fil pilote Le [fil pilote](http://www.planete-domotique.com/blog/2012/01/05/piloter-un-radiateur-grace-a-son-fil-pilote/), autre spécialité française, est un dispositif qui permet de commander les radiateurs électriques d’une installation via l’adjonction d’un fil supplémentaire où circulera du 230 volts. Ce fil permet de commander les radiateurs avec 4 modes : _Confort_, _Éco_, _Arrêt_ et _Hors gel_. La simplicité de mise en œuvre de ce système en a fait un standard de fait en France, et rares sont les logements à ne pas en être équipé, bien qu’il soit trop rarement utilisé. L’utilisation de ce protocole est libre ; malheureusement, son utilisation d’une ligne 230 V implique de l’électronique de puissance, ce qui n’est pas à la portée de tout le monde pour du [_DIY_](http://fr.wikipedia.org/wiki/DIY "Do It Yourself — faites‐le vous‐même"). ###xPL Le projet [_xPL_](http://fr.wikipedia.org/wiki/XPL_(protocole\)) vise à fournir un protocole unifié pour le contrôle et le supervision de tous les équipements de la maison. Ce protocole se veut simple dans sa structure, tout en mettant à disposition un panel de fonctionnalités important. Il dispose, par exemple, de fonctions d’auto‐découverte et d’auto‐configuration qui lui permettent d’être _« Plug and Play »_, contrairement à beaucoup d’autres protocoles de domotique. De part ses origines complètement libres, il est implémenté dans beaucoup de logiciels libres de domotique, mais il est très dur de trouver du matériel compatible pour équiper un habitat. → [Site du projet](http://xplproject.org.uk/) ###BACnet [BACnet](http://fr.wikipedia.org/wiki/BACnet "Définition Wikipédia") (_Building Automation and Control networks_) est un protocole de communication spécifié par l’[ASHRAE](http://fr.wikipedia.org/wiki/ASHRAE "Définition Wikipédia — American Society of Heating, Refrigerating and Air Conditioning Engineers") et est un standard ISO et ANSI. Il s’agit d’un protocole de couche réseau pouvant être utilisé au dessus de plusieurs technologies de couches liaison et physique, telles que LonTalk, UDP/IP... BACnet intègre également la couche application grâce à une ensemble d’objets dédiés. Ces objets représentent les informations gérées et échangées par les appareils. Son approche objet au plus proche des couches applicatives en fait un bon candidat comme protocole de haut niveau dans une installation GTB ou domotique. BACnet est souvent perçu comme le protocole qui permettra d’unifier tous les autres, grâce à ses fonctionnalités avancées. Il est donc actuellement très apprécié pour la supervision dans la GTB. ###Ethernet et consorts La norme [NF C 15-100](http://fr.wikipedia.org/wiki/NF_C_15-100) impose maintenant dans les logements neufs le VDI, (i.e. Voix Données Image), le VDI consiste en l’obligation de câblage en RJ-45 de la plupart des pièces de la maison, ceci permettant de créer un réseau de communication englobant téléphone, Internet, réseau informatique et multimédia. Le principe est d’utiliser les étonnantes possibilités de ce type de câble pour y faire transiter le maximum de données relatives à l’habitat ou à son utilisation. Cette omniprésence de câbles [UTP/STP](http://fr.wikipedia.org/wiki/Paire_torsadée) à la connectique RJ-45 peut, bien sûr, être mise à disposition de la domotique de l’habitat : * le multimédia, grâce à [DLNA](http://fr.wikipedia.org/wiki/DLNA)/[UPNP](http://fr.wikipedia.org/wiki/Universal_Plug_and_Play) ; * la télévision, en allouant une paire aux signaux hertziens ; * la téléphonie sur IP ; * la téléphonie « classique », via RJ-11 (connectique compatible avec RJ-45) ; * les signaux analogiques, en faisant passer le signal sur une paire dédiée : [lien](http://linuxfr.org/nodes/85940/comments/1231607) ; * l’énergie, via le [PoE/UPoE/PoE+](http://en.wikipedia.org/wiki/Power_over_Ethernet), qui permet de réduire la densité de câblage dans certaines configurations, 50 watts maximum actuellement sont transmissibles sur le lien, bientôt 100 watts, les cibles affichées sont les écrans et _notebooks_. Des adaptateurs PoE vers alimentation 18,5 ou 19 V + RJ-45 sont disponibles sur Internet (ne pas prendre la marque Phihong, néanmoins). Une gestion fine de l’énergie peut‐être mise en œuvre via des MIB SNMP, tels que [EMAN](http://datatracker.ietf.org/wg/eman/) ou EnergyWise (propriétaire Cisco) et quelques commutateurs PoE grand public peuvent être achetés dans le commerce. Les possibilités offertes par le câblage UTP/STP connectique RJ-45 sont donc très grandes, le meilleur évangélisme possible à ce sujet est la lecture de [ce journal](http://linuxfr.org/users/ploum/journaux/tant-quà-refaire-lélecttricité...) et de ses commentaires ; beaucoup d’informations et de conseils peuvent y être trouvés. #Logiciels La plupart des logiciels présentés ci‐dessous n’ont pas été testés pour l’écriture de cette dépêche, il ne s’agit que de présentations sommaires des fonctionnalités. Tout retour d’expérience en commentaire sera très apprécié. Cette liste est loin d’être exhaustive, des recherches sur Gitorious ou des plates‐formes équivalentes peuvent vous retourner des dizaines de résultats. Les logiciels présentés après sont ceux ayant une bonne visibilité sur le Web. ##openHAB [_openHAB_](http://code.google.com/p/openhab/) (_open Home Automation Bus_) est un logiciel de domotique écrit en Java avec OSGi et publié sous la licence GPL v3. _openHAB_ embarque un serveur Web pour son interface, il dispose également d’applications pour iOS et Android. Le logiciel peut être commandé d’une façon particulière : en lui envoyant des ordres via XMPP. Le développement est actif, la version 1.0.0 ayant été atteinte il y a quelques semaines, après deux ans de développement, de nombreux modules de communication avec d’autres protocoles devraient arriver dans les versions ultérieures. ##Fhem [Fhem](http://fhem.de/fhem.html) est un serveur de domotique écrit en Perl sous licence GPL v2. Ce logiciel d’origine allemande permet de gérer les protocoles FS20, OneWire, X10, HomeMatic, KNX et EnOcean. Sa documentation et ses forums majoritairement en allemand sont un point repoussant pour beaucoup d’utilisateurs. → [Code](http://fhem.svn.sourceforge.net/) ##Heyu [Heyu](http://heyu.tanj.com/heyu2/) est un programme de domotique utilisable en ligne de commande. Ce programme est écrit en _C_ et est sous licence GPL v3 (les anciennes versions disposent d’une [licence particulière](http://heyu.tanj.com/heyu_license.html)). Heyu est spécifiquement destiné au protocole X10, pour communiquer avec ce réseau, l’interface privilégiée est le CM11A de XA0 Inc. Ce projet n’est depuis peu plus très actif, son ouverture tardive et son utilisation exclusive de X10 ont sans doute provoqué son abandon. → [Code](http://developer.berlios.de/projects/heyu/) ##DomotiGa [DomotiGa](http://www.domotiga.nl/) est un logiciel de domotique pour GNU/Linux écrit en Gambas et sous licence GPL v3, ses origines sont néerlandaises. Ce logiciel est compatible avec les réseaux 1-Wire, KNX, X10, xPL, Z-wave et bien d’autres encore. Son développement est actif, et une feuille de route détaillée est disponible pour consulter les objectifs des prochaines versions. → [Code](http://www.domotiga.nl/projects/domotiga/repository) ##Misterhouse [MisterHouse](http://misterhouse.sourceforge.net/) est un logiciel multi‐plate‐forme écrit en Perl sous licence GPL. Ce logiciel est vieillissant et ne semble plus maintenu, il est revient tout de même régulièrement en avant lors des recherches sur la domotique libre. De part ses racines américaines, ce logiciel permet de gérer les réseaux X10, Z-wave, EIB, 1-wire. → [Code](http://misterhouse.svn.sourceforge.net/viewvc/misterhouse/trunk/) ##Domogik [Domogik](http://www.domogik.org/) est un logiciel écrit en Python sous licence GPL v3+. Ce logiciel dont la version 0.1.0 a déjà fait l’[actualité du site](https://linuxfr.org/news/domogik 010-pour-la-domotique-pratique), est né sur le [forum _ubuntu-fr.org_](http://forum.ubuntu-fr.org/viewtopic.php?id=200018&p=1) entre plusieurs personnes qui souhaitaient un logiciel de domotique. Il est en développement actif et permet pour le moment une gestion basique de l’habitat. Son architecture repose sur le protocole _xPL_ en interne. Il étend petit à petit ses fonctionnalités vers les protocoles les plus utilisés en domotique. Pour le moment, les protocoles suivants sont gérés : Plcbus, x10, 1wire, Ipx800, Teleinfo, RFID Mir:ror, Modem _« caller id »_, Wake on LAN / Ping. Le logiciel dispose d’une interface Web et d’une application Android. → [Code](http://hg.domogik.org/domogik/) ##Calaos [Calaos](http://www.calaos.fr) est une solution commerciale de domotique basée sur un automate _modbus_ et un serveur domotique GNU/Linux. Le code des applications est en majorité libre sous licence GPL v3. La solution est destinée en priorité à des maisons neuves avec une intégration forte au moment de l’étude de la construction. Une installation Calaos utilise des automates qui permettent le pilotage de tous les éléments électriques de la maison, ainsi que de faire l’acquisition des interrupteurs, sondes de température, capteurs de présence, etc. L’automate est capable d’interagir avec des bus de terrain tels que le DALI ou le KNX. Viens ensuite le serveur domotique, qui va piloter l’automate et ainsi gérer l’ensemble des règles de la maison (comme l’appui sur un interrupteur qui engendre le lancement d’un scénario). Il donne également accès à la maison sous différentes formes d’interfaces : Web, tactile (basée sur les EFL), applications mobiles, etc. Un système Calaos est aussi capable de gérer des caméras IP, ainsi que le multi‐pièce (_multi‐room_) audio (Squeezebox). → [Code](http://dev.calaos.fr) ##OpenRemote Le but de [OpenRemote](http://www.openremote.org/display/HOME/OpenRemote) est de créer une pile logicielle libre que les constructeurs pourront intégrer à très bas coût dans leurs produits, afin de créer des surfaces de contrôle pour le bâtiment. OpenRemote supporte un [grand nombre de protocoles](http://www.openremote.org/display/docs/Supported+Protocols+in+OpenRemote+2.0+Controller) parmi lesquels : X10, KNX, Z-wave, ZigBee, 6LoWpan, etc. L’idée étant de réutiliser les écrans déjà présents dans les lieux de vie tels que les _smartphones_, les tablettes et les ordinateurs de bureau. Sont donc actuellement supportés : Android, iOS, ainsi que GWT pour les applications Web. L’ensemble du code est sous licence [AGPL](http://fr.wikipedia.org/wiki/AGPL "Définition Wikipédia"). → [Interview de Marc Fleury à propos d’OpenRemote](http://www.dailymotion.com/video/xi86yh_marc-fleury-co-fondateur-d-open-remote_tech?start=112) → [Code](https://sourceforge.net/projects/openremote) ##LinuxMCE [LinuxMCE](http://linuxmce.com/) est une distribution GNU/Linux qui vise à fournir une solution complète et intégrée de gestion multimédia, de domotique, de téléphonie et de sécurité pour une maison. Elle repose sur beaucoup de logiciels libres, tels que VLC, Asterisk, Xine, etc. Tous ces logiciels sont mis en œuvre conjointement afin de créer une ensemble cohérent. Beaucoup de code additionnel permet de réaliser les diverses interfaces de configuration et de contrôle. Cette distribution en développement permet de gérer les protocoles de domotique suivants : KNX, 1-Wire, DMX, X10, EnOcean... Elle prend pour base d’anciennes versions (10.04, pour la version en développement) de Kubuntu. Elle représente probablement la solution libre la plus aboutie actuellement, ses développeurs la [comparent à des solutions propriétaires à plus de 100 000 $ USD](http://wiki.linuxmce.org/index.php/Frequently_Asked_Questions#What_do_commercial_appliance_solutions_similar_to_LinuxMCE_cost.3F). Malheureusement, elle impose l’utilisation d’une distribution dédiée, les plus débrouillards pourront la décortiquer pour en extraire les composants qui les intérèssent et recréer un serveur de domotique sur un de leur serveur domestique. → [Code](http://svn.linuxmce.org/svn/) → [Wiki LinuxMCE sur la domotique](http://wiki.linuxmce.org/index.php/Automation) Beaucoup d’autres solutions libres existent, on peut par exemple citer [openAMI](http://www.openami.de/index.html), [Minerva](http://www.minervahome.net/), [Freedomotic](http://www.freedomotic.com/), etc. Cette liste est loin d’être exhaustive — des recherches sur [_Gitorious_](http://gitorious.org/) ou des plates‐formes équivalentes peuvent vous retourner des dizaines de résultats —, les logiciels présentés ci‐dessus sont principalement ceux ayant une bonne visibilité sur le Web. # Conclusion Voici un aperçu des différentes technologies utilisées en domotique, à ces technologies, on peut ajouter celles qui auront peut‐être une grande présence dans le futur, telle [GreenNet](http://www.st.com/internet/com/press_release/t3264.jsp) qui a pour ambition de créer des réseaux de minuscules micro‐ordinateurs équipés de processeurs à 72 MHz et de liaisons à 2 Mb/s, basés sur la récolte d’énergie ; ou encore [CAN](http://fr.wikipedia.org/wiki/Controller_area_network), avec [CANopen](http://fr.wikipedia.org/wiki/CANopen) qui arrive depuis le monde des bus embarqués. On assiste globalement à une grande convergence des technologies de domotique vers l’Internet, à travers l’utilisation de plus en plus massive de technologies réseau telles qu’IP. Globalement, les grands silos de données qui ont été constitués au fil des ans par les différents constructeurs s’ouvrent progressivement au monde extérieur.

AltStyle によって変換されたページ (->オリジナル) /