Explorer l’autoconsommation de l’énergie photovoltaïque

De WikiRennes
Aller à la navigationAller à la recherche

Ressources

Lien vers notre dossier de travail : https://partage.imt.fr/index.php/s/n2aiTRaPjtwF4kk

Membres de l'équipe

  • Éva
  • Malo
  • Guillaume
  • Clément
  • Jean-Marie
  • Baptiste
  • Mickael
  • David

Contexte

Enjeu

Dans les foyers équipés de panneaux solaires, l’autoconsommation (utilisation directe de l’électricité produite par les ) est souvent faible en raison d’un décalage temporel entre :

  • Production : Pic en milieu de journée (quand les habitant·es sont souvent absent·es).
  • Consommation : Pics le matin et le soir (quand la production est faible ou nulle).

Conséquences :

  • Revente du surplus à un tarif peu avantageux (voir même injection gratuite sur le réseau).
  • Recours au réseau électrique en période de faible production, augmentant la facture.

L'enjeu est donc d'adapter la consommation des appareils électriques domestiques pour la faire mieux correspondre à la production d'énergie par des panneaux photovoltaïques dans un contexte d'autoconsommation.

Matériel

  • Nano-grid Manjet
  • Prise connectée NOUS A8T
  • Raspberry PI

Plan d'action

1. Récupérer la production instantanée des panneaux solaires

2. Piloter la charge d'un ou plusieurs appareils

3. Concevoir un système qui invite les usager.es à adapter leur consommation électrique

Analyse des courbes de charge et de production

Courbe de charge : données temporelles de consommation d'énergie dans un réseau

On récupère les courbes de charges typiques de chaque appareil électrique habituellement présent dans les logements via un jeu de données ADEME . Il s'agit de profils de consommation moyens calculés à partir des données agrégées d'une centaine de logements, toutes saisons confondues.

  • Le ballon d'eau chaude fonctionne uniquement la nuit, conséquence des tarifs avantageux de l'électricité pendant les heures creuses
  • Les pics d'utilisation du lave vaisselle se situent après les repas
  • les pics d'utilisation du lave linge à 11h et à 20h, il est utilisé le plus fréquemment en journée

Note : Le fonctionnement du réfrigérateur étant lié à son utilisation, les données agrégées de permettent pas de dégager de tendance

On récupère également un profil type de production solaire photovoltaïque via la base de données PVGIS dans des conditions similaires à Manjet (orientation 30° Sud, 1,6kW crête)

On peut en déduire que :

  • le pilotage du ballon d'eau chaude est la stratégie la plus intéressante puisqu'il s'agit d'un moyen de stockage qui peut être chargé indépendamment des besoins, et qui de plus a une consommation bien supérieure à tous les autres appareils domestiques
  • le lave-linge, le lave vaisselle et les petits appareils électroniques sont des postes de consommation facilement des déportables mais non pilotables automatiquement
Production photovoltaïque et aires empilées des consommation des différents appareils
Comparaison de la production photovoltaïque et des consommations des différents appareils (sans ballon d'eau chaude)
Courbes de charges au pas horaire des différents appareils électriques

Pilotage de la prise connectée

Schéma de l'installation


Objectif

Construire un prototype dans Home Assistant pour préparer un futur branchement à un panneau solaire, avec cette logique :

  • mesurer ou simuler une puissance disponible
  • définir un seuil de déclenchement
  • allumer des prises connectées en fonction de la puissance produite
  • gérer une marge d’hystérésis pour éviter les allumages/extinctions trop fréquents
  • calculer une puissance restante pour décider d’allumer une deuxième prise

L’objectif du prototype est de valider l’architecture de pilotage et les règles métier avant le raccordement à une source solaire réelle.

Périmètre du prototype

Le prototype couvre les briques suivantes :

  • modélisation des paramètres de pilotage dans Home Assistant
  • calcul d’une puissance disponible et d’une puissance restante
  • pilotage séquentiel de plusieurs prises connectées
  • prise en compte d’une hystérésis pour stabiliser les décisions
  • préparation d’une future intégration temps réel avec une mesure de production réelle

Le prototype ne cherche pas encore à être définitif ni optimisé pour la production. Il sert avant tout à valider la logique fonctionnelle.

Pilotage.jpg

Concepts Home Assistant utilisés

Entités

Les objets manipulés dans Home Assistant :

  • input_number.* : valeurs numériques configurables
  • switch.* : prises réelles pilotées
  • sensor.* : capteurs de puissance remontés par Tasmota

Helpers

Des entités simples créées pour piloter la logique :

  • seuil
  • hystérésis
  • production solaire
  • puissance restante

Automatisations

Règles déclenchées quand une valeur change, pour :

  • recalculer une puissance restante
  • allumer ou éteindre les prises selon la puissance disponible

Structure de configuration utilisée

La structure Home Assistant conservée est volontairement simple :

default_config:

frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

Le prototype a été intégré dans les fichiers YAML déjà présents, sans introduire de système de packages supplémentaire.

Paramètres de pilotage

Les principaux paramètres manipulés dans configuration.yaml sont :

  • input_number.production_solaire
    • représente la puissance solaire disponible
    • sert de donnée d’entrée principale pour la décision
  • input_number.seuil_puissance_prise
    • représente le seuil à partir duquel la première prise peut être activée
  • input_number.hysteresis_puissance_prise
    • représente la marge utilisée pour éviter des basculements trop fréquents autour du seuil
  • input_number.puissance_restante
    • stocke la puissance encore disponible après déduction des consommations connues

Ces helpers permettent de rendre la logique lisible, observable et modifiable depuis Home Assistant.

Pilotage des prises

Le prototype pilote deux prises :

  • prise 1
  • prise 2

Les entity_id ont été regroupés dans des variables d’automatisation afin d’éviter les références dispersées dans le YAML.

Exemple :

  • prise_1_switch: switch.tasmota
  • prise_2_switch: switch.tasmota_2

Cette approche simplifie la maintenance et permet de remplacer plus facilement les prises ciblées.

Algorithme de pilotage mis en place

Prise 1

La prise 1 est pilotée à partir de la production solaire et d’un seuil avec hystérésis.

Règle retenue :

  • allumer si production_solaire >= seuil
  • éteindre si production_solaire < seuil - hysteresis
  • entre les deux, conserver l’état actuel

Cette logique évite les comportements instables lorsque la puissance disponible oscille autour du seuil.

Rôle de l’hystérésis

L’hystérésis ajoute une zone tampon entre la condition d’allumage et la condition d’extinction.

Exemple :

  • seuil = 300 W
  • hystérésis = 20 W

Alors :

  • allumage à partir de 300 W
  • extinction seulement sous 280 W

Cette stratégie réduit les cycles courts et protège la stabilité globale du système.

Prise 2

La prise 2 est pilotée selon la puissance restante.

Règle retenue :

  • si la puissance restante dépasse un seuil minimal
  • alors on allume la prise 2
  • sinon on l’éteint

Exemple :

  • si puissance_restante > 60
  • alors prise_2_switch s’allume

Le prototype introduit ainsi une logique de pilotage séquentiel : la deuxième charge n’est activée qu’une fois la première prise servie et si un surplus de puissance subsiste.

Calcul de la puissance restante

La puissance restante a finalement été stockée dans un helper input_number.puissance_restante.

Une automatisation met à jour cette valeur à chaque changement pertinent.

Formule utilisée :

puissance_restante = production_solaire - conso_prise_1 - conso_prise_2

Avec plancher à 0 :

  • si le résultat est négatif, on conserve 0

Ce choix a été retenu pour plusieurs raisons :

  • simplifier le debug
  • rendre la valeur visible dans l’interface
  • pouvoir la réutiliser facilement dans les autres automatisations

Capteurs de puissance Tasmota

Les prises Tasmota exposent des capteurs de puissance tels que :

  • sensor.tasmota_energy_power
  • sensor.tasmota_energy_power_2

Ces capteurs sont utilisés pour estimer la consommation réelle des prises et alimenter le calcul de la puissance restante.

Un point important a été identifié pendant le prototype :

  • le capteur Home Assistant exploité n’était pas suffisamment réactif
  • la mesure semblait agrégée sur une fenêtre d’environ 5 minutes

Conclusion :

  • pour un pilotage réellement dynamique, il faudra s’appuyer sur une télémétrie plus directe et plus fréquente

Réactivité Tasmota

Pour préparer une intégration plus temps réel, le réglages Tasmota suivant a été identifié comme utile :

  • TelePeriod

Exemple de réglages envisagés dans la console Tasmota :

TelePeriod 10

Objectif :

  • réduire l’intervalle de remontée
  • publier lors des variations de puissance
  • obtenir une donnée exploitable pour un pilotage plus fin

Cela constituera une étape importante lorsque le prototype passera d’une logique simulée à une mesure solaire réelle.

Notifications

Le prototype prévoit également l’envoi d’une notification lors de l’activation de la deuxième prise.

Deux canaux ont été envisagés :

  • notification standard
  • notification persistante dans Home Assistant

Un garde-fou a été ajouté pour éviter les répétitions inutiles :

  • la notification ne doit partir qu’au moment du basculement effectif de la prise 2 vers l’état allumé

Points techniques importants rencontrés

1. numeric_state est strict

Avec :

  • above
  • below

les comparaisons sont strictes :

  • above = >
  • below = <

Donc une valeur exactement égale au seuil ne déclenche pas above.

Cette subtilité a conduit à privilégier, à certains endroits, une logique plus explicite via templates.

2. Les services doivent correspondre au domaine

Les actions doivent utiliser le bon domaine de service selon l’entité ciblée.

Exemple :

  • une prise switch.* doit être pilotée avec switch.turn_on et switch.turn_off

3. Le template sensor n’était pas visible

Le capteur template de puissance restante n’apparaissait pas correctement dans les états ni dans le dashboard.

Solution retenue :

  • remplacer le capteur template par un input_number.puissance_restante
  • mettre à jour cette valeur via une automatisation

Cette solution s’est révélée plus simple et plus robuste pour un prototype.

État actuel du prototype

Le prototype permet aujourd’hui de :

  • représenter une puissance solaire disponible dans Home Assistant
  • définir un seuil et une hystérésis
  • piloter une première prise selon cette production
  • calculer une puissance restante
  • piloter une deuxième prise selon cette puissance restante
  • émettre une notification lors de l’activation de la deuxième prise


Réalisation de l'application