Journal Gestion de l'énergie domestique : OpenHEMS

Sommaire

• Le marché HEMS
• Home-Assistant
  • Installation
  • Plugins et Extensions
  • Choix technique OpenHEMS
• Architecture technique OpenHEMS
  • La configuration
  • Stratégies
  • Nodes
• Pour aller plus loin

Bonjour,

Il y a 5 mois je vous parlais de mon projet OpenHEMS. Depuis, je l'ai pas mal avancé. J'ai notamment ajouté une fonction essentielle a sa popularisation: Une intégration en tant qu'Add-on (extension) Home-Assistant.

Pour rappel, il s'agit d'un logiciel pour piloter intelligemment la gestion de l'énergie (Home Energy Management System). En français, il s'agit de déclencher les appareils électriques au meilleur moment en fonction des heures creuses et, si l'on en a de la production photovoltaïque (ou éolienne). Il est écrit en Python, et communique avec les appareils via Home-Asistant.

Dans ce journal je revient rapidement sur quelques fondements mais je vais plus loin sur le marché et les choix techniques. Sur LinuxFR, je m'adresse à un public connaisseur qui appréciera d'avoir des information techniques. ;)

Le marché HEMS

Je commence à avoir une vision plus claire de la gestion de l'énergie chez le particulier.

Pour la majorité des français cela se limite a lancer manuellement les appareils aux heures creuses quand il en ont (car il y a une méfiance grandissante vis a vie de la rentabilité des heures creuses). Parfois il y a un minuteur associé à la prise ou quand la machine en dispose, l'utilisation d'un lancement différé. Tant que ces personnes n'ont pas de domotique à la maison, elles n'ont pas vraiment d'intérêt a en faire plus. Mais l'intérêt va croissant pour la domotique et alors automatiser fait sens.

Chez ceux, largement minoritaire, ayant des panneaux solaires, cette solution manuelle est contraignante. Il devient alors plus rentable d'automatiser. En effet, vendre l'électricité en journée pour la racheté le soir plus cher est une perte sèche par rapport à la solution de décaler sa consommation. Pour eux il existe des solution payantes très chère, mais la solution privilégié est généralement la bidouille car paradoxalement les installateurs de panneaux solaire ne proposent que très rarement des solutions dans ce sens.

Quand on veut automatiser, alors on se tourne vers une application (généralement open-source) de domotique. En open-source, il existe:

• Domoticz : L'ancêtre développé en C++. Son interface est un peu désuètes mais elle a le mérite d'être très performante. Merci C++. C'est donc un bon choix si l'on vise l'autonomie avec assez peu de panneaux solaires (pour la faible consommation qui y est allouée).

• Jeedom : Une version Java.

• Home-Assistant : C'est la solution la plus populaire et de loin et aussi de ce fait la plus avancée.

Il faut prendre en compte que le travail de ces application est assez énorme car il faut prendre en compte tout les protocoles, tous les appareils de toutes les marques. C'est un peu comme un mini-noyau d'OS. Évidemment, l'alternative la plus simple à ces applications c'est l'application du constructeur mais qui vous verrouille chez lui. Autrement il existe des applications fermées très chère.

Pour Home-Assistant, pour gérer les panneaux solaires, j'ai noté l'utilisation des solutions :

• EMHASS : C'est un excellent Add-on qui utilise l'IA pour l'optimisation. Mais le lancement automatique n'est pas intégré. On obtient la planification, à savoir le moment ou il faudra lancer les appareils sans que cela ne se fasse seul. Au vue de sa licence MIT je pense qu'il est largement utilisé dans des applications professionnels.

• Solar Optimizer. C'est un plugin qui utilise l'algorythme du recuit simulé pour optimiser le lancement des appareils. Les appareils sont réellement lancé seulement l'installation et la mise au point ne sont pas toujours trivial.

Home-Assistant

On va détailler un peu plus Home-Assistant, que l'on appel HA, compte tenu que c'est celui qui nous intéresse.

Installation

Suivant les méthodes d'installations on ne dispose pas toujours de toutes les fonctionnalités:

• Via l'OS dédié sur Raspberry PI (HAOS pour les intimes) : Il n'y a alors qu'à flasher l'OS sur une carte SD. C'est simple et complet.

• Via VM : C'est la solution pour installer l'OS et disposer de toutes les fonctionnalités. C'est la solution recommandé quand on a pas un Raspberry PI. C'est à la fois la plus consommatrice de ressources, et une solution pas si simple à mettre en œuvre.

• Via Docker. On ne dispose alors que du module cœur mais qui suffira pour la majorité des utilisations simples. Pour des utilisations un peu plus avancé, c'est possible mais un peu plus complexe qu'avec l'OS. L'avantage est que c'est la solution la plus légère des 3.

• En théorie on peut l'installer en faisant son OS from scratch mais ce n'est pas mis en évidence et je ne l'ai pas testé.

Plugins et Extensions

Il faut savoir qu'Home-Asistant est un écosystème complexe qui dispose de plusieurs manière de faire de l'automatisation. Les voici:

• Home-Assistant intègre un système d'automatisation simple par défaut. Il convient pour lancer une action sur un événement. C'est limité mais cela peut suffire.

• La solution la plus utilisée chez les bidouilleur c'est via la configuration YAML. L'avantage est que c'est assez simple à lire pour un initié et relativement portable. On peut se l'échanger, mais il y aura sûrement des adaptations à faire. Ces fichiers de configurations sont utilisables aussi simplement sous l'installation Docker que sous HAOS. Évidemment on est vite limité quand on veut faire des choses complexes avec.

• Pour aller plus loin en restant simple, il y a Node-Red. Node-Red est une application no-code destinée à faire de l'automatisation. Elle est intégré comme add-on c'est a dire comme Docker indépendant dans HAOS. On l'installe facilement depuis l'OS (VM ou pas) via le magasin de "modules" (Add-on). Mais, sans l'OS, il faut l'installer à part (en Docker ou pas) et aller y mettre un token d'authentification. Node-Red, est simple à utiliser pour un noob, mais pour un informaticien c'est tout de même limité. Disons que c'est bien pour assembler des briques. Node-red dispose de pléthore de plugin pour récupérer et piloter tous les systèmes (les APIs constructeurs… jusque Gmail)

• Pour aller encore plus loin, on peut faire des plugins en code Python en utilisant un framework dédié. L'avantage, c'est que cela permet d'étendre toutes les possibilité de HA. On peut faire un driver vers du matériel, un appareil virtuel, un composant IHM, ou… de l'automatisation. Pour installer ces "applications" dans HA, on dispose de magasins d'extensions. Il existe l'officiel certifié et les autres. Le plus officiel des non-officiel est HACS. Attention, il faut un compte Github pour installer HACS.

Choix technique OpenHEMS

Voilà, j'ai décrit toutes les possibilité de faire de l'automatisation. Pour autant même la dernière ne me convient pas car elle demande de maîtriser tout un framework complexe sans m'apporter la souplesse que je recherchais (mal expoliqué). Il y a autre chose qui me gênait aussi, dans une moindre mesure, c'est que cela aurait limité la solution à Home-Asistant.
Si au départ j'ai pensé faire un plugin HA, mon idée a finalement été d'utiliser l'API Home-Assistant pour faire une application indépendante comme Node-Red. Dans OpenHEMS, j'abstrait la partie réseau et ainsi, rien ne m'empêcherait de remplacer le "driver HA" par un "driver Domoticz" ou Jeedom (qui disposent de leurs propre API).
Je suis resté sous Python mais dans l'idéal, je la re-développerais bien en Go (ou Rust) pour gagner en performances.

Architecture technique OpenHEMS

La configuration

La configuration se fait au moyen d'un fichier YAML qui vient surcharger une configuration YAML par défaut. Cette configuration est entièrement éditable via une IHM web.

Outre la configuration OpenHEMS il faudra ajouter un widget sur Home-Assistant pour programmer les appareils. (Lance la machine a laver quand tu peux). Pour le wiget, j'ai choisi par simplicité, une iframe de OpenHEMS. HA permet d'ajouter des iframe (de site web), et c'est peut-être moins propre qu'un véritable plugin mais ça fonctionne. Le widget permet de demander une durée de mise en marche et un timeout (Un moment pour lequel on veut que l'appareil soit prêt)

Stratégies

La première chose a définir est la stratégie. Alors que certaines solution payantes repose sur l'IA pour détecter le réseau et choisir seul la meilleure stratégie de pilotage (souvent avec l'IA), sout OpenHEMS vous devez chosir une stratégie. La stratégie, défini quels sont les critères pour démarer et arrêter les appareils.

• offpeak : Il s'agit de démarer et arrêter les appareils au moment des heures-creuses. Seulement si l'on met une dead-line (timeout) sur un appareil et que le temps imparti en heures-creuses ne suffit pas il peut compléter en démarrant l'appareil en heures-pleines.

• Emhass : Emhass permet de gérer le cas avec des panneaux solaires. Il utilise, EMHASS depuis les sources.

• ratiosellbuy : Il s'agit d'un moyen, quand on dipose de panneaux solaires pour lancer les appareils dès que l'on est sur le point de vendre de l'électricité ou inverssement d'acheter de l'électricité. On peut avec la configuration agir de manière intermédiaire. Attention, ce n'est pas non plus une garanti dans la mesure ou il y a un temps de réaction. Par rapport à Emhass, je le conseillerai si l'on un contrat à heures fixes.

• annealing. C'est l'implémentation basé sur Solar Optimizer et donc l'algorithme du recuit simulé. Mais je l'ai fait beaucoup évoluer et aujourd'hui c'est l'algorythme génétique qui est utilisé… car je trouve qu'il donne un meilleur résultat.

• switchoff: C'est une stratégie de complément pour éteindre/allumer un appareil à heures fixes.

Nodes

Après avoir choisi la stratégie, on configure les appareils du réseau. Pour les paramètre on peut toujours mettre une valeur (numérique ou pas) ou un id Home-Assistant. Si c'est un id HA, OpenHEMS récupère la valeur sur HA sinon, il prends la valeur directement. Ceci permet une grande souplesse. Par exemple si l'on ne dispose pas de capteur remontant la consommation réel, on peut toujours mettre une valeur en dure. On perd bien sur des fonctionnalités (Coupe d'appareils en cas de risque de faire sauter les plombs), mais on peut quand même l'utiliser. Inverssement si la puissance maximale varie, on peut faire un capteur virtuel sur HA (Avec une configuration YAML) pour ajouter la fonctionnalité dans OpenHEMS sans avoir besoin de la développer.

• solarpanel : Les panneaux solaires

• Swith : Un appareil on/off.

• publicpowergrid : Le compteur Linky en France ou l'on spécifie le contrat avec ses heures creuses/pleines/prix d'achat/vente…

• battery : La batterie s'il y en a

Pour aller plus loin

Le code source est disponible ici avec une documentation en anglais.

Si la stratégie offpeak est bien testée chez moi, les autres stratégies le sont moins. J'espère une adoption plus générale pour avoir plus de retours. La fiabilisation de ses autres stratégies fait partie de mon todolist. J'aimerais aussi avoir des appareils à puissance variables mais comme je n'en ai pas à la maison, je suis un peu bloqué. J'aimerais d'ici cet été mettre en place des panneaux solaires à la maison avec un routeur solaire F1ATB.