J’essaye de programmer la valeur du courant max de charge de la batterie mais cette valeur est écrasée ensuite par Venus os. J’ai la preuve avec MQTT explorer que l’on arrive bien à écrire dans le register, mais Venus OS reprogramme à la valeur max systématiquement après un certain temps.
J’ai le venus os version 3.34
La première lecture à 2 A est provoquée par ma programmation.
La deuxième lecture à 10A a été provoquée par la réécriture de par Venus OS., car aucune autre écriture par mon programme à été faite. (vérifié avec l’explorer)
Comment contourner ce problème?
Merci pour cette réponse, mais le topic que tu donne est fait pour limiter le courant de charge venant du MPPT et non du grid, Le Setting est lui accèssible depuis le MPPT uniquement. Il limite bien le courant batterie, mais le courant vient dans ce cas du solaire et pas du grid.
J’ai fini par trouver une solution pour limiter le courant de batterie venant du grid. Je le fais avec le courant limite de ACIN et dans ce cas on se moque de la valeur limite programmé pour la batterie.
J’ai besoin de limiter ce courant, car quand je met mon générateur externe (qui est peu puissant), alors le simple courant de charge programmé à 10A écroulait le générateur. La puissance utile est chez moi est toujours limitée à moins de 500W lorsque j’utilise le générateur et 2 A suffisent aussi pour la charge de la batterie. La solution était évidente, mais j’étais obnubilé par ce courant batterie sans penser qu’il fallait tout simplement limiter par programme le courant ACIN
Merci
J’ai une recharge très douce depuis le grid cette nuit donc je te confirme que ca fait bien les deux ! ( du coup, j’ai une automatisation qui reset cette valeur au petit matin si ca état dans la veille au soir)
Oui, mais dans mon cas, je ne peux pas mettre 2A pour le MPPT aussi car dans ce cas, le solaire ne rechargerait pas la batterie suffisamment. Je voulais limiter uniquement le courant du grid. Le générateur est utilisé le jour uniquement en cas de mauvais temps. et dès que le courant batterie est supérieur à 2A alors je coupe le générateur automatiquement par programme.
Merci
Apparemment tu programme sous HA, c’est fiable?, moi je le fais par nodered. et ca me permet d’écrire aussi directement avec nodered dans une base de donnée pour ne garder que ce qui est essentiel sur mon NAS. Sous HA, il faut faire un tas de manips pour écrire les historiques qui doivent être permanents.
L’idée proposée est bonne Merci de l’exemple Yaml…
Oui c’est fiable et ça fonctionne bien, la difficulté est de transcrire les infos victron en HA.
Genre les schedules sont en seconde depuis minuit que j’ai transformé en time dans HA de manière automatique
Oui, c’est la raison pour laquelle j’ai tout refais en nodered. La lecture des valeurs de Victron est faite directement par MQTT en m’abonnant aux requêtes du Victron et je met à disposition de HA les valeurs importantes recalées avec les heures du PI5. L’automatisme de commande et de stockage sont confiés à nodered, et les avertissements, notifications sont gérés par HA.
J’ai du coup accès à toutes les informations Victron que je veux avec une fiabilité de commande assurée par nodered.
Nodered est plus fiable à mon gout que HA:HA je l’ai déjà vu bugger surtout dans l’historique et il se mélange les pinceaux dans le stockage de la base de données. Comme le stockage de VRM est maintenant limité, j’assure moi même l’historique avec une granularité de 1h dans l’historique de quasiment toutes les valeurs importantes, L’étape suivante sera d’intégrer les défauts à la granularité de 1s dans cet historique long terme. (ça on ne peut pas le faire par HA je pense car il faut une décision issue de traitement des données que HA ne possède pas encore.
Pierre
3000W
Mais depuis j’ai réglé le problème. J’avais pourtant lu les docs, mais je n’avais pas fais le lien que le venus reprogrammait de lui même la valeur du courant de charge “grid” lorsque l’on reprogramme le courant limite ACIN (a chaque fois que l’on reprogramme ce courant ACIN limit, alors la valeur du courant du chargeur est réévalué.
Par contre d’aimerai bien savoir comment ce courant est calculé en fonction du courant disponible que la load sur ACOUT ne consomme pas.
Dans ma logique, les deux courants n’étaient pas liés, car en principe, on peut décider de limiter le courant AC pour la LOAD ACOUT et mettre un courant de charge plus faible pour ne pas charger la batterie à partir du générateur. Mon use case, dans mon cas: ca me coute très cher d’alimenter la load par générateur en cas de mauvais temps en hors réseau (500W max dans mon cas), et la batterie n’a pas à être rechargée par le générateur, elle peut attendre une recharge solaire plus tard.
La fiabilité de HA est là (depuis le temps que je l’utilise, très peut de soucis) mais surtout, nodered n’a pas une interface pour tout les jours, donc pour faire des automatisations statiques why not, mais perso je veut pouvoir intervenir et voir quand les changement ont lieu , …
après pour la bdD, oui, elle est assez fragile (c’est du sqlite par défaut), mais les sauvegardes sont là pour ça mais surtout, je confie a influxdb/grafana les données Solaires et d’énergies , …
Voici un exemple, de mes 2 schedules que j’utilise (le 1er, c’est normalement que avant un jour rouge tempo, le 2eme c’est pour consommer (mais pas recharger) en HC et ainsi évité de consommer au petit matin en HP si la batterie n’est pas assez plein pour attendre les 1er photons du matin , …
Du coup, l’interface du cerbo et VRM, j’y vais que très rarement car pour les besoins du jour au jours, c’est dans HA (comme bcp d’autres choses chez moi, comme notes , devoirs et plannings des enfants, compte bancaires, horaires de bus, niveau de pollution, prévision météo, … )
Bonne idée, pour les scheludes
j’utilise aussi nodered pour contrôler les batteries en permanence et surtout asservir le SOC qui n’est pas bien calculé par Victron quand on charge exclusivement avec le MPPT. Le défaut du MPPT est que le critère de charge à 100% sur batterie au plomb est uniquement basé sur “la tension batterie a dépassé la tension min d’absorption, et que le courant de queue est inférieur à une certaine valeur”. Ce qui est faux, le bon critère est il faut que la tension d’absorption reste au dessus de la tension d’absorption min pendant que le courant de queue descende en dessous du courant de queue. De ce fait, la batterie passe à 100% lorsqu’il y a un nuage qui passe juste après que la tension ait passé la tension d’absorption car dans ce cas le courant de queue est atteint systématiquement. La batterie est alors sous-chargée-> Galère…
J’observe que le SOC est bas pour l’installation. Si c’est du lithium, pas trop de soucis, ma philosophie est plutôt de recharger les batteries par le solaire, et ne pas les décharger en dessous de 70%. je me sert des batteries en tampon si il y a des variations de soleil, et des que le mauvais temps arrive dans ce cas je bascule soit sur le secteur soit sur le générateur…
Je conseille de mettre batterie life en route sur le chargeur grid, la durée de vie des batteries s’en trouvera améliorée.
Cordialement
je ne comprend pas trop ce que vous voulez dire, je crois qu’il y a une incompréhension du système de charge!
deja le mppt ne calcule pas de soc. ensuite le mppt comme tout chargeur victron est un générateur de tension sur la phase absorption et float donc la tension ne va pas dépasser celle donnée par le régulateur, apres il passe en float en fonction d’un courant de queu (qui accesoirement est réglable) et qui peut être influencé par des consommateur dc d’où le csc du dvcc quand on est en site isolé. quand on est en ess ou avec des batterie vecan, le mppt ne gère rien il fait simplement ce que le cerbo lui dit en fonction soit de l’ess soit de la batterie vecan!
Bonjour,
Nous sommes d’accord sur les fonctions du MPPT. par contre je n’ai jamais dit que le MPPT calculait le SOC. Par contre le critère appliqué pour calculer le SOC est faux quand on charge avec le MPPT et pas le chargeur grid.
Je suis avec des batteries plomb (donc sans BMS).
Faites l’essai dans les conditions suivantes pour vous en convaincre:
Mettez la tension d’absorption de ce chargeur grid juste en dessous de celle du MPPT pour qu’il ne donne pas de courant.
chargez avec le MPPT seul jusqu’à obtenir la tension d’absorption et attendez un peu de temps pour voir apparaitre le courant de charge qui diminuera car le MPPT rentre dans une phase de tension constante.
puis simulez un nuage pour avoir le courant de charge de la batterie qui descend en dessous du courant de queue, attendez encore une peu de temps (la tempo programmé programmée dans l’OS). la tension peut passer en dessous de la tension de float si la batterie n’est pas complètement chargée et alors le SOC se mettra à 100% alors que la batterie n’est pas complètement chargée.
Ceci est répétable dans cette configuration avec mon système.
Et ca me donne une batterie qui est vue chargée à 100% alors que la batterie peut n’être qu’à 75%.
Ou dites moi ce que je n’ai pas le droit de faire!
J’ai corrigé ceci par nodered, l’algo théorique pour valider un SOC à 100% est: tant que la tension de la batterie est à la tension d’absorption et que le courant passe en dessous du courant de queue alors la batterie est chargée à 100%. J’ai travaillé pour le groupe Hawker (section chargeur de batteries) en tant qu’expert de développement de chargeurs de batteries de traction, je sais de quoi je parles.
ok j’avais mal compris votre post.
dans votre cas c’est le multiplus qui calcule le soc ou un shunt?
si c’est le multiplus alors c’est normal car il calcule le soc selon les tension qui sont réglé dans l’onglet chargeur donc avec unreglage de tension plus faible que sur le mppt, forcement il passera a 100% avant que le mppt soit en floating et le soc ne sera pas bon !