Optimisation photovoltaïque #5 : Le système de régulation

Sommaire

Cet article fait partie d’une série de posts ayant pour objectif de rendre rentable l’utilisation de panneaux solaires photovoltaïque dans un contexte domestique. Pour bien comprendre ce dont il s’agit, il est recommandé de lire les articles dans l’ordre. En voici la liste :

• 1. Le raisonnement : ce qui motive la rédaction de ces articles.
• 2. Principe et survol de la solution technique : comment exploiter à 100% l’énergie des panneaux solaires.
• 3. Contrôle numérique du variateur de puissance : pilotage de la puissance fournie en temps réel par un système informatique.
• 4. Mesurer l’énergie produite et l’énergie consommée : à l’aide de modules PZEM-004t et de microcontroleurs WiFi ESP8266 (ESP-01).
• 5. Le système de régulation : on rassemble toute les briques !
• 6. Dimensionnement : choisir de façon optimale sa capacité de production solaire photo voltaïque.
• 7. Et pour aller plus loin : améliorations et idées diverses.

La régulation

Etant informaticien, c’est la partie la plus simple pour moi, mais en même temps c’est aussi celle que j’ai retravaillée et ajustée le plus longuement. Le logiciel n’est pas complexe, mais il faut naturellement un peu de temps pour rencontrer les diverses situations, les analyser, en déduire un automatisme approprié et enfin l’éprouver en situation réelle.

Passer en revue le code source en lui même serait pour le moins aride. Par ailleurs, si au bout du compte je suis très satisfait du comportement de ce logiciel, je perçois aussi ses limites.

Pour ces raisons, le présent article décrit le programme de régulation dans ses grandes lignes d’une part, et d’autre part met l’accent sur les adaptations/configurations à apporter pour l’utiliser dans un autre contexte (c’est à dire le vôtre)

Code source

Le code source du programme de régulation est disponible sur GitHub à cette adresse : https://github.com/pierrehebert/photovoltaic_optimizer/tree/master/regulation. Il s’agit d’un programme Python (compatible 2.7) n’ayant d’autre dépendance que paho-mqtt.

Fonctionnement général

L’implémentation proposée ici s’articule autours de deux modules:

• Le module “equipment” : définition des équipements électriques qui peuvent être pilotés par la régulation. On y trouve différentes classes d’équipements, selon leur possibilités (consommation d’une puissance variable grace au SCR, consommation d’une puissance fixe et connue et pilotée en tout ou rien). La classe “Equipment” (et ses dérivées) fournit une abstraction du pilotage, calcule les compteurs d’énergie et gère les modes de forçage.
• Le module “regulation” implémente la logique à proprement parler. A partir d’une liste d’équipements (à configurer selon les besoins), le programme peut agir sur la consommation en allumant/éteignant des appareils. Pour équilibrer consommation et production le logiciel opère d’abord en mode “direct” puis ajuste les niveaux “par incréments”. C’est à dire que le programme est capable de déterminer directement quelle est la puissance à allouer à un appareil afin de se rapprocher au plus vite de l’équilibre, puis ajuste les valeurs graduellement.

Nous n’entrerons pas plus ici dans les détails du programme. Pour bien saisir toutes les subtilités, mieux vaut s’en remettre au code source lui même

Aspects matériel

Le programme de régulation doit fonctionner en permanence, 7 jours sur 7, et si possible 24h/24. On peut envisager un fonctionnement uniquement lors de la production solaire cependant le programme proposé ne prend pas en compte ce cas de figure.

On a la possibilité d’héberger le programme sur une machine locale, ou pourquoi pas sur le cloud étant donné que les échanges sont purement réseau via MQTT.

Cette dernière option peut paraître surprenant mais n’est pas à rejeter totalement : la régulation est relativement “lente” (quelques secondes) et reste compatible avec les latences réseau. Elle permet surtout de mutualiser une ressource matérielle existante.

Ceci étant, je préconise une mise en œuvre locale dès lors qu’une ressource de calcul bon marché (du point de vue énergétique et matériel) est disponible. L’essentiel est de disposer d’un interpréteur Python. La charge de calcul étant très faible un processeur “lent” convient. Un Raspberry Pi, même le modèle 1, c’est à dire le plus ancien modèle, est un bon choix. Il est possible aussi de recycler un ancien appareil Android (téléphone ou tablette). Cette solution peut paraître farfelue mais laissez moi présenter ses avantages : l’appareil est facile à trouver à un prix défiant toute concurence, il est économe en énergie, dispose d’un écran intégré, se connecte au WiFi sans problème, est déjà équippé d’un système d’exploitation et, last but not least, dispose de sa propre batterie de secours. Pensez y

Limites

Tout d’abord, le logiciel proposé n’est pas un programme générique, il contient une part importante de fonctionnel spécifique, en particulier le mécanisme de “fallback” qui permet de recourir automatiquement à EDF pour chauffer l’eau, en cas d’absence prolongée d’ensoleillement. En d’autres termes il vous faudra peut être adapter un peu le code source si vous souhaitez l’utiliser dans votre système, il n’existe pas de procédure d’installation “plug&play”, ni documentation détaillée. Le programme est cependant raisonnablement commenté.

Une autre limite réside dans la période de régulation trop longue. On en a déjà parlé dans l’article sur la prise de mesure. Même si c’est au niveau de la mesure que se situe réellement le problème, il n’en reste pas moins que le programme de régulation pourrait réaliser un lissage (ou similaire) pour absorber les variations rapides typiquement produites par les appareils de cuisson. Je n’ai pas tenté d’améliorer ce point, n’étant pas sur que le jeu en vaille la chandelle.

Enfin le mécanisme de “fallback”, qui décide quand apporter de l’énergie au ballon depuis EDF, ne pourra jamais être optimal. Il manque simplement des informations telles que : quantité d’eau chaude utilisée, température de l’eau en entrée, prévisions météo, prévisions de consommation. En admettant que ces informations soient connues on pourrait précisément déterminer la quantité d’énergie manquante. Techniquement c’est certainement faisable mais je doute que le coût d’installation puisse être amorti un jour par les gains obtenus de cette optimisation. Pour l’instant je suppose qu’une heuristique simple, quoiqu’imparfaite, reste le meilleur compromis possible… A condition de recourir de temps en temps à des opération manuelles ! Par exemple je désactive le mécanisme de fallback en cas d’absence prolongée. Il peut aussi m’arriver d’annuler le fallback si la météo prévoit du beau temps pour le lendemain.

Pour autant ces limitations restent mineures. En pratique la marge de progression n’est probablement que de quelques pourcents, et sans doute inférieure aux pertes (onduleurs, isolement du ballon, autres).