« Explorer l’autoconsommation de l’énergie photovoltaïque » : différence entre les versions
(Plan du document) |
|||
| (9 versions intermédiaires par 3 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
== Ressources == | == 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 == | == 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 === | === Matériel === | ||
* Nano-grid Manjet | |||
* Prise connectée NOUS A8T | |||
* Raspberry PI | |||
== Plan d'action == | == Plan d'action == | ||
| Ligne 16 : | Ligne 42 : | ||
== Analyse des courbes de charge et de production == | == Analyse des courbes de charge et de production == | ||
<blockquote>Courbe de charge : données temporelles de consommation d'énergie dans un réseau</blockquote>On récupère les courbes de charges typiques de chaque appareil électrique habituellement présent dans les logements via [https://www.data.gouv.fr/datasets/consommation-electrique-heure-par-heure-des-appareils-domestiques 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 [https://re.jrc.ec.europa.eu/pvg_tools/fr/ la base de données PVGIS] dans des conditions similaires à Manjet (orientation 30° Sud, 1,6kW crête) <blockquote>'''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''' | |||
</blockquote>[[Fichier:Aires empilées.png|vignette|Production photovoltaïque et aires empilées des consommation des différents appareils ]] | |||
[[Fichier:Aire empilées sans eau chaude.png|vignette|Comparaison de la production photovoltaïque et des consommations des différents appareils (sans ballon d'eau chaude)]] | |||
[[Fichier:Courbes de charges des différents appareils électriques.png|vignette|Courbes de charges au pas horaire des différents appareils électriques ]] | |||
== Pilotage de la prise connectée == | == Pilotage de la prise connectée == | ||
[[Fichier:Schema de l'installation.jpg|vignette|383x383px|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. | |||
[[Fichier:Pilotage.jpg|vignette]] | |||
=== Concepts Home Assistant utilisés === | |||
==== Entités ==== | |||
Les objets manipulés dans Home Assistant : | |||
* <code>input_number.*</code> : valeurs numériques configurables | |||
* <code>switch.*</code> : prises réelles pilotées | |||
* <code>sensor.*</code> : 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 : | |||
<syntaxhighlight lang="yaml"> | |||
default_config: | |||
frontend: | |||
themes: !include_dir_merge_named themes | |||
automation: !include automations.yaml | |||
script: !include scripts.yaml | |||
scene: !include scenes.yaml | |||
</syntaxhighlight> | |||
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 <code>configuration.yaml</code> sont : | |||
* <code>input_number.production_solaire</code> | |||
** représente la puissance solaire disponible | |||
** sert de donnée d’entrée principale pour la décision | |||
* <code>input_number.seuil_puissance_prise</code> | |||
** représente le seuil à partir duquel la première prise peut être activée | |||
* <code>input_number.hysteresis_puissance_prise</code> | |||
** représente la marge utilisée pour éviter des basculements trop fréquents autour du seuil | |||
* <code>input_number.puissance_restante</code> | |||
** 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 <code>entity_id</code> ont été regroupés dans des variables d’automatisation afin d’éviter les références dispersées dans le YAML. | |||
Exemple : | |||
* <code>prise_1_switch: switch.tasmota</code> | |||
* <code>prise_2_switch: switch.tasmota_2</code> | |||
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 <code>production_solaire >= seuil</code> | |||
* éteindre si <code>production_solaire < seuil - hysteresis</code> | |||
* 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 <code>puissance_restante > 60</code> | |||
* alors <code>prise_2_switch</code> 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 <code>input_number.puissance_restante</code>. | |||
Une automatisation met à jour cette valeur à chaque changement pertinent. | |||
Formule utilisée : | |||
<pre> | |||
puissance_restante = production_solaire - conso_prise_1 - conso_prise_2 | |||
</pre> | |||
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 : | |||
* <code>sensor.tasmota_energy_power</code> | |||
* <code>sensor.tasmota_energy_power_2</code> | |||
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 : | |||
* <code>TelePeriod</code> | |||
Exemple de réglages envisagés dans la console Tasmota : | |||
<pre> | |||
TelePeriod 10 | |||
</pre> | |||
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. <code>numeric_state</code> est strict ==== | |||
Avec : | |||
* <code>above</code> | |||
* <code>below</code> | |||
les comparaisons sont strictes : | |||
* <code>above</code> = <code>></code> | |||
* <code>below</code> = <code><</code> | |||
Donc une valeur exactement égale au seuil ne déclenche pas <code>above</code>. | |||
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 <code>switch.*</code> doit être pilotée avec <code>switch.turn_on</code> et <code>switch.turn_off</code> | |||
==== 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 <code>input_number.puissance_restante</code> | |||
* 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 == | == Réalisation de l'application == | ||
Version actuelle datée du 10 avril 2026 à 17:44
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
Pilotage de la prise connectée
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.
Concepts Home Assistant utilisés
Entités
Les objets manipulés dans Home Assistant :
input_number.*: valeurs numériques configurablesswitch.*: prises réelles pilotéessensor.*: 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.tasmotaprise_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_switchs’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_powersensor.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 :
abovebelow
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 avecswitch.turn_onetswitch.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

