Cette intégration permet d'optimiser l'utilisation de votre énergie solaire. Elle commande l'allumage et l'extinction de vos équipements dont l'activation est différable dans le temps en fonction de la production et de la consommation électrique courante.
- Qu'est-ce que Solar Optimizer ?
- Comment fonctionne-t-elle ?
- Installation
- La configuration
- Entités disponibles
- La gestion de la priorité
- Les évènements
- Les actions
- Créer des modèles de capteur pour votre installation
- Une carte pour vos dashboards en complément
- Les contributions sont les bienvenues !
Nouveautés
- release 3.5.0 :
- ajout d'une gestion de la priorité. Cf. la gestion de la priorité
- release 3.2.0 :
- ajout d'un capteur optionnelle de la puissance nette instantanée chargée ou déchargée dans la batterie. Elle vient s'ajouter à la puissance nette consommée. En effet si la puissance de charge de la batterie est de la puissance disponible pour les équipements. Le capteur doit remonter une valeur en watt, positive si la batterie se décharge et négative si la batterie charge.
- release 3.0.0 :
- ajout d'une IHM de configuration des équipmements.
⚠️ l'installation de la release 3.0.0 nécessite une procédure particulière. Voir la procédure ci-dessous ici.- release 2.1.0 :
- ajout d'une durée minimale d'allumage en heure creuses. Permet de gérer les équipements qui doivent avoir un minimum d'allumage par jour comme les chauffes-eau ou les chargeurs (voitures, batteries, ……). Si l'ensoleillement n'a pas durée d'atteindre la durée requise, alors l'équipement s'allumera pendant les heures creuses. Vous pouvez en plus définir à quelle heure les compteurs d'allumage sont remis à zéro ce qui permet de profiter des toutes les heures creuses
- release 2.0.0 :
- ajout d'un appareil (device) par équipement piloté pour regrouper les entités,
- ajout d'un compteur de temps d'allumage pour chaque appareil. Lorsque le switch commandé passe à 'Off', le compteur de temps est incrémenté du temps passé à 'On', en secondes. Ce compteur est remis à zéro tous les jours à minuit.
- ajout d'un maximum de temps à 'On' dans la configuration (en minutes). Lorsque cette durée est dépassée, l'équipement n'est plus utilisable par l'algorithme (is_usable = off) jusqu'au prochain reset. Cela offre la possibilité, de ne pas dépasser un temps d'allumage maximal par jour, même lorsque la puissance solaire est disponible.
- pour profiter de cette nouvelle info, n'oubliez pas de mettre à jour le decluterring template (en fin de ce fichier)
- cette release ouvre la porte a des évolutions plus conséquentes basé sur le temps d'allumage (avoir un minimum journalier par exemple) et prépare le terrain pour l'arrivée de la configuration via l'interface graphique.
Cette intégration va vous permettre de maximiser l'utilisation de votre production solaire. Vous lui déléguez le contrôle de vos équipements dontl'activation peut être différée dans le temps (chauffe-eau, pompe de piscine, charge de véhicle électrique, lave-vaisselle, lave-linge, etc) et elle s'occupe de les lancer lorsque la puissance produite est suffisante.
Elle tente en permanence de minimiser l'import et l'export d'énergie en démarrant, stoppant, modifiant la puissance allouée à un équipement.
2 types d'équipements sont gérés :
- les équipements commandés par un switch (un service d'une manière générale) qui ont une puissance consommée fixe et pré-déterminée,
- les équipements dont la puissance de consommation est réglable (Tesla, Robotdyn). En réglant la puissance allouée à ces équipements, Solar Optimizer aligne la consommation sur la production au plus près.
L'idéal est d'avoir au moins un équipement dont la puissance est ajustable dans la liste des équipements gérés par Solar Optimizer.
Le fonctionnement est le suivant :
- à interval régulier (paramétrable), l'algorithme simule des modifications des états des équipements (allumé / éteint / puissance allouée) et calcule un coût de cette configuration. Globalement le coût est le
a * puissance_importée + b * puissance_exportée. La coefficients a et b sont calculés en fonction du cout de l'électricité au moment du calcul, - l'algorithme garde la meilleure configuration (celle qui a un cout minimum) et cherche d'autres solutions, jusqu'à ce qu'un minimum soit atteint.
- la meilleure configuration est alors appliquée.
L'algorithme utilisé est un algorithme de type recuit simulé dont vous trouverez une description ici : https://fr.wikipedia.org/wiki/Recuit_simul%C3%A9
Pour éviter les effets de bagottements d'un cycle à l'autre, un délai minimal d'activation est paramétrable par équipements : duration_min. Par exemple : un chauffe-eau doit être activé au moins une heure pour que l'allumage soit utile, la charge d'une voiture électrique doit durer au moins deux heures, ...
De façon similaire, une durée minimale de désactivation peut être spécifiée dans le paramètre duration_stop_min.
A chaque équipement configuré est associé une entité de type switch nommé enable qui permet d'autoriser l'algorithme à utiliser l'équipement. Si je veux forcer la chauffe du ballon d'eau chauffe, je mets son switch sur off. L'algorithme ne le regardera donc pas, le chauffe-eau repasse en manuel, non géré par Solar Optimizer.
Par ailleurs, il est possible de définir une règle d'utilisabilité des équipements. Par exemple, si la voiture est chargée à plus de 90%, l'algorithme considère que l'équipement qui pilote la charge de la voiture doit être éteint. Cette régle est définit sous la forme d'un template configurable qui vaut True si l'équipement est utilisable.
Si une batterie est spécifiée lors du paramétrage de l'intégration et si le seuil battery_soc_threshold est spécifié, l'équipement ne sera utilisable que si le soc (pourcentage de charge de la batterie) est supérieur ou égal au seuil.
Un temps d'utilisation maximal journalier est paramétrable en facultatif. Si il est valorisé et si la durée d'utilisation de l'équipement est dépasée, alors l'équipement ne sera pas utilisable par l'algorithme et laisse donc de la puissance pour les autres équipements.
Un temps d'utilisation minimal journalier est aussi paramétrable en facultatif. Ce paramètre permet d'assurer que l'équipement sera allumé pendant une certaine durée minimale. Vous spécifiez à quelle heure commence les heures creuses, (offpeak_time) et la durée minimale en minutes (min_on_time_per_day_min). Si à l'heure indiquée par offpeak_time, la durée minimale d'activation n'a pas été atteinte, alors l'équipement est activé jusqu'au changement de jour (paramètrable dans l'intégration et 05:00 par défaut) ou jusqu'à ce que le maximum d'utilisation soit atteint (max_on_time_per_day_min) ou pendant toute la durée des heures creuses si max_on_time_per_day_min n'est pas précisé. Vous assurez ainsi que le chauffe-eau ou la voiture sera chargée le lendemain matin même si la production solaire n'a pas permise de recharger l'appareil. A vous d'inventer les usages de cette fonction.
Ces 5 règles permettent à l'algorithme de ne commander que ce qui est réellement utile à un instant t. Ces règles sont ré-évaluées à chaque cycle.
La gestion de la priorité est décrite ici.
Le comportement de l'algorithme est fortement influencé par les valeurs des capteurs "coût du kWh importé" et "coût du kWh exporté". En effet, l'algorithme va calculer le "coût fictif" d'une combinaison d'allumage / extinction / puissance voulue des équipemenets pilotés. Si ces 2 valeurs sont égales alors le coût d'un import du réseau de 500 w sera le même que le coût d'un export vers le réseau de 500 w. Donc SO pourra soit rejeter les 500 w (sous-consommation), soit importer 500w (sur-consommation), si la puissance produite le permet.
Les valeurs des sensors de couts de revente et d'achat doivent être réglées comme suit:
- si elles sont égales, SO acceptera autant d'import que d'export. Ca "coute" la même chose pour lui d'exporter 500 w que d'importer 500 w,
- si cout d'achat est très supérieur à cout de revente, SO va minimiser l'achat mais va potentiellement exporter plus (énergie perdue),
- si cout de revente >> cout d'achat, c'est le contraire, SO va minimiser la revente et donc potentiellement importer plus (et donc la facture augmente)
👉 Si vous ne voulez aucun import (ie achat) : dans ce cas vous devez mettre un coût d'achat >> cout de revente, 👉 Pour ceux qui ont des contrats d'auto-consommation sans revente, tout ce qui est rejetté est perdu donc vous pouvez avoir intérêt à minimiser les rejets quitte à acheter un plus plus. Pour cette configuration, le coût de revente >> coût d'achat.
De mon coté j'ai mis les vraies valeurs de cout d'achat (qui varie selon le jour, l'heure : abonnement Tempo) et le vrai cout de revente qui est de 13cts le kWh. Donc si mon cout d'achat devient faible (heure creuse en bleu), je peux importer plus, si le cout d'achat est très fort (heure pleines rouge), je n'aurai pas d'import du tout. C'est bien ce que je veux dans mon cas - mais ce n'est que mon cas et parce-que j'ai un contrat de revente à 13 cts/kWh.
La version 3.0.0 amène une IHM de configuration qui permet d'ajouter facilement des nouveaux équipements à contrôler et de changer facilement leur configuration.
Cette procédure, ne doit être déroulée que si vous avez déjà installée et configurée une version 2.x.
L'installation de la v 3.0.0 impose de recréer tous les équipements via l'IHM et de supprimer la configuration du fichier configuration.yaml. La procédure à suivre est la suivante, elle doit être suivie scrupuleusement :
- allez dans Paramètres / Intégration, sélectionnez "Solar Optimizer" et supprimez l'appareil "Solar Optimizer". L'intégration "Solar Optimizer" ne doit plus être visible,
- supprimez la configuration qui est dans votre fichier
configuration.yaml, - lancez HACS, recherchez "Solar Optimizer" et faite l'installation de la version 3.0.0,
- Allez dans Paramètres / Intégration et cliquez sur "Ajouter une intégration" et sélectionnez "Solar optimizer",
- Vous arrivez sur la page de configuration des paramètres communs décrites ici
- Installez HACS. De cette façon, vous obtenez automatiquement les mises à jour.
- Ajoutez ce repository Github en tant que repository personnalisé dans les paramètres HACS.
- recherchez et installez "Solar Optimizer" dans HACS et cliquez sur "installer".
- Redémarrez Home Assistant.
- Ensuite, vous pouvez ajouter l'intégration de Solar Optimizer dans la page d'intégration. Vous ne pouvez installer qu'une seule intégration Solar Optimizer.
Une installation manuelle est possible. Elle n'est pas recommandée et donc elle ne sera pas décrite ici.
Lors de l'ajout de l'intégration Solar Optimizer, la page de paramétrage des paramètres communs s'ouvre :
Vous devez spécifier :
- une période de rafraichissement en secondes. Plus la période est courte et plus le suivi sera précis mais plus la charge du votre serveur sera importante ; les calculs sont en effet gourmands en charge CPU. 5 minutes (donc 300 sec) est une bonne valeur moyenne,
- le sensor qui donne la consommation nette instantanée du logement (elle doit être négative si la production dépasse la consommation). Ce chiffre est indiqué en Watt,
- le sensor qui donne la production photovoltaïque instantanée en Watt aussi (elle est forcément positive ou nulle),
- un sensor ou input_number qui donne le cout du kwh importé (requis: nombre strictement positif),
- un sensor ou input_number qui donne le prix du kwh exporté (requis: nombre strictement positif). On peut utiliser la même valeur/sensor que l'importée si pas de contrat de revente. Ne pas mettre 0 sinon ça fausse trop l'algorithme,
- un sensor ou input_number qui donne la valeur de la taxe applicable sur les kwh exportée en pourcentage (chiffre positif ou 0 si vous ne revendez pas ou ne connaissez pas cette valeur). Cette valeur dépend de votre contrat. Elle n'est pas déterminante dans l'algorithme donc une valeur de 0 est tout à fait adaptée,
- un sensor facultatif qui donne l'état de charge d'une éventuelle batterie solaire en pourcentage. Si vous n'avez pas de batterie dans votre installation solaire, laissez ce champ vide,
- un sensor qui donne la puissance nette instantanée de charge de la batterie. Elle doit être exprimée en watt et doit être négative si la batterie charge et positive si la batterie se décharge. Cette valeur sera ajoutée à la puissance net consommée. Si la puissance consommée nette est de -1000 w (vente de 1000 w) mais que la batterie charge de -500 w, cela veut dire que le surplus utilisable par l'algorithme est de 1500 w.
- l'heure de début de journée. A cette heure les compteurs d'uitlisation des équipements sont remis à zéro. La valeur par défaut est 05:00. Pour bien faire, elle doit être avant la première production et le plus tard possible pour les activations en heures creuses.
A part l'état de charge de la batterie solaire, ces informations sont nécessaires à l'algorithme pour fonctionner, elles sont donc toutes obligatoires. Le fait que ce soit des sensor ou input_number permet d'avoir des valeurs qui sont réévaluées à chaque cycle. En conséquence le passage en heure creuse peut modifier le calcul et donc les états des équipements puisque l'import devient moins cher. Donc tout est dynamique et recalculé à chaque cycle.
Chaque équipements pilotable doit ensuite être configuré en ajoutant une nouvelle intégration via la bouton "Ajouter un équipement" disponible dans la page de l'intégration :
Le menu suivant s'affiche alors vous permettant de choisir un équipement simple qui va fonctionner en on/off ou un équipement dont la puissance est variable (pour suivre la puissance disponible) :
Un équipement simple est un commande uniquement par un allumage / extinction (un switch). Si l'algorithme décide de l'allumer, l'équipement est allumé et sinon il est éteint. Il se configure de la façon suivante :
Vous devez spécifier les attributs suivant :
| attribut | valable pour | signification | exemple | commentaire |
|---|---|---|---|---|
name |
tous | Le nom de l'équipement. | VMC sous-sol | Le nom est utilisé pour nommé les entités de cet équipement. |
entity_id |
tous | l'entity id de l'équipement à commander | switch.vmc_sous_sol | Peut être un switch, un input_boolean, un humidifier, un climate, un fan, un select ou un light. Si l'entité n'est pas un switch, les champs activation_service et deactivation_service doivent être adaptés |
device_power or power_max |
tous | la puissance maximale consommée par l'équipement lorsqu'il est allumé en watts | 250 | - |
check_usable_template |
tous | Un template qui vaut True si l'équipement pourra être utilisé par Solar Optimizer. Un template commence par {{ et doit se terminer par }}. | {{ is_state('cover.porte_garage_garage', 'closed') }} | Dans l'exemple, Sonar Optimizer n'essayera pas de commander la "VMC sous-sol" si la porte du garage est ouverte. Laissez {{ True }} si vous ne vous servez pas de ce champ |
active_template |
tous | Un template qui vaut True si l'équipement si l'équipement est actif. Un template commence par {{ et doit se terminer par }}. Ce template n'est pas nécessaire si l'état allumé est 'on' (switch, light, humidifier) | {{ is_state('climate.clim_salon', 'cool') }} | Dans l'exemple, l'équipement de type climate sera vu par Solar Optimizer comme actif si son état est cool. Laissez vide pour les équipements pour lesquels l'état par défaut 'on' / 'off' est valable (les switchs et input_boolean) |
duration_min |
tous | La durée en minute minimale d'activation | 60 | La VMC sous-sol s'allumera toujours pour une heure au minimum |
duration_stop_min |
tous | La durée en minute minimale de desactivation. Vaut duration_min si elle n'est pas précisée |
15 | La VMC sous-sol s'éteindra toujours pour 15 min au minimum |
action_mode |
tous | le mode d'action pour allumer ou éteindre l'équipement. Peut être "action_call" ou "event" (*) | action_call | "action_call" indique que l'équipement s'allume et s'éteint via une action. Cf. ci-dessous. "event" indique qu'un évènement est envoyé lorsque l'état doit changer. Cf. (*) |
activation_service |
uniquement si action_mode="action_call" | le service a appeler pour activer l'équipement sous la forme "domain/service[/parameter:value]". Ce template doit être adapté pour tous les équipements qui ne sont pas des switchs | switch/turn_on | l'activation déclenchera le service "switch/turn_on" sur l'entité "entity_id". La syntaxe acceptée est la suivante : domain/action[/parameter:value] |
deactivation_service |
uniquement si action_mode="action_call" | le service a appeler pour désactiver l'équipement sous la forme "domain/service[/parameter:value]". Ce template doit être adapté pour tous les devices qui ne sont pas des switchs | switch/turn_off | la désactivation déclenchera le service "switch/turn_off" sur l'entité "entity_id". La syntaxe acceptée est la suivante : domain/action[/parameter:value] |
battery_soc_threshold |
tous | le pourcentage minimal de charge de la batterie pour que l'équipement soit utilisable | 30 | Dans cet exemple, l'équipement ne sera utilisable par l'algorithme si la batterie solaire n'est pas chargée à au moins 30%. Nécessite le renseignement de l'entité d'état de charge de la batterie dans les paramètres communs. Cf. ci-dessus. |
max_on_time_per_day_min |
tous | le nombre de minutes maximal en position allumé pour cet équipement. Au delà, l'équipement n'est plus utilisable par l'algorithme | 10 | L'équipement sera allumé au maximum 10 minutes par jour |
min_on_time_per_day_min |
tous | le nombre de minutes minimale en position allumé pour cet équipement. Si lors du démarrage des heures creuses, ce minimum n'est pas atteint alors l'équipement sera allumé à concurrence du début de journée ou du max_on_time_per_day_min |
5 | L'équipement est sera allumé au minimum 5 minutes par jour ; soit pendant la production solaire, soit pendant les heures creuses |
offpeak_time |
tous | L'heure de début des heures creuses au format hh:mm | 22:00 | L'équipement pourra être allumé à 22h00 si la production de la journée n'a pas été suffisante |
Ce type d'équipement permet moduler la puissance consommée par l'équipement en fonction de la production solaire et de ce que décide l'algorithme. Vous avez ainsi une sorte de routeur solaire logiciel qui permet, par exemple, de moduler la charge d'une voiture électrique avec uniquement le surplus de production.
Tous les paramètres décrits ici s'applique et douvent être complétés par ceux-ci :
| attribut | valable pour | signification | exemple | commentaire |
|---|---|---|---|---|
power_entity_id |
équipement à puissance variable | l'entity_id de l'entité gérant la puissance | number.tesla_charging_amps |
Le changement de puissance se fera par un appel du service change_power_service sur cette entité. Elle peut être un number, un input_number, un fan ou une light. Si l'entité n'est pas un number, le champ change_power_service doit être adaptés. |
power_min |
équipement a puissance variable | La puissance minimale en watt de l'équipement | 100 | Lorsque la consigne de puissance passe en dessous de cette valeur, l'équipement sera éteint par l'appel du deactivation_service. Ce paramètre fonctionne avec power_max pour définir l'interval possible de variation de la puissance |
power_step |
équipement a puissance variable | Le pas de puissance en watt | 10 | Pour une voiture mettre 230 (230 v x 1 A). Pour une entité light mettre power_max / 255Pour une entité fan mettre power_max / 100 |
change_power_service |
équipement a puissance variable | Le service à appeler pour changer la puissance | number/set_valueor light/turn_on/brightness |
- |
convert_power_divide_factor |
équipement a puissance variable | Le diviseur a appliquer pour convertir la puissance en valeur | 50 | Dans l'exemple, le service "number/set_value" sera appelé avec la consigne de puissance / 50 sur l'entité entity_id. Pour une Tesla sur une installation tri-phasée, la valeur est 660 (230 v x 3) ce qui permet de convertir une puissance en ampère. Pour une installation mono-phasé, mettre 230.Pour une entité light ou fan mettre la même valeur que dans le champ power_step |
Les exemples ci-dessus sont à adapter à votre cas.
Pour commander la recharge d'une voiture de type Tesla avec modulation de l'intensité de charge, si la batterie solaire est chargée à 50%, en tri-phasé avec recharge en heures creuses à partir de 23h00, voici les paramètres :
name: "Recharge Tesla"
entity_id: "switch.tesla_charger"
# 3 x 230 v
power_min: 690
# 18 x 230 v
power_max: 4140
power_step: 690
check_usable_template: "{{ is_state('input_select.charge_mode', 'Solaire') and is_state('binary_sensor.tesla_wall_connector_vehicle_connected', 'on') and is_state('binary_sensor.tesla_charger', 'on') and states('sensor.tesla_battery') | float(100) < states('number.tesla_charge_limit') | float(90) }}"
# 2 heures
duration_min: 120
# 15 min stop
duration_stop_min: 15
# Power management
power_entity_id: "number.tesla_charging_amps"
# 5 min
duration_power_min: 5
action_mode: "service_call"
activation_service: "switch/turn_on"
deactivation_service: "switch/turn_off"
change_power_service: "number/set_value"
convert_power_divide_factor: 690
battery_soc_threshold: 50
min_on_time_per_day_min: 300
offpeak_time: "23:00"En monophasé, remplacez les 690 par des 230. Vous devez adapter, la puissance maximale et le check_usable_template au minimum.
Pour allumer une climatisation si la température est supérieure à 27° :
name: "Climatisation salon"
entity_id: "climate.clim_salon"
device_power: 1500
check_usable_template: "{{ states('sensor.temperature_salon') | float(0) > 27 }}"
active_template: "{{ is_state('climate.vtherm', 'cool') }}"
# 1 h minimum
duration_min: 60
action_mode: "service_call"
activation_service: "climate/set_hvac_mode/hvac_mode:cool"
deactivation_service: "climate/set_hvac_mode/hvac_mode:off"Pour changer le preset d'une climatisation si la température est supérieure à 27° :
name: "Climatisation salon"
entity_id: "climate.clim_salon"
device_power: 1500
check_usable_template: "{{ states('sensor.temperature_salon') | float(0) > 27 }}"
active_template: "{{ is_state_attr('climate.clim_salon', 'preset_mode', 'boost') }}"
# 1 h minimum
duration_min: 60
action_mode: "service_call"
activation_service: "climate/set_preset_mode/preset_mode:boost"
deactivation_service: "climate/set_preset_mode/preset_mode:eco"Pour allumer un déhumidificateur si l'humidité dépasse un seuil pour au moins une heure par jour avec possibilité d'allumage en heures creuses :
name: "Dehumidification musique"
entity_id: "humidifier.humidifier_musique"
device_power: 250
# 1 h
duration_min: 60
duration_stop_min: 30
check_usable_template: "{{ states('sensor.humidite_musique') | float(50) > 55 }}"
action_mode: "service_call"
activation_service: "humidifier/turn_on"
deactivation_service: "humidifier/turn_off"
max_on_time_per_day_min: 180
min_on_time_per_day_min: 60
offpeak_time: "02:00"Pour allumer une lampe témoin de production disponible:
name: "Eclairage"
entity_id: "light.lampe_temoin_production"
device_power: 100
check_usable_template: "{{ True }}"
action_mode: "service_call"
activation_service: "light/turn_on"
deactivation_service: "light/turn_off"
offpeak_time: "02:00"Pour allumer une lampe témoin de production disponible:
name: "Eclairage dimmable"
entity_id: "light.shelly_dimmer"
power_min: 10
power_max: 100
# power_max / 255
power_step: 0.4
check_usable_template: "{{ True }}"
power_entity_id: "light.shelly_dimmer"
# 5 min
duration_power_min: 5
action_mode: "service_call"
activation_service: "light/turn_on/brightness:0"
deactivation_service: "light/turn_off"
change_power_service: "nlight/turn_on/brightness"
# même valeur que power_step
convert_power_divide_factor: 0.4
offpeak_time: "02:00"La configuration avancée permet de modifier la configuration de l'algorithme. Il n'est pas conseillé d'y toucher mais cette fonction reste disponible pour des besoins spécifiques. L'algorithme est un algorithme de type recuit simulé qui cherche des configurations (combinaisons de on/off) et procède à une évaluation d'une fonction de coût à chaque itération. A chaque itération, l'algorithme échange de façon aléatoire l'état de certains équipements et évalue la fonction de cout. Si l'évaluation est meilleure que la prédédente elle est gardée. Si elle est plus forte, elle peut être gardée en fonction d'une "température". Cette température va baisser au fur et à mesure des itérations ce qui va permettre de converger vers une solution quasi optimale.
Pour utiliser la configuration avancée, vous devez :
-
ajouter la ligne suivante dans votre
configuration.yaml:solar_optimizer: !include solar_optimizer.yaml -
et créez un fichier au même niveau que le
configuration.yamlavec les informations suivantes :
algorithm:
initial_temp: 1000
min_temp: 0.1
cooling_factor: 0.95
max_iteration_number: 1000Les paramètres influent de la manière suivante :
- initial_temp : la température initiale. Des valeurs de la fonction de coût jusqu'à 1000 sont acceptées dans les premières itération. Si vous avez des grosses puissances, ce paramètres peut être augmenter. Si vous n'avez que des petites puissances, il peut être baissé,
- min_temp : la temperature minimale. En fin de recherche de solution optimale, seulement des variations de 0.1 seront acceptées. Ce paramètre ne devrait pas être modifié,
- cooling_factor : à chaque itération la temperature est multipliée par 0,95 ce qui assure une descente lente et progressive. Mettre une valeur plus petite, va forcer l'algorithme a converger plus vite au détriment de la qualité de la solution. Une solution moins bonne sera trouvée plus vite. A l'inverse, mettre une valeur plus forte (et strictement inférieure à 1) va engendrer des temps de calcul plus long, mais la solution sera meilleure.
- max_iteration_number : le nombre maximal d'itérations acceptables. Mettre en nombre plus faible peut dégrader la qualité de la solution mais va raccourcir le temps de calcul si aucune solution stable n'est trouvée.
Les valeurs par défaut conviennent à des configurations avec une vingtaine d'équipements (donc avec beaucoup de possibilités). Si vous n'avez que quelques équipements, disons moins de 5, et pas d'équipements avec une puissance variable, vous pourriez utiliser ce jeu de paramètres (non testés) :
algorithm:
initial_temp: 1000
min_temp: 0.1
cooling_factor: 0.90
max_iteration_number: 300Vous ne devriez pas constater de différence dans la qualité des solutions trouvées mais l'algorithme ira plus vite et sera beaucoup moins gourmand en ressources CPU. Tout changement dans la configuration avancée nécessite un arrêt / relance de l'intégration (ou de Home Assistant) pour être pris en compte.
L'intégration, une fois correctement configurée, créée un appareil (device) nommé 'configuration' qui contient plusieurs entités :
- un sensor nommé "total_power" qui est le total de toutes les puissances des équipements commandés par Solar Optimizer,
- un sensor nommé "best_objective" qui est la valeur de la fonction de coût (cf. fonctionnement de l'algo). Plus la valeur est faible et plus la solution trouvée est bonne,
- un sensor nommé "power_production" qui est la dernière valeur de la production solaire lissée (si l'option a été choisie) prise en compte,
- un sensor nommé "power_production_brut" qui est la dernière valeur de la production solaire brute prise en compte.
- une liste de choix nommé "Priority weight" qui est le poids donné à la gestion de la priorité par rapport à l'optimisation de la consommation solaire. Cf. la gestion de la priorité
La reconfiguration de cet appareil permet de configurer Solar Optimizer.
- un switch nommé
switch.enable_solar_optimizer_<name>. Si le switch est "Off", l'algorithme ne considérera pas cet équipement pour le calcul. Ca permet de manuellement sortir un équipement de la liste sans avoir à modifier la liste. Ce switch contient des attributs additionnels qui permettent de suivre l'état interne de l'équipement vu de l'algorithme, - un sensor nommé
sensor.on_time_today_solar_optimizer_<name>qui donne la durée d'activation depuis la remise à zéro (cf. raz_time) - un switch nommé
switch.solar_optimizer_<name>qui reflète l'état d'activation demandé par Solar Optimizer - une liste de choix nommé "Priority" qui est la priorité de cet appareil. Les valeurs possibles vont de 'Very low' à 'Very high'. Cf. la gestion de la priorité
Ce dernier switch possède des attributs consultables via Outils de developpement / Etats :
is_enabled: true si l'appareil est autorisé par l'utilisateur dans le calcul,is_active: true si l'appareil est actif,is_usable: true si l'appareil peut être utilisé par l'algorithme,can_change_power: true si la puissance peut être adaptée,current_power: la puissance courante de l'appareil,requested_power: la puissance demandée par Solar Optimizer,duration_sec: la durée d'allumage en secondes,duration_power_sec: la durée d'un changement de puissance en secondes,next_date_available: à quelle date et heure l'équipement sera de nouveau disponible pour l'algorithme,next_date_available_power: à quelle date et heure le changement de puissance de l'équipement sera de nouveau disponible pour un changement,battery_soc_threshold: l'état de charge minimal de la batterie solaire pour que l'équipement soit utilisable par l'algorithme,battery_soc: l'état de charge courant de la batterie solaire.
D'un point de vue de l'utilisateur vous devez fournir 2 valeurs :
- le poids de la priorité (
priority weight) par rapport à l'optimisation de la consommation solaire. En effet, ces 2 notions sont contradictoires : optimiser la consommation de la production est contraire à prioriser certains équipements par rapport à d'autres. Si un équipement est privilégié alors il sera allumé plus souvent ce qui peut avoir pour effet de dégrader l'optimisation de la consommation. Cet attribut est disponible dans l'appareil nommé 'Configuration' sous la forme d'une entité de typeselect. - la priorité de chaque équipement. Cette priorité est une liste de choix entre 5 valeurs de 'Very low' à 'Very high'. Plus la priorité va vers 'Very high' et plus l'équipement sera démarré par l'algorithme. Cet attribut est disponible dans l'appareil de l'équipement sous la forme d'une entité de type
select.
Plus la valeur est élevé et plus la priorité sera prise en compte par l'algorithme au détriment de l'optimisation. La valeur None permet de désactiver totalement la gestion de la priorité. L'optimisation de la consommation de la production solaire est alors maximale.
Plus la priorité est élevée et plus l'équipement sera sollicité par l'algorithme au détriment des autres de priorité plus faible.
Notes
- la priorisation d'équipements par rapport à d'autres peut dégrader l'optimisation de la consommation de la production solaire. Il est donc normal d'avoir du surplus non consommé si vous utilisez les priorités. Vous pouvez régler le dégré de prise en charge de $la priorité en réglant le poids de la priorité
- la priorité n'est pas absolue : il est tout à fait possible d'avoir un équipement de moindre priorité d'activé alors qu'un plus prioritaire n'est pas activé. Ca dépend de la consommation de chaque équipement, de la puissance disponible, des durées d'allumage de chaque équipement, ... Bref, rien n'interdit ce cas de figure. Si il se produit trop souvent, vous pouvez régler plus finement la priorité de l'équipement ou de la poids de la priorité dans l'algorithme, comme expliqué ci-dessus.
Solar Optimizer produit des évènements à chaque allumage ou extinction d'un appareil. Cela vous permet de capter ces évènements dans une automatisation par exemple.
solar_optimizer_state_change_event : lorsqu'un équipement change d'état. Le contenu du message est alors le suivant :
event_type: solar_optimizer_state_change_event
data:
action_type: [Activate | Deactivate],
requested_power: <la nouvelle puissance demandée si disponible>,
current_power: <la puissance demandée si disponible>,
entity_id: <l'entity_id de l'appareil commandé>,
solar_optimizer_change_power_event : lorsqu'un équipement change de puissance. Le contenu du message est alors le suivant :
event_type: solar_optimizer_state_change_event
data:
action_type: [ChangePower],
requested_power: <la nouvelle puissance demandée si disponible>,
current_power: <la puissance demandée si disponible>,
entity_id: <l'entity_id de l'appareil commandé>,
solar_optimizer_enable_state_change_event : lorsque le switch enable d'un équipement change d'état. Le contenu du message est alors le suivant :
event_type: solar_optimizer_enable_state_change_event
data:
device_unique_id: prise_vmc_garage
is_enabled: false
is_active: true
is_usable: false
is_waiting: true
Vous pouvez contrôler la réception et le contenu des évènements dans Outils de développement / Evènements. Donnez le nom de l'évènement à écouter :
Un exemple d'automatisation qui écoute les évènements :
alias: Gestion des events de Solar Optimizer
description: Notifie les modifiations de status de Solar Optimizer
mode: parallel
max: 50
triggers:
- event_type: solar_optimizer_change_power_event
id: power_event
trigger: event
- event_type: solar_optimizer_state_change_event
id: state_change
trigger: event
conditions: []
actions:
- choose:
- conditions:
- condition: trigger
id: power_event
sequence:
- data:
message: >-
{{ trigger.event.data.action_type }} pour entité {{
trigger.event.data.entity_id}} avec requested_power {{
trigger.event.data.requested_power }}. (current_power is {{
trigger.event.data.current_power }})
title: ChangePower Event de Solar Optimizer
enabled: false
action: persistent_notification.create
- if:
- condition: template
value_template: >-
{{ trigger.event.data.entity_id == switch.cloucloute_charger
}}
then:
- data:
message: On demande a changer la puissance de Cloucloute
title: Changement de puissance
notification_id: cloucloute-power-change
action: persistent_notification.create
- data:
value: >-
{{ (trigger.event.data.requested_power | float(0) / 660) |
round(0) }}
target:
entity_id: number.cloucloute_charging_amps
action: number.set_value
- conditions:
- condition: trigger
id: state_change
sequence:
- data:
message: >-
{{ trigger.event.data.action_type }} pour entité {{
trigger.event.data.entity_id}} avec requested_power {{
trigger.event.data.requested_power }}. (current_power is {{
trigger.event.data.current_power }})
title: StateChange Event de Solar Optimizer
action: persistent_notification.createSolar Opitmizer propose des actions qui permettent d'interagir avec SO. Les actions sont utilisables à travers les Outils de dev / Actions et aussi à travers des automatisations.
Cette action permet de remettre à zéro le temps d'allumage d'un équipement. Pour l'utiliser, allez dans Outils de dev / Actions, tapez Solar optimizer et vous verrez l'action reset_on_time. Sélectionnez là, choisissez le ou les appareils concernés sur lesquels appliquer l'action et appuyez sur 'Exécutez l'action'.
Vous devez obtenir quelque-chose comme ça :
En mode yaml vous devez obtenir ça :
action: solar_optimizer.reset_on_time
target:
device_id: 825afe5fcee088d82d024f5f925cdb3e
data: {}Après avoir lancé l'action, le temps d'allumage est remis à 0 ce qui peut autoriser l'algorithme a reprendre l'appareil en considération.
Votre installation peut nécessiter de créer des capteurs spécifiques qui doivent être configurer ici. Les règles sur ces capteurs sont importantes et doivent être scrupuleusement respectées pour un bon fonctionnement de Solar Optimizer. Voici mes templates de capteurs (valable pour une installation Enphase uniquement):
Fichier configuration.yaml :
template: !include templates.yaml
Fichier templates.yaml :
- sensor:
- name: "Total puissance produite instantanée (W)"
icon: mdi:solar-power-variant
unique_id: total_power_produite_w
device_class: power
unit_of_measurement: "W"
state_class: measurement
state: >
{% set power = [states('sensor.envoy_xxxxx_current_power_production') | float(default=0), 0] | max %}
{{ power | round(2) }}
availability: "{{ is_number(states('sensor.envoy_xxxxx_current_power_production')) }}"
- name: "Total puissance consommée net instantanée (W)"
unique_id: total_power_consommee_net_w
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{%- set power_net = states('sensor.envoy_xxxxx_current_net_power_consumption') | float(default=0) -%}
{{ power_net }}
availability: "{{ is_number(states('sensor.envoy_xxxxx_current_net_power_consumption')) }}"
A adapter à votre cas bien sûr.
En complément, les codes Lovelace suivant permet de controller chaque équipement déclaré. Les étapes à suivre sont :
- Avec HACS, installez les plugins nommés
streamline-card,expander-cardetmushroom-templatesi vous ne les avez pas déjà, - Installez les templates pour
streamlineen tête de votre code Lovelace, - Installez une carte par équipement géré par Solar Optimizer qui référence le template `streammline``
Lisez la documentation du plugin ici pour vous familiariser avec cet excellent plugin.
Suivez la procédure d'installation qui consiste à installer un nouveau dépôt Github de type Dashboard et à installer le plugin.
Vous devez avoir dans la partie "Téléchargé" vos plugins de visibles :
Faites de même avec les plugins expander-card et mushroom-template.
Pour installer les templates vous devez aller sur votre dashboard, vous mettre en édition et cliquer sur les trois points dans le menu en haut à droite :
puis
puis
Vous arrivez alors en édition manuelle de votre dashboard Lovelace.
Attention : le yaml est susceptible. L'indentation doit être scrupuleusement respectée.
Copier/coller le texte ci-dessous (cliquez sur le bouton copier pour tout prendre sans risque) tout au début 1 ligne, 1 colonne.
# A mettre en début de page sur le front
streamline_templates:
managed_device_power:
default: null
card:
type: custom:expander-card
expanded: false
title-card-button-overlay: true
title-card:
type: custom:mushroom-template-card
primary: '{{ state_attr(''[[device]]'', ''device_name'') }}'
secondary: >-
[[secondary_infos]] ({{ state_attr('[[on_time_entity]]',
'on_time_hms') }} / {{ state_attr('[[on_time_entity]]',
'max_on_time_hms')}} )
icon: '[[icon]]'
badge_icon: >-
{% if is_state_attr('[[on_time_entity]]','should_be_forced_offpeak',
True) %}mdi:power-sleep{% elif
is_state_attr('[[device]]','is_enabled', True) %}mdi:check{% else
%}mdi:cancel{% endif %}
badge_color: >-
{% if is_state_attr('[[on_time_entity]]','should_be_forced_offpeak',
True) %}#003366{% elif is_state_attr('[[device]]', 'is_usable', True)
and is_state_attr('[[device]]', 'is_enabled', True) %}green {% elif
is_state_attr('[[device]]', 'is_enabled', False) %}red {% elif
is_state_attr('[[device]]','is_waiting', True) %}orange {% elif
is_state_attr('[[device]]', 'is_usable', False) or
state_attr('[[device]]', 'is_usable') is none %}#A0B0FF{% else
%}blue{% endif %}
entity: '[[device]]'
icon_color: >-
{% if is_state('[[device]]', 'on')%}orange{% else %}lightgray{% endif
%}
tap_action:
action: toggle
hold_action:
action: more-info
double_tap_action:
action: none
cards:
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: '[[enable_entity]]'
double_tap_action:
action: more-info
tap_action:
action: toggle
hold_action:
action: more-info
icon_color: green
content_info: name
- type: markdown
content: >-
**Prochaine dispo** : {{ ((as_timestamp(state_attr('[[device]]',
'next_date_available')) - as_timestamp(now())) / 60) | int }}
min<br> **Prochaine dispo puissance**: {{
((as_timestamp(state_attr('[[device]]',
'next_date_available_power')) - as_timestamp(now())) / 60) | int }}
min<br> **Utilisable** : {{ state_attr('[[device]]', 'is_usable')
}}<br> **Est en attente** : {{ state_attr('[[device]]',
'is_waiting') }}<br> **Est forcé en heures creuses** : {{
state_attr('[[on_time_entity]]', 'should_be_forced_offpeak') }}<br>
**Heures creuses** : {{ state_attr('[[on_time_entity]]',
'offpeak_time') }}<br> **Puissance requise** : {{
state_attr('[[device]]', 'requested_power') }} W<br> **Puissance
courante** : {{ state_attr('[[device]]', 'current_power') }} W
title: Infos
- type: history-graph
hours: 24
entities:
- entity: '[[device]]'
- entity: '[[enable_entity]]'
- entity: '[[power_entity]]'
managed_device:
default: null
card:
type: custom:expander-card
expanded: false
title-card-button-overlay: true
title-card:
type: custom:mushroom-template-card
primary: '{{ state_attr(''[[device]]'', ''device_name'') }}'
secondary: >-
[[secondary_infos]] (max. {{ state_attr('[[device]]', 'power_max') }}
W - {{ state_attr('[[on_time_entity]]', 'on_time_hms')}} / {{
state_attr('[[on_time_entity]]', 'max_on_time_hms')}} )
icon: '[[icon]]'
badge_icon: >-
{% if is_state_attr('[[on_time_entity]]','should_be_forced_offpeak',
True) %}mdi:power-sleep{% elif
is_state_attr('[[device]]','is_enabled', True) %}mdi:check{% else
%}mdi:cancel{% endif %}
badge_color: >-
{% if is_state_attr('[[on_time_entity]]','should_be_forced_offpeak',
True) %}#003366{% elif is_state_attr('[[device]]', 'is_usable', True)
and is_state_attr('[[device]]', 'is_enabled', True) %}green {% elif
is_state_attr('[[device]]', 'is_enabled', False) %}red {% elif
is_state_attr('[[device]]','is_waiting', True) %}orange {% elif
is_state_attr('[[device]]', 'is_usable', False) or
state_attr('[[device]]', 'is_usable') is none %}#A0B0FF{% else
%}blue{% endif %}
entity: '[[device]]'
icon_color: >-
{% if is_state('[[device]]', 'on')%}orange{% else %}lightgray{% endif
%}
tap_action:
action: toggle
hold_action:
action: more-info
double_tap_action:
action: none
cards:
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: '[[enable_entity]]'
double_tap_action:
action: more-info
tap_action:
action: toggle
hold_action:
action: more-info
icon_color: green
content_info: name
- type: markdown
content: >-
**Prochaine dispo** : {{ ((as_timestamp(state_attr('[[device]]',
'next_date_available')) - as_timestamp(now())) / 60) | int }}
min<br> **Utilisable** : {{ state_attr('[[device]]', 'is_usable')
}}<br> **Est en attente** : {{ state_attr('[[device]]',
'is_waiting') }}<br> **Est forcé en heures creuses** : {{
state_attr('[[on_time_entity]]', 'should_be_forced_offpeak') }}<br>
**Heures creuses** : {{ state_attr('[[on_time_entity]]',
'offpeak_time') }}<br> **Puissance requise** : {{
state_attr('[[device]]', 'requested_power') }} W<br> **Puissance
courante** : {{ state_attr('[[device]]', 'current_power') }} W
- type: history-graph
hours: 24
entities:
- entity: '[[device]]'
- entity: '[[enable_entity]]'
- entity: '[[power_entity]]'Vous devez avoir une page qui ressemble à ça :
Cliquez alors sur Enregistrer puis Terminer. Les templates sont maintenant installés, il ne reste plus qu'à les utiliser.
Pour utiliser les templates installés à l'étape précédente, vous devez :
- Editer un dashboard ou vous voulez ajouter la carte,
- cliquer sur 'Ajouter une carte' en bas à droite,
- sélectionner la carte nommée Streamline Card comme ceci :
- remplir les champs de la façon suivante :
Vous devez choisir le template managed_device pour un équipement non muni d'une modulation de puissance ou managed_device_power sinon.
Saisissez ensuite les différents attributs.
Un exemple complet pour un équipement 'non power' :
et pour un équipement avec modulation de puissance :
Vous obtiendrez alors un composant permettant d'interagir avec l'équipement qui ressemble à ça :
La carte ainsi obtenue permet de voir l'état d'utilisation de l'équipement et d'interagir avec lui. Ouvrez la carte en appuyant sur le 'V' et vous obtenez ça :
| Couleur | Signification | Exemple |
|---|---|---|
| Gris | Equipement éteint |  |
| Jaune | Equipement allumé |  |
| Icone / Couleur | Signification | Exemple |
|---|---|---|
| Coche verte | Equipement éteint en attente de production |  |
| Coche bleue | Equipement éteint non disponible (check-usable renvoie faux) |
 |
| Coche orange | Equipement éteint en attente du délai enttre 2 |  |
| Annulation rouge | Equipement éteint non autorisé par l'utilisation enable est faux |
 |
| Lune Bleu nuit | Equipement allumé en heures creuses |  |
Cliquez sur la carte de l'équipement et ça forcera son allumage ou son extinction.
Cliquez sur le bouton Enable et ça autorisera ou non l'utilisation de l'équipement par l'algorithme de Solar Optimizer.
Si vous souhaitez contribuer, veuillez lire les directives de contribution