Blog

Tags : Jeedom, Solar Assistant, production solaire, Zigbee, MQTT, zigbee2mqtt

Estimated reading time: 35 minutes

0. Contexte et intentions

Le constat n’aura échappé à personne : l’électricité c’est cher. Une flambée de 60% en 5 ans ça pique. En attendant que LVMH lance sa gamme de forfaits énergie, ceux qui perçoivent l’orage approcher tentent de prendre les devants.

Deux écoles se dégagent de ce raisonnement. Les capitalistes optent pour le kit solaire Plug&Play, rentable et simple, avec revente du surplus. Les bricolo-comploto-survivalistes, eux, choisissent l’onduleur central et un gros rack de batteries. Ils se préparent ainsi à la fin du monde. Je caricature, évidemment 🙂

1. Présentation des équipements

Le but de cette présentation est de montrer comment contrôler un équipement solaire avec de la domotique sans injection réseau, avec des batteries physiques et sans contrat de revente.

Selon la configuration de l’onduleur, deux options existent pour gérer la production non consommée ou non stockée. Soit le surplus part dans le réseau, soit le régulateur de puissance solaire (MPPT) limite la production des panneaux à la seule consommation de la maison.

Dans les deux cas, une partie du potentiel énergétique des panneaux est perdue. Autant l’utiliser. La priorité est d’abord de remplir des batteries pour passer la nuit hors réseau l’été, en plus de la journée. Ensuite, l’énergie excédentaire peut être dirigée automatiquement vers des appareils utiles : eau chaude, chauffage, climatisation, déshumidification, véhicule électrique ou piscine, selon les besoins.

Je n’ai fait appel à aucun pro pour ce projet. Cela demande quelques neurones et beaucoup de temps, mais aujourd’hui, je maîtrise suffisamment chaque système pour me dépanner dans la plupart des cas.

Un petit schéma pour résumer tout ça :

Une pince ampèremétrique, reliée à l’onduleur, mesure en continu le courant à l’arrivée du compteur. Cela permet d’empêcher l’onduleur d’injecter du courant dans le réseau. Le compteur « perso » connecté permet de couper l’arrivée réseau lorsqu’on en a pas besoin.

1.1 Côté solaire

• Onduleur hybride DeYe 5kW (config : zéro export to CT, Priority load)
• Batteries Pylontech US3000 et US2000 : 10kWh évolutif
• String 6 x panneaux DMEGC 500W bifaces
• 3 paires de panneaux Trinasolar 430W sur micro-onduleurs DeYe SUN80 (3 orientations)
• Coffrets électriques de sécurité, coupes circuits…

1.2 Côté domotique

On y retrouve principalement des appareils Zigbee et des équipements connectés wifi

1.3 Côté informatique

1.3.1 Configuration

• Raspberry Pi 4 hébergeant Jeedom 4.4, Debian 11, SSD256, principaux plugins:
  • Zigbeelinker
  • Mqtt Manager
  • Jeedom Connect
  • Virtuel
  • TeleInfo, lit les données du compteur EDF électronique avec le boiter teleinfo
  • Rte Ecowatt Tempo, API Rte pour la couleur des jours
  • meteoMC et PWS (lit les données de la station Froggit en local) pour la météo
  • SolCast : prévisions de production basé sur API
  • … & d’autres +/- utiles.
• Raspberry Pi 3 PiOS Debian 11, SSD256, clé SonOff Dongle+ EFR32 flashée Ember, avec Docker et containers pour :
  • Broker mosquitto (serveur du protocole mqtt)
  • Zigbee2mqtt (Gère la clé SonOff et convertit le protocole Zigbee en protocole mqtt, comme son nom l’indique)
  • Portainer (gestion en interface graphique des containers docker)
  • Autoheal (programme de gestion santé des containers)
  • Script qui ping Jeedom toutes les 3min, et reboot par switch zigbee off/on en cas de 3 non réponses successives. (brutal mais efficace)
  • Script qui copie tous les matins à 6h le backup de Jeedom dans le SSD du Pi Docker
  • Et faire des tests avec Docker
• Raspberry Pi 3 SD32 : Solar Assistant (programme de liaison à l’onduleur central) et son broker mqtt
• Raspberry Pi 5 SSD 1To : Home assistant (en test et pour lier certains appareils non soutenu par un plugin Jeedom, en mqtt)
• Un hub LAN Netgear pour connecter tous les Raspberry ensemble
• Un routeur LAN/WAN.Wifi perso pour ne pas être tributaire de la livebox et devoir tout reconfigurer à chaque changement de box (baux DHCP statiques, règles de routage NAT etc) : DMZ vers le routeur dans un sous réseau et c’est réglé. Si la livebox plante le routage continue même sans internet, et le wifi de la livebox est éteint.

1.3.2 le protocole MQTT, Mosquitto et MqttExplorer

MQTT est un protocole largement utilisé en domotique pour sa simplicité, sa faible consommation de ressources et d’énergie. Il agit comme un langage universel entre les appareils du réseau domotique, se propageant via Ethernet et Wi-Fi.

Ce protocole permet de communiquer avec divers objets et de créer des ponts entre Jeedom et Home Assistant, ou encore entre des Raspberry Pi et des modules ESP32. Il sert aussi bien à récupérer des informations, comme l’état d’un appareil (allumé = 1, éteint = 0), des valeurs numériques ou du texte affiché sur une matrice, qu’à envoyer des commandes aux équipements.

1.3.2.1 MQTT comment ça marche

MQTT fonctionne selon un modèle serveur/clients. Les clients se connectent à un broker (serveur ou « courtier »), qui sert d’intermédiaire pour l’échange de sujets (messages ou payloads).

Les sujets sont organisés en topics, une arborescence qui, en domotique, correspond aux appareils et à leurs fonctionnalités. Par exemple :

solar_assistant/inverter_1/load_power/state :

• solar_assistant est le topic principal qui correspond à l’appareil « Solar Assistant »
• inverter1 est la partie des données « onduleur » pour séparer avec par exemple les batteries
• load_power est la consommation de la maison, parmi toutes les autres données de l’onduleur
• et state son état

Dans ce topic on trouve la valeur de la consommation de la maison sous forme de sujet : state = 531 qui correspond à 531 Watts, remis à jour à chaque nouvelle valeur fournie par l’onduleur, environ chaque seconde.

1.3.2.2 Mosquitto & Mqtt Explorer

Le broker est mosquitto, il en existe d’autres comme emqx ou hivemq : très simple à installer en tant que service permanent, il se configure en éditant son fichier mosquitto.conf pour définir le mot de passe ou connecter un broker à un autre broker

Pour voir ce qu’il se passe sur le broker mosquitto on peut installer MqttExplorer sur une machine windows, et se connecter au broker en pointant son IP, le port par défaut est 1883 :

MqttExplorer permet aussi de publier des messages directement sur le broker pour vérifier une commande ou envoyer un ordre à un appareil : sur une commande d’état d’appareil s’il est à 0 (off) on envoi 1 (on) au sujet et l’appareil s’active : pour éclairer une ampoule par exemple.

En savoir plus sur le mqtt : https://youdom.net/le-mqtt-cest-quoi-comment-ca-marche-le-principe-de-jmqtt-avec-jeedom/

1.3.3 Zigbee2mqtt et ZigbeeLinker

Pour piloter des équipements il faut un réseau d’appareils connectés qui communiquent avec Jeedom.

Et donc comme la transition est bien faite, on va retrouver du mqtt dans cette partie. Car les appareils Zigbee c’est bien sur le papier, mais dans les faits IRL c’est un peu plus complexe : un peu comme Android AOSP et les surcouches fermées des fabricants d’Android phones, Zigbee est un protocole open source. Mais chaque fabricant utilise sa box « passerelle » pour communiquer avec les appareils de sa gamme et tout envoyer sur leurs serveurs pour que ce soit plus facile à gérer. Et pour ne pas multiplier les passerelles et les applis du téléphone on se retrouve vite enfermé chez un même constructeur, comme deparazar, alors qu’ils utilisent tous le même protocole mais pas inter-compatible et ça c’est ballot.

1.3.3.1 Z2M

Heureusement la planète abrite des petits malins qui ont eux aussi trouvé ça ballot et décidé de rendre tout inter-compatible avec une clé USB munie d’une antenne pour capter le signal Zigbee des appareils du réseau domestique ; et pour ne pas avoir à pinguer les serveurs de tous les fabricants du monde, gérer ça sur un serveur local : le fameux programme Zigbee2Mqtt (Z2M)

A cet instant vous aurez facilement compris : Z2M récupère le signal RF* des appareils du réseau Zigbee avec la clé USB et le convertit en protocole mqtt pour Mosquitto en réseau local. Et possède, indépendamment des multiples liaisons interconnectées qui peuvent être faites avec Jeedom ou Home Assistant, son propre frontend accessible via navigateur qui permet de contrôler tous les appareils.

*RF : radio fréquence, le réseau zigbee transite en ondes radio 2.4GHz comme le wifi, c’est pas le même signal mais il peut interférer.

La suite se passe sur : https://www.zigbee2mqtt.io/ pour voir la liste toujours plus grande des appareils compatibles (+4000 à ce jour !)

1.3.3.2 ZigbeeLinker

Dans Jeedom il existe plusieurs plugins pour faire la jonction avec Z2M, en particulier JeeZigbee et ZigbeeLinker. Les 2 sont payants à 6.00€, et je ne parlerai que brièvement de ZigbeeLinker que je connais.

Après avoir téléchargé le plugin, il existe plusieurs façon d’installer les dépendances en fonction de ce que vous avez déjà : si Z2M ou Mosquitto est déjà présent sur le réseau, ça risque de mettre le bazar de réinstaller par dessus. On a 3 options principales :

• Complète : installe Z2M, le broker mosquitto et le client mqtt pour Jeedom.
• Custom : on choisit les dépendances à installer.
• Mini : client simple.

Quand j’ai commencé, n’y comprenant pas grand-chose dans tous ces trucs à apprendre d’un seul coup, j’ai fait une installation complète. Et ça a marché. Après j’ai flairé que d’avoir facilement la main sur chaque élément séparé permettait de s’en sortir sans avoir à réinstaller tout Jeedom parce que « ça marche plus » … Depuis que j’ai tout compris 🙂 , ZigbeeLinker est installé en simple client du serveur mqtt et le fait très bien, même si apparemment le passage à la V2.0 de Z2M ne s’est pas très bien passé pour tout le monde – bon, pour lui ça a été et moi aussi, parce qu’on lit les changelogs, on fait des backups et on attend un peu si ça sent pas bon dans le « issues » du GitHub, surtout pour les maj majeures.

Et donc au fur et à mesure de mes essais j’ai commencé à me rendre compte déjà que le Pi3 commençait à patiner avec tout ce petit monde à sa charge et qu’il fallait le libérer un peu : J’ai installé Jeedom standalone sur un Pi4 et Z2M et Mosquitto sur le Pi3 en Docker, car Docker c’est quand même turbo pratique.

1.3.4 Docker or not docker ?

Si vous n’avez pas la moindre idée de ce qu’est Docker, en gros c’est un programme qui permet de compartimenter d’autres programmes comme si chaque compartiment était une « machine » à part entière avec ses fichiers systèmes, les programmes désirés et leurs propres volumes, ports de communications etc. Je n’ai pas été chercher la définition exacte et je vous la donne telle que je l’ai compris 🙂 Mais ce qu’il y a de bien, c’est que chaque compartiment possède sa propre image qu’on peut remplacer à volonté : une mise à jour se passe mal, pas grave on remet l’ancienne image dans le container (nom du compartiment). Sans compter un programme comme autoheal lui-même dans un container qui s’occupe de vérifier la santé des autres containers et les relance automatiquement, pratique quand on a des services H24 comme Mosquitto ou Z2M.

Une bien meilleure définition que moi de docker avec des tutos : https://youdom.net/docker-container-domotique/

1.3.4.1 Portainer

Ensuite, Docker c’est soit de la ligne de commande pour barbus, soit on utilise Portainer, l’interface graphique pour docker et là tout est plus simple avec les Stacks pour installer nos programmes préférés, même en ayant une barbe. (voir le lien au dessus pour installer Portainer)

Perso, j’ai compartimenté chaque programme, mais on peut tout aussi bien faire une liste de tous les services voulus dans un seul container. Je ne sais pas si c’est mieux ou moins bien mais ça marche très bien comme ça.

1.3.4.2 L’éditeur « Stack » Portainer

Pour installer Mosquitto avec volumes permanents, paf, Docker-compose (Stack) avec check par autoheal toutes les 1min

version: "3.8"
services:
  mosquitto:
    image: eclipse-mosquitto:latest
    container_name: mosquitto
    restart: unless-stopped
    volumes:
      - config:/mosquitto/config
      - data:/mosquitto/data
      - log:/mosquitto/log
    ports:
      - 1883:1883
      - 9001:9001
    networks:
      - mosquitto
    environment:
      - TZ=Europe/Paris
    healthcheck:
      test: ["CMD-SHELL", "timeout 5 mosquitto_sub -h localhost -u mqtt -P mosquitto -t '$$SYS/#' -C 1 || exit 1"]
      interval: 1m
      timeout: 30s
      retries: 6
networks:
  mosquitto:
      name: mosquitto
      driver: bridge      
volumes:
  config:
  data:
  log:

Pour Z2M, repaf, volumes permanents, et Autoheal check le fontend pour voir si il répond, sinon il relance

version: "3.8"
services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt:latest
    container_name: zigbee2mqtt
    restart: unless-stopped
    privileged: true
    volumes:
      - /mnt/zigbee-data:/app/data
      - /run/udev:/run/udev:ro
    ports:
      - 8080:8080
    environment:
      - TZ=Europe/Paris
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    labels:
      - "com.centurylinklabs.watchtower.monitor-only=true"
    networks:
      - zigbee2mqtt
    healthcheck:
      test: "wget --no-verbose --tries=1 --header 'Host: votre.domaine.com' --spider http://192.168.0.151:8080 || exit 1"
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
networks:
  zigbee2mqtt:
    name: zigbee2mqtt
    driver: bridge
volumes:
  zigbee_data:

Tant qu’on y est je donne le Stack pour Autoheal (qui se check lui même)

version: "3.8"
services:
  autoheal:
    restart: always
    image: willfarrell/autoheal:latest
    container_name: autoheal
    environment:
      - AUTOHEAL_CONTAINER_LABEL=all
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Faire « Update the stack » en dessous de l’éditeur (on voit par exemple qu’ici tout va bien pour Z2M d’un coup d’œil, il est healthy en vert grâce à Autoheal)

Puis Re-pull image and redeploy – Update

Il y aussi moyen de faire les mises à jour en auto des containers avec watchtower, perso je préfère juste surveiller et les faire à la main, comme pour Jeedom.

1.3.4.3 Paramétrage de ZigbeeLinker

Ensuite on renseigne à la config de Z2M et au Client de ZigbeeLinker où se trouve Mosquitto : adresse IP de la machine docker : 1883 par défaut, ainsi que le topic de base dans Mosquitto : ici zigbee2mqtt qui regroupe tous les appareils zigbee de Z2M

Adresse du broker mqtt, port et topic racine dans un client de ZigbeeLinker

2. Solar Assistant

Avant de commencer la présentation, il est à préciser qu’il existe un plugin gratuit pour Jeedom qui permet de faire la même chose pour les onduleurs qui utilisent l’application de gestion « Solarman » : le plugin solarman

2.1 Présentation

Solar Assistant est un petit logiciel qui n’a rien à voir avec Jeedom. Redoutable d’efficacité pour lire les données de l’onduleur et des batteries en direct, il est aussi capable d’envoyer des commandes à l’onduleur. Il permet de lire ces données dans un navigateur avec des graphiques Grafana intégrés, et d’activer son propre broker mqtt. Il dispose d’un accès local mais aussi d’un accès depuis un serveur dédié de l’éditeur du logiciel.

2.1.1 Interface et utilisation

Interface limpide et très ergonomique, toutes les fonctions de l’onduleur sont directement paramétrables dans le menu de configuration. Les mises à jour sont régulières et accueillent à chaque fois de nouveaux onduleurs et quelques fonctionnalités supplémentaires.

Son principal avantage réside dans le fait que les données sont actualisées toutes les secondes, contrairement à Solarman qui offre une actualisation toutes les minutes, au mieux. Et cela a son importance lorsqu’on veut programmer des délestages lors d’un jour d’alternances soleil / nuages, quand on passe subitement de 4kW de production à 300w en quelques secondes et cela des dizaines de fois dans la journée : A ce moment là, par exemple des radiateurs sont allumés et il faut les éteindre pour ne pas vidanger les batteries, mais pas trop vite non plus car le soleil peut revenir quelques secondes plus tard : il faut faire des moyennes, et pour cela il faut un maximum de données.

2.1.2 Se le procurer, et quelques détails

Le logiciel seul coûte une soixantaine d’euros sur le site et immédiatement disponible après paiement, les câbles spécifiques à chaque onduleur ou batterie aussi, mais facilement trouvables ailleurs. Il est possible de commander directement le tout préinstallé sur une machine Orange Pi.

Son seul défaut, l’interface bien que très complète n’est pas du tout « customisable », pas de dark mode par exemple ou de fichier de traduction pour le moment, et il ne s’installe que dans un Orange / Raspberry Pi en standalone. Un Pi3 suffit en mode console (accès distant), il est déjà très stable (reboot programmé 1 fois par mois pour l’hygiène). Un Pi4 ou 5 est fortement recommandé si on veut lui coller écran/clavier/souris avec GUI, ce qui ne sert strictement à rien mais bon, c’est possible…

Petit tips : pour les fans de dark mode, on peut tout de même consulter les graphiques sur une page html :

Allez, une autre petite image du menu Batteries (rack de 4)

Pas grand chose à rajouter à la liste des appareils compatibles et au fichier d’aide déjà bien fourni sur https://solar-assistant.io/ (faire clic droit « traduire » sur le site pour qui l’anglais pique les yeux)

Mais aussi Huawei, Voltronic, Solis… voir le changelog sur le site de Solar Assistant car à chaque version sa nouvelle liste, et la liste des appareils non supportés

2.2 Connecter Solar Assistant au broker principal

Assez simple coté Solar assistant : Configuration > MQTT Broker > « Configure ». Juste lui donner un petit nom et « reset energy totals » à mettre en « Daily » pour retourner la production journalière en mqtt. Appuyez sur « Start » et le broker est lancé.

2.2.1 Deux brokers ?

3. Jeedom et MQTT Manager

Donc on a vu le plugin Jeedom ZigbeeLinker pour s’occuper directement des appareils de Z2M en se connectant comme client au broker Mosquitto. Mais ZigbeeLinker est spécialisé pour identifier les appareils Zigbee, pas pour gérer du mqtt en général. Pour cela dans Jeedom on a deux plugins gratuits : JMQTT et MQTT Manager. Et il a encore fallu en choisir un, plus ou moins au pif – ma technique c’est de regarder celui qui à la mise à jour la plus récente sur le market… et ce jour là, enfin voilà.

3.1 Le plugin MQTT Manager, passerelle entre Jeedom et Solar Assistant

Je passe l’installation du plugin et son activation, rien de particulier. Go dans la config lui donner l’adresse du broker, port 1883. Soit celui de Solar Assistant directement, soit le « général » si un pont a été créé (mosquitto.conf, tout ça…)

Ensuite on crée un nouvel équipement, on renseigne son petit nom sans oublier le topic racine et l’analyse

Puis onglet commande et on lance une recherche, on coche tout ce qui nous intéresse et sauvegarde (x2)

Et voilà, toutes les commandes « info » de l’onduleur sont liées à Jeedom ! Et on va pouvoir les utiliser dans les scénarios.

3.2 Le pilotage dans Jeedom

C’est dans cette partie qu’on va boucler la boucle. Pourquoi tout ça ? les appareils zigbee, le serveur mqtt et Solar Assistant ? On va tous les connecter ensemble pour faire du délestage automatisé, orchestré par Jeedom.

3.2.1 Un point sur le surplus

Comme évoqué précédemment, avec du solaire on ne consomme pas toute la production à l’instant où elle est produite :

Si il y a 6kw de puissance de panneaux installée, en plein mois de juillet ça va produire 6kw en continu une bonne partie de la journée. Et donc avec le « talon de consommation » (les appareils qui consomment en continu : frigo, congel, box internet, serveur etc…) qui chez moi équivaut à 250w en moyenne et même en allumant quelques équipements de temps en temps (chauffe eau, électroménager et j’en passe) toute la production ne sera pas consommée. Et le but c’est quand même de rentabiliser un peu l’investissement en profitant au max de l’énergie solaire.

Surplus = ce qui n’est pas consommé à l’instant où il est produit

On passe les contrats de revente car à ce moment-là, le surplus part au réseau à travers un compteur et on reçoit de l’argent en fonction de la production vendue. Sur un système sans injection réseau c’est déjà plus complexe, car on interdit à l’onduleur d’envoyer du courant dans le réseau (programmation, pince ampèremétrique, coupure du réseau). Mais le surplus existe toujours et il faut bien en faire quelque chose. Pour l’onduleur c’est assez simple, il lui reste 3 options :

• Consommer le surplus en direct (allumer des appareils)
• Charger des batteries
• Brider le contrôleur de puissance des panneaux solaire (MPPT)

3.2.2 Gestion du surplus

Autant l’avouer de suite, le bridage est exactement ce qu’on ne veut pas voir : une fois les batteries pleines, si la production n’est pas consommée le MPPT va limiter la production à la consommation de la maison vu qu’il ne peut pas « l’évacuer » dans le réseau. En été ça peut arriver très vite sans délestage et on se retrouve à 13h avec les batteries chargées et une journée radieuse qui continue sans être rentabilisée, et c’est terrible !

Dans ce système, le but est de privilégier la consommation de la maison et se servir des batteries en tampon du surplus, tant que les batteries ne sont pas pleines elles peuvent l'absorber ; le but étant de contrôler la charge par des délestages et arriver en fin de journée avec au moins 90% de batteries pour passer la soirée et éventuellement la nuit et l'aube du lendemain en attendant le soleil, ou pas.

3.2.3 Suivant les saisons

La suite, c’est plutôt de la cuisine et chacun sa sauce. Car il va falloir peser entre la météo, qui est quand même le personnage principal de l’histoire, la saison, la consommation de la maison plus ou moins aléatoire, la charge des batteries, les jours Tempo et les appareils à notre disposition pour délester …

3.2.3.1 L’été

On profite au maximum des équipements, objectif hors réseau permanent : on part à raz-les-pâquerettes des batteries le matin, pour arriver chargé à fond en fin de journée et passer la nuit sur batteries, puis recommencer le lendemain. Voir passer un jour de mauvais temps sur batteries, les panneaux produisent toujours un peu, mais anticiper si plusieurs sont prévus. Délestage : chauffe-eau, climatiseur, déshumidificateur, c’est la charge batterie au long de la journée qui va déterminer comment délester.

3.2.3.2 Printemps et automne

C’est le plus compliqué et qui fait s’arracher les cheveux dans les scénarios. Les nuages qui défilent les uns derrière les autres, les alternances de jours de beaux et mauvais temps, pas trop savoir s’il faut chauffer ou refroidir, jongler avec la charge batterie. Bon courage mais je donnerai quand même quelques petits trucs pour s’en sortir.

3.2.3.3 L’Hiver

Objectif : survivre. Non, franchement ça va. En contrat Tempo la base pour faire des économies c’est d’être hors réseau les jours rouges quoi qu’il en coûte (sic) quitte à refaire le niveau des batteries en heures creuses. Dans le sud, un jour rouge c’est un jour de grand froid, qui dit anticyclone, qui dit beau temps ! Pas toujours, mais souvent. Du coup c’est pas si terrible. La nuit reconnexion réseau pour chauffer et éventuellement charger ou faire du maintien de charge jusqu’au lendemain et les jours de beau temps quand les batteries chargent bien on chauffe de l’eau ou des pièces. Le mieux étant d’avoir un autre système de chauffage pour s’en sortir quand on procède comme ça (bois ou pellets)

3.2.4 Comment on procède

Pour expliquer un peu le graphique ci-dessus, de 7h30/ 40% de batteries à 19h00/ 80% de batteries – Pic 92% à 16h15

• En haut, en jaune la production solaire, en bleu la consommation de l’onduleur (maison), le réseau en rouge (coupé) kW
• Milieu : charge et décharge batterie kW = positif quand ça charge, négatif en décharge.
• Bas : remplissage des batteries en %

Dès que la puissance de charge solaire atteint une certaine valeur constante, le chauffe-eau s’allume. Puis dès que la batterie atteint un pourcentage défini, des radiateurs s’allument graduellement à plusieurs paliers de pourcentage de charge batterie et fonction de la puissance de charge constante. Puis au fur et à mesure que le soleil diminue, les radiateurs s’éteignent à une puissance de charge elle aussi constante. Je dis beaucoup constante car j’ai une petite astuce que je vais révéler au chapitre suivant !

3.2.1 Le scenario de délestage

Le scénario de délestage est activé par un scénario « maître » qui le déclenche à 9h du matin et l’arrête à 19h en hiver. Il boucle ensuite toutes les 3 minutes dans la plage horaire pour analyser la production, consommation et charge batterie, et allumer ou éteindre des équipements. Trois scénarios différents de délestage se déclenchent en fonction de la saison, on ne va pas chercher à allumer des radiateurs en plein été. Chaque scénario propose une variation en fonction de la prévision météo (soleil ou mauvais temps = délestage à +/- du % batterie) mais il marche quand même sans internet à défaut – tout est en local ça serait dommage d’être bloqué à cause d’une valeur internet.

3.2.1.1 L’astuce : définir des moyennes

Pour palier au problème des nuages qui défilent et pour ne pas déclencher/éteindre des appareils à chaque variation extrême, je m’appuie sur un système de moyennes contenues dans des variables.

averageBetween(#[Energie][solar_assistant][totalbattery_powerstate]#,10 min ago,now)
averageBetween(#[Energie][solar_assistant][totalbattery_powerstate]#,5 min ago,now)

[totalbattery_powerstate] est la puissance de charge/décharge des batteries en Watts. averageBetween() est la fonction qui définit la moyenne. Ici entre le moment ou la boucle passe et la moyenne des valeurs des 10 ou 5 minutes précédentes. Plus on a de mesures, plus la moyenne est précise et relative à l’ensoleillement réel.

Même si « la boucle » de délestage passe toutes les 3 minutes, les valeurs contenues dans l’historique sont réactualisées chaque seconde et sont prises en compte au calcul de la moyenne, donc pensez à activer l’historique de la commande, sinon le scénario retournera une erreur.

3.2.1.2 Le concept

La manœuvre est assez simple :

• On va laisser la charge solaire des batteries se faire pour s’assurer un minimum de 80%. Un jour de beau temps d’hiver où on a besoin de délester. Si le temps est pourri la question ne se pose pas.
• A partir de ce moment, on va commencer à contrôler la charge en ralentissant la puissance de charge : si on charge à 2000w, on va allumer un radiateur pour réduire la voilure et arriver moins vite aux 100% de charge.
• On procède graduellement : plus on s’approche des 100%, plus on va allumer des appareils mais sans passer en décharge. Du moins le moins possible.
• Arrivé en fin de journée ou si le soleil s’en va : les appareils s’éteignent un à un avec la baisse de production, en minimisant l’utilisation de la batterie.
• Se base sur une moyenne de 10 min pour allumer un équipement et 5 min pour l’éteindre : permet d’être plus réactif à l’arrêt qu’au démarrage en cas d’arrivée de gros nuages.
• Si un équipement est allumé dans la période : il va automatiquement influer dans la moyenne de charge et donc forcer l’extinction d’un délestage.

3.2.1.3 Concrètement

Pour allumer un premier radiateur de délestage de 500w, le scénario attend d’atteindre 80% de charge batteries. Puis il évalue la valeur moyenne sur 10 minutes et à minima de 900w de charge batterie, pour assurer 400w de charge après déclenchement du radiateur. Quand un radiateur se déclenche, il soustrait directement sa puissance à la valeur moyenne pour éviter des déclenchements en série des radiateurs suivant au passage de la boucle. Si la production baisse à cause des nuages ou en fin de journée, le scénario éteindra le radiateur si la valeur de charge moyenne sur 5 min passe sous les 100w. Et ainsi en cascade à 75%, 80%, 85% etc. Il attend 5 sec à chaque on/off que les valeurs de consommation se réajustent. Il attend aussi que les radiateurs dans la file derrière lui soient éteints.

En fin de scénario si la charge batterie atteint 95%, soit le chauffe-eau soit un radiateur de 1500W se déclenche pour redescendre les batterie à 90%. En effet, au-delà les micro-onduleurs commencent à se couper quand on approche des 100%. L’onduleur ne sais pas les « brider » comme avec le MPPT. Et les derniers % de batterie ne sont jamais très linéaires.

On peut affiner ça en fonction de la température des pièces à chauffer en priorité et commencer par la plus basse. Mais vivant dans une vieille baraque en cailloux, la question ne se pose pas, on peut chauffer… Priorité SdB, puis les chambres, le couloir, et le séjour même s’il y a l’insert.

Un autre scénario rééquilibre la batterie une fois par semaine à 100%

3.2.2 Le scénario « 22h00 – 6h00 »

En contrat Tempo, tout le monde est en HC de 22h à 6h. L’hiver difficile d’échapper à l’accrochage réseau pour chauffer ou recharger. A 22h le scénario se lance pour analyser ce qu’il faut faire.

3.2.2.1 Le « Work Mode »

Un truc qui est bien pratique aussi, c’est de pouvoir envoyer des commandes automatiques à l’onduleur. En particulier pour le « WORK MODE », un tableau dans le software de l’onduleur qui défini les plages de travail. A quelle heure il peut se connecter au réseau et à quel pourcentage de batteries minimum il peut descendre, ou a quel pourcentage il doit recharger en fonction des heures.

• En hiver, ça permet de figer la charge à la valeur % batteries au passage réseau à 22h pour faire du maintien la nuit et repartir le lendemain. Ici la commande lui a été envoyée de rester à 62% jusqu’à 5h55, charge à laquelle le rack était à 22h
• Permet de définir une recharge de nuit si la batterie n’est pas assez chargée pour un lendemain maussade
• L’été ça permet de définir le % batterie de départ de la journée au plus bas (vers 20% si il fait très beau ou 40% si pas terrible)
• 15% en journée pour ne pas descendre trop bas par sécurité pour les batteries, mais les scénarios veillent au grain avant d’en arriver là.

Ce système sert à limiter les recharges réseau. Connaissant le niveau de charge et la météo du lendemain on peut automatiquement lui dire de rester hors réseau, faire juste du maintien de charge ou de charger les batteries.

3.2.2.2 Paramétrer dans Mqtt Manager

Et c’est là que le plugin de Jeedom « Mqtt Manager » revient dans la danse, car il va aussi pouvoir envoyer les ordres directement à l’onduleur via Solar Assistant et le mqtt.

On retourne dans notre équipement MQTT Manager « solar_assistant » et dans l’onglet « Commandes », on va créer une commande « action »

Les paramètres « inverter_1/capacity_point_1/set » et « inverter_1/capacity_point_6/set » correspondent respectivement aux lignes 1 et 6 du tableau Work Mode, celles de nuit. SET défini un envoi de valeur mqtt. Dans la valeur à envoyer on a une variable, c’est plus facile à gérer dans le scénario. Quand la commande « WM_point1_XX » est exécutée, la valeur de la variable(deye_wm_point1) est envoyée à l’onduleur 🙂

3.2.2.3 Les scénarios

Ensuite on passe au scénario. C’est ici qu’on va définir à quel % de batterie on va repartir le lendemain dans la variable d’envoi de valeur à l’onduleur. La variable de condition « SI » correspond aux heures d’ensoleillement prévues à J+1 (plugin MétéoMC), avec +/- de variations suivant la météo de J+2 et d’autres paramètres. Si la box internet ne répond pas, pas de prévision météo donc 70% de batterie par défaut :

Pour les mois d’hiver, on fige la batterie en maintien de charge au % où elle se trouve à 22h00 ( et point 1 = point 6) :

Une fois que tous les ajustements sont faits, on envoi les commandes d’exécution :

Et voilà, le Work mode de l’onduleur a été modifié automatiquement !

4. Pour conclure

Je ne suis pas des métiers de l’informatique, de l’électricité ou du solaire, juste un scaphandrier avec un bon niveau de « système D » et un attrait certain pour ces domaines, comme quoi…

Le crossover solaire/domotique n’est pas encore très répandu, sans doute à cause de sa complexité à mettre en œuvre de manière industrielle, mais surtout de part la personnalisation à appliquer car chaque foyer a ses particularités. Pourtant c’est une solution qui paraît évidente quand on voit les possibilités qu’elle ouvre en termes d’optimisation énergétique domestique.

En espérant avoir contribué convenablement à la cause. Bonne production aux solaristes et merci aux dev et contributeurs de Jeedom.

Lionel