J’ai le même problème que toi et je l’ai signalé il y a quelques semaines dans ce post
Jean Marc, effectivement, tu m’a déjà parlé de ce fonctionnement, mais ce n’est pas logique car tout le monde sait que l’énergie Solaire est forcément moins couteuse que l’énergie du réseau et ça n’a aucun intéret même si c’est pour quelques Watts et quelques minutes de consommer depuis le réseau !
Surtout que SO n’a aucun moyen de savoir s’il y aura le surplus suffisant ou non plus tard dans la journée.
Après oui on peut gruger sur les valeurs des couts de l’énergie en achat et en vente, mais du coup on aura des données incohérentes dans SO ce qui va à l’encontre des capteurs créés.
L’incohérence est d’après moi sur l’imposition de prendre en compte ces coûts d’énergie alors que comme j’ai pu l’indiqué précédemment pour des charges à puissances fixe, un fonctionnement juste sur Y a t-il assez de surplus ?, OUI ou NON alors CHARGE ON ou CHARGE OFF serait plus que suffisant !
toujours cette vieille rengaine. Je comprends mais encore une fois, c’est pas l’objectif de SO. Une simple automatisation permet de faire ce que tu veux.
Si vous voulez vraiment n’avoir aucun achat depuis le réseau, mettez 10 pour le cout d’achat et 0.1 pour le cout de revente. Ca devrait régler votre problème.
Personnellement, si j’ai un peu de batterie disponible, je préfère allumer le chauffe-eau et importer 500 w (depuis la batterie donc) plutot que de revendre 1500 w. Lorsque le prix de revente va passer à 4cts vous comprendrez tout l’intérêt. SO essaye de n’avoir ni import ni export, la proportion étant gérer par les couts de chaque.
L’objectif de lisser la production c’était d’éviter que tout s’éteigne lorsqu’un nuage passe devant le soleil.
C’est une moyenne mobile de la production.
Mais finalement, la production solaire n’est pas utilisée dans le calcul donc ca n’a pas d’impact. La consommation nette suffit. Ca reviendra peut être un jour donc essayez de garder des capteurs cohérents.
Ok, mais dommage au vu de son Nom et sa Description !
Oui en effet, mais une intégration permet d’avoir plus de contrôle en théorie et surtout permet d’intégrer facilement des infos sur son tableau de bord qui sont utile (cumul de fonctionnement bouton de déclenchement et d’arrêt, des cartes créés et ou adaptées…)
Certes via une Automatisation ça doit être possible, mais ça reste de ce que j’arrive à gérer sur HA compliqué par rapport à une intégration qui donne déjà ces infos
Ca serait intéressant de faire un paragraphe à ce sujet dans la doc pour les suivants, mais comme dit précédemment, du coup le calcul sur le Best Objective est erroné
au contraire, pour ceux qui ont un tarif de vente à 4c€, ils ont intérêts d’autoconsommer un max et sans faire tourner le réseau et du coup le fonctionnement à cheval Surplus et Réseau en simultané sera contre productif pour eux car leur charge aura fonctionnée en partie sur le réseau et sera sûrement à l’arrêt par son régulateur (thermostat pour un chauffe-eau) alors qu’il y a de forte chance qu’il y ai assez de surplus.
Pour ta batterie, j’ai du mal à comprendre car en toute logique au début journée et donc de la production solaire, celle-ci va demander de charger au lieu de faire fonctionner d’autre charge !
Après oui je suis d’accord pour la fin de journée
Mais pour moi le problème de fonctionnement Surplus + Réseau est réellement problématique que le matin car je vois bien dans mes courbes de production que celle-ci est suffisante quelques dizaine de minute après que les charges soient activé et du coup elles ont fonctionnés sur le réseau pour rien
Ne sachant pas si le fonctionnement est celui attendu ou non, j’ai entrepris de faire une modification dans ton code du fichier « managed_device.py ».
Si jamais, la voici :
Fonction d’origine :
def reset_next_date_available_power(self):
"""Incremente the next availability date for power change to now + _duration_power_sec"""
self._next_date_available_power = self.now + timedelta(
seconds=self._duration_power_sec
)
_LOGGER.debug(
"Next availability date for power change for %s is %s",
self._name,
self._next_date_available_power,
)
Fonction modifiée
def reset_next_date_available_power(self):
"""Incremente the next availability date for power change to now + _duration_power_sec"""
self._next_date_available_power = self.now + timedelta(
seconds=self._duration_power_sec
)
_LOGGER.debug(
"Next availability date for power change for %s is %s",
self._name,
self._next_date_available_power,
)
"""Lors d'un changement de puissance, si _next_date_available ne respect pas
le temps min de puissance, on le remet à jour pour assusrer un temps min à la
nouvelle puissance avant de pouvoir autoriser une coupure"""
if self._next_date_available <= self._next_date_available_power:
self._next_date_available = self._next_date_available_power
_LOGGER.info(
"Mise à jour de Next availability date suite au changmement de puissance %s is %s",
self._name,
self._next_date_available,
)
J’ai testé, et le fonctionnement est bien celui que j’attend.
Maintenant que tout est OK de mon côté, j’arrête de spammer la discution et de t’embêter
Excellent. Oui c’est pas bête du tout, tu assures ainsi un temps pour la nouvelle puissance.
Je vais voir comment ça se comporte sur les tests et je prends si il n’y a pas trop d’impacts. A vue de nez, ca me parait bien en tout cas.
