Regarde la doc sur l’utilisation d’un climate. Tu dois absolument mettre un template d’activation et personnaliser les commandes d’allumage/extinction pour que SO sache quand ton équipement doit être considéré comme actif et comment l’allumer et l’éteindre. C’est là: solar_optimizer/README-fr.md at main · jmcollin78/solar_optimizer · GitHub
Et tu peux supprimer ton input_boolean du coup.
merci mais pas mieux:
maintenant c’est l’inverse, il est allumé par défaut dans SO (mais pas en réel) il faut l’éteindre puis le rallumer pour que ça fonctionne.
une idée?
Bonjour à tous,
J’avais utilisé cette intégration il y a plusieurs mois pour contrôler mon chauffe eau. Depuis j’ai installé un routeur solaire, donc je l’avais désactivé.
Avec le retour des beaux jours et d’un export que j’aimerai optimisé je me suis dis que j’allais pouvoir recharger ma voiture électrique. Pour cela, j’ai une prise Legrand GreenUp qui me permet de charger jusqu’à 16A. Cette prise est contrôlée par un contacteur qui est activé / désactivé via un Shelly Pro EM (qui mesure également la consommation de la prise). J’ai branché sur la prise un chargeur dont l’intensité peut être réglable, j’ai mis 13A.
J’ai configuré l’intégration comme ceci :
Ensuite j’ai programmé la charge de la voiture comme cela (les champs du bas ne sont pas remplis)
Le problème c’est que la prise est arrêté alors qu’il y a largement de quoi l’alimenter avec le surplus, et je pense que ça me coûterai donc moins cher de charger la voiture que de revendre l’énergie, et je ne comprends pas pourquoi.
Voici mes différents graphiques de Solar Optimizer :
On voit que j’ai dû allumer la prise manuellement.
Je peux fournir d’autres infos ou log au besoin 
Merci d’avance et merci pour cette super intégration
Il ne faut pas mettre les « dans le template d’activation. Y’a des exemples dans le texte !
Ton template d’utilisabilité. Pas sûr que ce soit ça que tu voulais faire. Mets {{ True}}. Sinon tu dis à SO de ne pas l’utiliser qd ça ne charge pas.
Ton entity_id c’est le switch à commander ? Bizarrement il s’appelle consommation
Hello!
merci c’est bien ça, j’avais bêtement copier/coller ton exemple sur git.
merci!
@Jean-Marc_Collin , je teste depuis plus d’une semaine maintenant la nouvelle option du capteur batterie entrée négatif et sortie +. Je ne comprends pas trop l’intérêt, pourquoi tu a implémenté ça ?
Mon but est, par ordre de priorité :
1: renvoyer le moins possible dans le réseau enedis gratuitement…
2: chauffer mon ballon d’eau chaude
3: charger ma batterie autant que possible avec tout le surplus disponible…
4: …et s’il reste encore du surplus, allumer des équipements style des ventilateurs/clim ou autres juste pour « consommer »
Or, depuis que j’ai renseigné le champ d’entrée sortie dans la batterie, les équipements qui sont censés juste aller consommer le « surplus » se mettent en route très fréquemment, même si la puissance de charge max de la batterie n’est pas utilisée. Je préfèrerais mettre cette puissance prioritairement dans la batterie.
Donc, pourquoi cette option ? Et comment puis-je y remédier pour mon cas exposé ci-dessus ?
Hello @pacostef57 ,
Si tu n’as pas besoin de l’option, ben ne l’utilise pas. Elle n’est pas obligatoire.
Elle permet de considérer la charge de la batterie (en W) comme une puissance disponible pour les équipements.
Si il y a 2000 watts qui vont charger la batterie, tu pourrais très bien préférer activer tes équipements avec ces 2000 watts au lieu de charger la batterie.
Donc ça créé une sorte de priorité comme ça :
Mais t’es vraiment pas obligé de l’utiliser.
avec ta logique : ballon d’eau chaude first et ensuite charger la batterie. Tu devrais au contraire en avoir besoin. Si la batterie charge, SO va l’utiliser pour allumer ou le ballon.
Ce qui n’est pas possible c’est de faire 4. avec tout le reste... c’est soit la batterie est prioritaire soit elle ne l’est pas.
Donc si tu configures la puissance nette de la batterie tu as les priorités suivantes:
Si tu ne le mets pas tu as :
En passant:
4: …et s’il reste encore du surplus, allumer des équipements style des ventilateurs/clim ou autres juste pour « consommer »
j’aime pas du tout. Allumer des équipements juste pour cramer de l’électricité c’est le contraire d’une démarche éco et tu vas user tes équipements pour rien. Mais ca te regarde.
Merci pour ta réponse assez complète.
En fait, avec les templates qui renvoient « true », on peut se créer des règles de priorité , c’est que je fais de manière simple. Tu ne cite pas cette possibilité qu’offrent les templates.
Par exemple je fais actuellement:
1: Priorité au chauffe eau, aucune condition , toujours « true », minimum 2h30 par jour et max 3h par jour. Allumage minimum pendant 1h15 (ce qui suffit la plupart du temps pour qu’il coupe la chauffe de lui-même car assez chaud). Et si on a tiré toute l’eau chaude du ballon, il aura souvent un deuxième allumage par SO, encore une fois de 1h15 minimum, ce qui l’aura la plupart du temps entièrement chauffé aussi.
2: Priorité ensuite à la charge de la batterie pour qu’elle soit pleine en soirée, quitte à ce que les équipements qui suivent ne se déclenchent pas, car j’estime que c’est « uniquement en cas de grosse production solaire, pour un confort supplémentaire »
Pour cela, je mets des templates d’utilisabilité qui renvoie « true » comme suit:
-Si mon chauffe eau a une conso instantanée de moins de 2000(W) (1ère preuve, mais pas suffisante, qu’il a déjà chauffé), et que ma batterie est pleine à 95(%) (deuxième preuve, mais pas suffisante), et que le courant de charge est inférieur à 530(W) (qui veut dire qu’en fin de charge elle n’accepte plus de rentrer plus de courant que cette valeur), et également qu’elle ne soit pas en train de décharger du courant vers la maison, alors seulement, j’accepte d’allumer la clim, les ventilateurs… Ce n’est pas très « creusé » comme solution, vu mon petit niveau, il y a forcément moyen de faire ça mieux, mais ça fonctionne vraiment bien et correspond la plupart du temps au résultat attendu.
Je suis un peu « extrême » certes quand je dis « consommer » juste pour ne pas réinjecter vers le réseau. C’est quand même utile pour le confort. Par contre, je lis un peu partout que les conditions vont se durcir dans pas très longtemps concernant le solaire « pas cher » ou plug&play, ainsi que les batteries type zendure, Anker , ce que j’utilise. Forcément avec ces systèmes (inférieurs à 3kWh, posé au jardin, pour être ok avec le CACSI, comme mon cas, on réinjecte de l’excédent vers le réseau). Pour l’instant c’est plutôt bien toléré mais ça ne va pas durer…des choses se mijotent.
Forcément on est en France… et quoi de mieux que d’aller taper sur les doigts des petits particuliers aux petits moyens, qui veulent économiser autant que possible, que de durcir/changer les règles, interdir ceci cela. Les linky savent tout ce qui rentre ou sort de la maison…le jour ou on dira stop aux réinjections des surplus solaires dans le réseau gratos, les tout petits budgets comme moi (matos materfrance, 2kWh, avec système zendure, pour 1900€) ben on pourra oublier les économies possibles avec un système très abordable).
Ça doit pas plaire, ni faire les affaires de certains, que l’on paie beaucoup moins cher sa facture d’électricité?!
Les plus aisés eux pourront continuer sans soucis financier, en adaptant (sous entendu passage à la caisse) selon les conditions qui seront pondues, par exemple mise en conformité des instals, paier un consuel, etc… Désolé pour le « petit coup de gueule du dimanche 
»
Hello,
Je suis un peu perdu suit a la migration V2 > V3…
J’ai le message suivant:
Cette erreur provient d'une intégration personnalisée
Enregistreur: custom_components.solar_optimizer.coordinator
Source: helpers/update_coordinator.py:380
intégration: Configuration de Solar Optimizer (documentation, problèmes)
S'est produit pour la première fois: 11:11:45 (3 occurrences)
Dernier enregistrement: 11:14:43
Unexpected error fetching Solar Optimizer data
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 380, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solar_optimizer/coordinator.py", line 112, in _async_update_data
device.set_current_power_with_device_state()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/config/custom_components/solar_optimizer/managed_device.py", line 321, in set_current_power_with_device_state
amps = self._hass.states.get(self._power_entity_id)
File "/usr/src/homeassistant/homeassistant/core.py", line 2156, in get
entity_id.lower()
^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'lower'
Du coup, le best_objective., power _production,… tout est indisponible?
Que faire?
Bonjour,
as-tu suivi la procédure de migration indiqué dans les releases notes ?
Hello, oui tout enlever et tout recommencer depuis zero, ce qui est étonnant c’est que lorsque je n’est pas d’injection solaire dans le réseau donc un consommation du réseau c’est ok? les valeur sont disponibles
Finalement, c’est tout bon, j’ai tout enlevé, redémarrer le serveur et tout remis…
Désolé pour le délais de réponse, je n’ai pas reçu la notif de réponse au topic …
Mon template d’utilisabilité est le suivant : je veux utiliser la prise uniquement si la prise est branchée côté voiture. Donc si la voiture est bien branchée mon is_state passe à True
Pour l’entity_id oui c’est bien le switch à commander. Il s’appelle en effet « consommation » car c’est le switch (contact sec) associé au Shelly pro EM qui mesure également la conso de la prise, je n’ai pas renommé le switch.
Salut @Jean-Marc_Collin
J’utilise SO depuis quelques semaines maintenant et c’est génial de pouvoir faire des économies ! Je ne sais plus si je l’ai dit avant donc merci pour cette intégration !
J’ai commencé par connecter la pompe de ma piscine, puis mon chauffe-eau (c’est là que les économies sont les plus importantes).
Je souhaite désormais connecter ma voiture électrique mais je me heurte à un souci : SO considère que la voiture est tout le temps « on » alors que ce n’est pas le cas.
Voici ma configuration :
Utilisabilité :
{{is_state('binary_sensor.cooper_se_connection_status','on') and not is_state('sensor.cooper_se_charging_status','finished_fully_charged')}}
Activation :
{{is_state('select.cooper_se_charging_mode','immediate_charging')}}
Donc je considère qu’elle est utilisable quand elle est branchée et que sa batterie n’est pas full.
Elle est ‹ on › quand son mode de chargement est « immediate_charging » et ce template est bien faux actuellement :
Et pourtant, avec un ‹ reset on time › effectué à 5h tous les matins, à 9h, elle est déjà ‹ on › depuis bientôt 4h… Et quand arrive le soleil pour la recharger, SO considère qu’elle a déjà assez chargé 
Qu’est-ce qui ne va pas ici ? Je n’ai pas le problème avec les autres équipements. La seule différence que je vois, c’est le fait que j’utilise des templates ici et pas pour les autres équipements.
Merci d’avance pour ton retour.
Bonne journée !
Hello,
Si c’est comme sur la mienne, tu dois juste enlever le template activation.
Elle est toujours en ‹ immediate charging › même si elle ne charge pas. C’est le mode de charge ‹ immédiat › ou ‹ différé › mais ca ne dit pas que ca charge.
Et comme c’est un switch pour démarrer/stopper la charge tu n’as rien besoin de mettre dans le templace d’activation.
Alors non, elle est toujours en « wait for charging » pour charger sur les heures creuses (programme interne du véhicule). C’est SO qui doit la passer en « immediat_charging ».
→ Mon erreur est peut-être là ? Il faut que je retire le programme de recharge et que je mette tout le temps « immédiat » ? J’ai juste peur que SO ne déclenche pas la recharge la nuit sur heures creuses et que je me retrouve sans charge le lendemain 
Salut à tous,
Avec les beaux jours qui devraient enfin arriver sous peut, je souhaite pouvoir faire fonctionner le pilotage de mes Chauffe Eaux via SO, mais j’ai beaux essayer et vérifier ma configuration, ça ne fonctionne pas et je ne vois rien dans la doc qui puisse m’orienter à résoudre mon problème
Question configuration générale, je sais qu’en principe c’est ok car j’ai déjà échangé à ce sujet.
Par contre pour mon équipement, que j’ai en double car 2 CE mais pas de la même puissance, voici ce que j’ai mis
Pour info, je pilote une entité de type light
A mon avis le problème doit venir de ce côté et du coup surement du Template d'utilisabilité {{ True }} et des Service d’activation et d’extinction, mais je n’ai rien trouver sur ce qu’il faut que je configure.
Voici les info de mon entité
Est-ce que quelqu’un peut m’aider ?
Merci par avance
Salut !
La v3.1 introduit le contrôle des entités de type Light donc ça devrait pas poser de problème. Je n’en utilise pas donc je ne pourrais pas t’aider. Tu es bien dans la v3.1 minimum ?
Et en relisant le doc je pense que le service d’activation et de désactivation doivent être adaptés pour les entités de type Light
Bonne journée
Hello @Yoyouri
Pour les entités de type light il faut personnalisé les services d’activation et de désactivation.
switch/turn_on ne fonctionne pas pour des lights. Il faut mettre light/turn_on je suppose (jamais essayé).
Il te faudra aussi personnalisé le template d’activation qui calcule si l’équipement est allumé par quelque-chose comme:
{{ is_state('light.xxxx', 'on') }}
à vérifier dans Development Tools / Modeles.
