OpenEnergyMonitor est un projet visant à développer des outils open-source de suivi énergétique pour nous aider à appréhender notre utilisation de l'énergie, nos systèmes énergétiques, et le défi de l'énergie soutenable.
OpenEnergyMonitor is a project to develop open-source energy monitoring tools to help us relate to our use of energy, our energy systems and the challenge of sustainable energy.
Les applications typiques sont le suivi des consommations énergétiques d'un bâtiment ou de la production d'un système solaire (panneaux photovoltaïques, ballon d'eau chaude sanitaire). Il n'y a pas encore, sinon marginalement, de pilotage automatique du bâtiment et des systèmes.
Les principaux mainteneurs, Glyn Hudson et Trystan Lea, y travaillent à temps plein depuis le labo OpenEnergyMonitor, dans les montagnes de Snowdonia, au Pays de Galle. Le projet inclut aussi les contributions significatives d'une quinzaine de participants. Les codes source du logiciel et les spécifications du matériel sont sous GPL.
Sommaire
Architecture
OpenEnergyMonitor est un projet modulaire, ce qui permet de n'en utiliser que des blocs, en les interfaçant avec les blocs d'autres projets. Le principe est d'avoir des éléments terminaux (nœuds) à coût réduit dispersés dans le bâtiment pour la mesure, qui communiquent en radio-fréquences (433 ou 868 MHz) avec une base dotée d'une connexion internet qui transmet les données recueillies à un serveur chargé de publier des courbes de suivi. Un module LCD connecté lui aussi en RF permet d'afficher certaines données localement.
Les éléments développés sont compatibles Arduino, c'est-à-dire que les cartes utilisent les même éléments de base qu'une carte Arduino, ce qui permet de les programmer avec les même outils de développement (bibliothèques de code, environnement de développement intégré). Les langages utilisés sont principalement le C++ pour les microcontrôleurs, php/javascript pour l'affichage côté serveur, et plus marginalement python si le Raspberry Pi est utilisé comme base.
Grandeurs et capteurs
Les grandeurs mesurées peuvent être des flux (électricité, gaz, eau) ou des paramètres hygrothermiques (température, humidité).
Température
La température de l'air est mesurée avec la sonde Dallas DS18B20. La communication se fait via un bus à un fil, grâce à une bibliothèque Arduino de Miles Burton.
Tension, courant, puissance
La cible du projet est plutôt la mesure de consommation électrique à l'échelle d'un bâtiment ou d'un départ de compteur que celle d'un équipement en particulier.
La mesure de tension se fait grâce à un adaptateur AC/AC qui ramène la tension du secteur à une amplitude acceptable pour le convertisseur analogique numérique (CAN) du microcontrôleur.
Le courant est mesuré via un transformateur de courant (current transformer, CT). C'est une bobine qui est disposée autour de l'une des phases du courant à mesurer et dans laquelle est généré un courant induit beaucoup plus faible et proportionnel au courant à mesurer.
Le courant généré passe dans une résistance de charge et la tension aux bornes de cette résistance, mesurée grâce à l'un des convertisseurs analogique / numérique (CAN) permet de déterminer la valeur du courant.
La puissance consommée peut être approximée en multipliant l'intensité mesurée par une valeur constante (230 V). La mesure simultanée de la tension permet une valeur plus précise, ainsi que le calcul des puissances réelle et apparente et du facteur de puissance (cos phi). Brancher un voltmètre quelques instants sur une prise de courant permet de réaliser combien la première méthode est approximative…
Les CAN utilisés ont une précision de 10 bits et, pour les exploiter au maximum, il convient d'adapter le CT et la résistance de charge au courant à mesurer. La mesure de la consommation d'un seul appareil doit donc être effectuée avec un CT destiné à des intensités plus faible, sans quoi la précision est médiocre. Le CT ne doit entourer qu'une seule phase. Il faut donc dégainer un fil pour le brancher sur un appareil.
Impulsions : gaz, eau, électricité
Certains compteurs délivrent une impulsion pour une quantité d'énergie donnée. Ce peut être sous la forme d'un contact sec, d'une diode, ou bien via un aimant disposé dans la roue de poids faible sur un compteur à affichage mécanique.
Les flashes de diode peuvent être mesurés avec des capteurs de lumière.
Pour instrumenter un compteur à affichage mécanique pourvu d'un aimant, il est possible de disposer près de la roue de poids faible un capteur de champ magnétique. Celui-ci peut être un capteur à effet Hall, qui renvoie une valeur (0 ou 1) en présence d'un champ magnétique, ou bien un simple interrupteur Reed. Ces capteurs sont reliés à une pin d'interruption du microcontrôleur. L'interrupteur Reed présente l'inconvénient de générer des rebonds (plusieurs fronts montants ou descendants lors d'un seul changement d'état) qu'il faut traiter matériellement ou logiciellement (une simple temporisation suffit).
emonTX
C'est le nœud qui embarque les capteurs. Il propose les connections suivantes :
- Trois ports permettant de brancher une sonde de courant CT (il est donc possible de suivre une installation en triphasé)
- Un port pour une sonde de température
- Un port avec compteur d'impulsions
- Une entrée AC permettant de brancher un adaptateur AC/AC optionnel afin d'avoir une référence pour les calculs de puissance
Le TX est alimenté sur secteur ou batterie. Les piles rechargeables Ni-Cd et Ni-Mh ont un voltage trop faible (2 x 1,2 = 2,4 V), il faut plutôt regarder du côté des Ni-Zn (forme bâton, plus chères) ou des accumulateurs au lithium (LiPo, rectangulaires plates, utilisées notamment dans les modèles réduits).
Le microcontrôleur embarqué est un Atmega 328 et la carte est compatible Arduino Uno. Les trois sondes de courant utilisent chacune un convertisseur analogique numérique (10 bits). La sonde de température utilise une entrée numérique et l'entrée impulsionnelle mobilise un port d'interruption. Il communique avec la base en RF grâce à un module RFM12B.
La version actuelle utilise des composants brochés. Une nouvelle mouture est en cours de finalisation avec notamment des composants montés en surface (CMS) et la possibilité de l'alimenter via l'adaptateur AC/AC, plutôt que d'avoir en plus un adaptateur pour l'alimentation.
emonTX existe aussi sous la forme d'un module complémentaire (shield) pour Arduino.
Le dépôt github du projet regorge de croquis (ou sketches, fichiers sources Arduino) avec des exemples de code pour différentes utilisation : mesure de courant, de température, etc. Du fait de la diversité des besoins et des adaptations, il n'y a pas à ce jour un code unique pour toutes les utilisations avec par exemple des #DEFINE pour activer chaque fonctionnalité. En revanche, ces codes s'appuient sur la bibliothèque EmonLib qui définit la classe EnergyMonitor.
emonBase
La base fait le lien entre un ou plusieurs emonTX disposés dans le bâtiment et un serveur distant.
Différents équipements peuvent remplir ce rôle :
Nanode RF, un élément du projet Nanode : un Arduino avec un module radio et un module éthernet.
Open Kontrol Gateway, du Open Kontrol system, qui propose un choix important de connectique sans fil: RFM12B, XBEE, XRF, RN-XV Wifi.
Un Raspberry Pi équipé de la carte RFM2Pi conçue par Martin Harizanov pour recevoir les données par RF.
Rapsberry Pi et RFM2Pi
La carte RFM2Pi est, elle aussi, compatible Arduino. Elle embarque un microcontrôleur Atmel Attiny et communique avec le Pi via un port série. La toute récente RFM2Pi v2 utilise des composants montés en surface (CMS) en remplacement des composants brochés et un Atmega 328 à la place de l'Attiny. Elle peut être programmée directement depuis le Pi.
Alors que les autres bases n'agissent qu'en répéteur, la particularité du Raspberry Pi est qu'il héberge lui-même un serveur emoncms localement, avec en option la possibilité de transférer les données à un serveur distant.
Il existe actuellement deux scripts passerelles (gateways) : le script historique en php, toujours maintenu, et un équivalent en python que je maintiens. Le script en php avait des limitations et l'idée de cette réécriture était d'avoir à disposition un code plus facile à faire évoluer. Sa conception est orientée objet, dans l'optique de produire un code générique adaptable, réutilisable par exemple pour envoyer à un serveur emoncms des données ne passant pas par la RFM2Pi (capteur relié directement au Pi).
Une image de carte SD avec un système pré-installé à base de Raspian Wheezy est disponible. Ceci comprend en particulier l'installation de l'application web emoncms.
Cette utilisation du Raspberry Pi implique beaucoup d'accès en écriture à la carte SD et des problèmes d'usure de la carte ont été signalés. Par nature, ceci est difficile à quantifier puisque c'est dépendant de l'usage, du nombre de capteurs et de la fréquence de mesure, de la qualité de la carte. Pour s'en prémunir, plusieurs pistes sont discutées : supprimer le maximum de logs, se doter d'un disque dur USB, n'utiliser le Pi qu'en répéteur et stocker les données sur un serveur distant, se délester de certaines opérations d'écriture en les exécutant sur une clé USB (une mémoire flash USB n'est pas moins fragile, mais une panne est moins gênante).
A ma connaissance, une solution à base d'OLinuXino n'a pas encore été testée, mais la carte RFM2Pi créée par Martin communique par port série donc ce devrait être possible.
emonGLCD
Le boîtier emonGLCD dispose d'un module RF et d'un écran LCD permettant l'affichage de données telles que température, production photovoltaïque, etc.
emoncms
emoncms est la partie web du projet. Son rôle est de stocker les données en base de donnée (mySQL), et d'afficher des indicateurs tels que des courbes de consommation, par exemple.
Une API permet d'envoyer les données au serveur emoncms sous forme de requêtes json grâce à une clé d'identification passée en paramètre.
Chaque nœud du réseau RF local (emonTX) a un identifiant unique (Node ID). A la réception des données, emoncms regroupe par Node ID les différentes données transmises : température, intensité, etc. Ces données (Input) sont brutes, et plusieurs opérations unaires et binaires de post-traitement sont possibles (mise à l'échelle, addition, multiplication,…) afin de générer des flux (Feeds) destinés à être visualisés.
emoncms propose plusieurs solutions de visualisation : courbe en temps réel, courbe zoomable, histogramme, indicateur de type vu-mètre, etc. Enfin, il est possible de créer des panneaux de contrôle (Dashboards) intégrant plusieurs visualisation avec titres et légendes. Les visualisations et les dashboards peuvent être rendues publiques et intégrées sous forme d'iframe dans des pages web. Ci-dessous, la visualisation "multigraph", puis quelques exemples de dashboards (cliquer pour afficher la version d'origine de l'image) :
Une équipe de Telecom Bretagne a créé un module qui affiche une carte sur laquelle il est possible de disposer des capteurs :
L'essentiel du code nécessaire à la création des graphiques est exécuté en javascript sur la machine cliente.
Un module en développement envoie des alertes par courriel selon les valeurs des flux.
Un module dédié au Raspberry Pi permet de modifier les paramètres de la carte RFM2Pi via un onglet de l'interface web emoncms.
Le site web Emoncms héberge une instance sur laquelle il est possible d'ouvrir un compte gratuit (sans garantie de stabilité et de disponibilité et sans sauvegarde des données).
Magasin en ligne
La plupart des éléments sont vendus via le magasin en ligne. Les cartes sont distribuées en kit à assembler/souder. L'assemblage est assez facile. Les prochaines versions en CMS seront vendues prêtes à l'emploi.
Évidemment, les ventes contribuent à financer le projet et l'activité des deux principaux développeurs.
Communauté
OpenEnergyMonitor regroupe une communauté importante d'utilisateurs/contributeurs. Les mainteneurs principaux sont très ouverts aux propositions et les patches sont en général facilement acceptés. Le forum est lui aussi très actif, avec des échanges documentés et constructifs.
Je réside actuellement à Bordeaux. Si vous êtes intéressé par le projet, on peut en parler au L@bx (hacklab bordelais) un mardi soir. Quelques autres participants au projet sont francophones.
Projets connexes
Enfin, voici quelques projets plus ou moins liés ou complémentaires :
Funky
Martin Harizanov développe aussi le Funky. Basé sur un Arduino Leonardo, celui-ci peut recevoir des capteurs et communiquer avec la carte RFM2Pi, à la manière d'un emonTX, en plus petit.
Flukso
Le projet Flukso, ouvert lui aussi, est assez similaire à OEM. Il utilise un boîtier principal connecté en Wi-Fi ou ethernet sur lequel il est possible de raccorder de une à trois CT, ainsi qu'une sonde avec interrupteur Reed pour mesurer un compteur de gaz ou d'eau. La logique n'est pas la même puisqu'il n'y a pas de lien radio : tous les capteurs sont donc nécessairement au même endroit, là où se trouve la base. Le site web de Flukso propose un hébergement des données et l'affichage est plutôt sympa et réactif.
Air Quality Egg
Le Air Quality Egg mesure température, humidité, taux de CO et de N02, et les transmet à un compte Cosm. C'est un projet libre (matériel et logiciel). Il n'est pas encore interfaçable avec emoncms mais c'est en projet.
On peut l'acheter via le magasin en ligne d'OEM. En France, il est distribué par la société IIDRE qui en assure le support.
La qualité de l'air fait l'objet d'une prise de conscience assez récente et le créneau est porteur. Des mesures de qualité de l'air vont devenir progressivement obligatoires en France dans les établissements recevant de jeunes publics. Les substances concernées par ces mesures sont les formaldéhydes, le benzène et le CO2, qui est un indicateur de confinement (défaut de ventilation) des locaux.
Plateformes d'hébergement de données
Dans ce message (en anglais) sur le forum Arduino, un comparatif de plateformes d'hébergement de données équivalentes à emoncms :
La plateforme fermée Cosm (anciennement Pachube) propose un hébergement gratuit de données et la possibilité de partager des panneaux de contrôle. Très utilisée, elle est considérée comme une référence.
ThingSpeak est une application en Ruby on Rails 3.0 distribuée sous GPLv3. Il est possible de créer un compte gratuit sur le serveur du projet qui en héberge une instance.
sen.se, plateforme fermée, avec possibilité de créer un compte gratuit sur le serveur du projet.
Aller plus loin
- Site web du projet OpenEnergyMonitor (3825 clics)
- Site web Emoncms (documentation et plateforme publique) (632 clics)
- Code source des éléments embarqués (emonTX, emonBase, emonGLCD) (476 clics)
- Code source de emoncms (322 clics)
# Merci!
Posté par Gael Beaudoin (site web personnel) . Évalué à 8.
Un super projet. Ca me donne envie de me lancer la dedans pour ma maison.
J'ai parcouru rapidement la documentation, ça n'a pas l'air simple, mais pas impossible non plus.
Est-ce que, par exemple, mesurer la consommation de courant générale de la maison, 2 ou trois prises électriques et deux sondes de températures rentre dans le faisable ? Me semble que oui, mais une confirmation de quelqu'un qui connait ça semble pas mal :)
Merci pour le journal :)
[^] # Re: Merci!
Posté par jihele . Évalué à 3.
Pas simple, mais pas impossible non plus.
Conso de courant générale, a priori, oui (vérifie que tu as accès au câbles électriques près du compteur). Prises électriques, c'est quand même moins fait pour. Il faut réussir à passer le CT, ça fait une belle pince, ça ne rentre pas dans le boîtier de la prise. Ou alors il faut dégainer un câble de rallonge ou de multiprise. Si c'est sur un départ de compteur spécifique (un fusible séparé), envisager de mesurer au compteur. Sondes de températures, oui, bien sûr, c'est le plus simple.
Si en plus il est possible de regrouper une sonde de température et une mesure de courant, ça évite de multiplier les boîtiers. Pour juste une température, le TX est un peu "overkill" mais il est aussi vendu en version "température seulement".
N'hésite pas à venir poser des questions sur le forum si ça te tente.
[^] # Re: Merci!
Posté par rpnpif . Évalué à 5.
Il y a plus simple pour mesurer la consommation de toute la maison, au moins en France.
Le projet utilise la lampe flash de comptage, c'est un peu rustique.
Cela dépend quand même du modèle de compteur, mais il est plus simple d'utiliser la sortie de téléinformation client qui est libre d'accès. Si elle n'est pas active, on peut demander à ERDF ou au service équivalent de le faire. C'est gratuit sauf si on fait déplacer exprès le technicien.
Un exemple de documentation ici. De nombreuses valeurs sont alors accessibles.
[^] # Re: Merci!
Posté par jihele . Évalué à 2.
En fait le projet utilise plutôt la pince ampère-métrique, la lampe flash étant l'exception, je crois. D'ailleurs, j'ai un compteur à disque encore plus rustique qui n'a même pas de diode…
Merci pour l'info. Le document que tu cites spécifie le protocole de transmission. Je trouve moi aussi plus propre d'accéder directement aux valeurs du compteur si c'est possible.
[^] # Re: Merci!
Posté par Baptiste Gaultier (site web personnel) . Évalué à 4.
Salut,
Si cela vous intéresse, je contribue à emoncms et emonplug pour le monitoring de mon campus et ma maison… Je me permets d'ajouter un peu de doc en français :
- http://openenergymonitor.org/emon/node/1474 (installation)
- http://openenergymonitor.org/emon/node/1850 (utilisation)
- http://departements.telecom-bretagne.eu/rsm/logiciels/smartb/ (présentation du cas d'un campus)
- http://departements.telecom-bretagne.eu/rsm/logiciels/smartb/particuliers/ (utilisation avec un compteur EDF à LED)
Si questions, je suis à votre disposition :)
Merci pour le coup de projecteur, c'est cool !
Baptiste
[^] # Re: Merci!
Posté par jihele . Évalué à 2.
Salut.
J'avais cherché ton nom sur DLFP avant de poster. Bienvenu à toi. Je sais pas si tu as fait attention, mais je mentionne vos contributions dans la dépêche, dans les exemples de dashboards. Merci pour les liens !
emonplug c'est un emonTX avec moins d'entrées (une seule entrée CT et pas d'entrée température) ?
Pour les compteurs à LED, s'ils ont une sortie où on peut brancher un fil ça doit valoir le coup d'implémeter leur protocole de communication plutôt que de s'embêter avec la détection de LED.
Je savais même pas qu'il y avait de la doc en français. Je l'aurais proposée dans les liens de dépêche. Je suis incapable de la retrouver sans tes liens directs. Quel est le chemin logique ?
[^] # Re: Merci!
Posté par Baptiste Gaultier (site web personnel) . Évalué à 2.
Avec plaisir !
Au début, c'était ça. La prochaine version se rapproche plus d'une prise de suivi de conso sans-fils qui pourra être coupée à distance depuis emoncms (grâce notamment au module event : lien)
En France, très peu de foyers sont équipés de sortie téléinfo, de plus il existe un shield pour Arduino qui parle déjà ce protocole : lien.
http://openenergymonitor.org/ » Home » Modules » emoncms. Nous travaillons sur une documentation plus détaillé et directement embarquée sur l'instance d'emoncms.
L'occasion d'indiquer également qu'un gros travail de traduction de emoncms a été fait la semaine dernière avec Mickaël VIALAT de planete-domotique.com.
Baptiste
[^] # Re: Merci!
Posté par steph1978 . Évalué à 2.
La pince ampère-métrique a l'avantage d'être utilisable partout mais je pense que la diode d'impulsion permet une mesure plus précise.
[^] # Re: Merci!
Posté par zebul0n (site web personnel) . Évalué à 1.
C'est rustique, mais ça évite de shunter. C'est mieux quand même vis à vis de l'assurance habitation en cas de pépin.
[^] # Re: Merci!
Posté par titinux . Évalué à 4.
Étant en train de construire ma maison il va sans dire que ce genre de projet m'intéresse tout particulièrement.
J'aurais néanmoins quelques questions.
[^] # Re: Merci!
Posté par jihele . Évalué à 2.
Je ne suis pas fan non plus. Quand on peut passer un fil, je préfère. Ce n'est pas l'optique choisie par le projet. Sans doute pour pouvoir s'adapter à l'existant. Selon la grandeur que tu cherches à mesurer, tu peux reproduire un peu la même chose avec un arduino et un shield ethernet.
Je crois que la prochaine version du TX prévoit un emplacement vide pour un connecteur Xbee optionnel (radio toujours) mais rien pour de l'ethernet.
Dans une maison neuve, tu peux passer du RJ45 partout donc c'est intéressant pour toi de regarder vers là, en effet. En bon geek, j'en mettrais un peu plus que le minimum (par exemple des prises à deux ports dans chaque pièce) histoire d'être tranquille.
Ce genre de chose est possible, oui. Dans la config de base, non, c'est un seul port pour ça par emonTX. Ca vaudrait le coup de prendre un arduino + shield ethernet et faire un truc à plusieurs ports (temp, lum, humidité). C'est pas forcément la mort en s'inspirant des docs du site, vraiment. Jette un coup d'oeil à la page Building Blocks qui détaille les morceaux. Et n'hésite pas à intervenir sur le forum si tu es intéressé, tu ne serais pas le seul.
Comme la construction doit déjà pas mal te mobiliser, je doute que tu aies des masses de temps pour développer ça, mais pense aux ports éthernet partout, tu auras toujours le temps de voir. Côté EDF, je ne sais pas s'il y a le choix pour le compteur et si ça vaut le coup de se renseigner avant pour en choisir un avec une sortie plus pratique à récupérer.
Oui, ce n'est pas grand chose à modifier. Comme je le dis en dépêche c'est assez modulaire.
Tu penses à une implémentation perso de zéro ? Je n'ai pas essayé les alternatives citées dans la dépêche, mais regarde du côté de ThingSpeak, par exemple, et dis-nous ce que ça donne.
# Licences
Posté par jihele . Évalué à 6.
Je ne me souviens plus si j'ai écrit ceci ou bien si ça fait partie de l'édition à la modération. En tout cas si ce n'est pas moi, je suis fautif car j'aurais du spécifier la licence.
Les licences sont précisées sur cette page. Le logiciel est sous GPL v3 et le matériel sous Creative Commons Attribution-ShareAlike 3.0.
Je ne crois pas que le choix des licences ait fait l'objet d'une réflexion poussée. La volonté était de faire du libre, point. Par exemple, la GPL v3 a du être choisie (plutôt que la v2) parce que c'est la dernière version.
[^] # Re: Licences
Posté par ʭ ☯ . Évalué à 4.
Est-ce que c'est autonome, ou les graphiques en javascript sont faits à partir d'API Google?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Licences
Posté par jihele . Évalué à 4.
C'est autonome.
J'ai vu récemment arriver quelques contributions d'utilisateurs qui amélioraient beaucoup l'efficacité du code (notamment en optimisant les requêtes en BDD), ce qui me laisse penser qu'il y a une marge d'amélioration ici pour quelqu'un qui aurait des compétences.
[^] # Re: Licences
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
J'ai ajouté cette ligne en modération, en me basant sur
http://openenergymonitor.org/emon/opensustech qui dit « Following the principles of the Free Software Movement the software source code and hardware designs for this project are available at no cost to everyone under the GNU General Public License. »
[^] # Re: Licences
Posté par jihele . Évalué à 2.
Je comprends. C'est clairement pas le priorité des développeurs que de réfléchir à ça (cf. les commentaires en bas de cette page). Je signale ça à Trystan. Merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.