Voir la source de Explorer l’autoconsommation de l’énergie photovoltaïque

== 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 ==
<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 ==
[[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 &gt;= seuil</code>
* éteindre si <code>production_solaire &lt; 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 &gt; 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>&gt;</code>
* <code>below</code> = <code>&lt;</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 ==