Oui.
J’ai une boucle de surveillance par ailleurs dans NodeRed, qui surveille le SOC et la tension batterie et procède à un appoint de charge si nécessaire (cas où on arrive à mes seuils de surveillance, qui sont à 7%/49v) avant éventuellement de basculer on grid.
Matt
Oui et non. Par exemple avec un Multiplus-II 5kVA, il est seulement possible d’alimenter des charges jusqu’à 4000 à 6500W selon la température, la durée et l’état de charge. S’il faut plus, alors le réseau est nécessaire. Si tu as mis des charges non essentiel du côté AC IN (recommandé), elles sont alimentées par le Multiplus tant que le réseau est présent. Elles ne sont plus alimentées dès que le réseau est en panne. Ainsi, tu réserves l’énergie aux charges essentiels.
Il y a également un risque d’usure du relais, difficilement estimable et peu documenté, qui pourrait réduire la durée de vie du Multiplus-II. Tous les relais (contacteurs ou rupteurs) ont une durée de vie dépendante du nombre de cycles et de l’intensité à l’instant du changement.
Tout ceci dépend énormément de l’utilisation que tu souhaites faire de ton installation. Chacun ses choix.
Comme beaucoup d’autres éléments, il est possible définir cette valeur avec Node-RED.
Considérant que je redéfinis cette valeur chaque jour sur base de mom propre algorithme (similaire à celui de Victron), je dois évaluer s’il est encore opportun d’utiliser l’algorithme BatteryLife de Victron ou s’il est plus simple de rester en mode Optimisé sans BatteryLife (ESS State de 10 à 12). A suivre…
J"ai fait ce choix 
L’ESS State n’est pas visible dans la console. Il est uniquement visible dans Node-RED.
Les valeurs définissent l’état ESS en fonction de l’évolution du système sur la journée. Elles permettent de déterminer comment le système doit réagir. Diminuer la limite active, l’augmenter ou ne rien faire. Forcer la recharge.
Ainsi en changeant le SoC minimum et l’état ESS à 8 ou 12, il est possible de forcer la charge, même si le SoC n’est que de 1 à 4% inférieur au SoC minimum.
Ok je comprends. J’ai un quattro 10kVA, et j’ai rarement dépassé cette valeur. Avant j’étais en Virtual Switch qui basculait sur le réseau quand la charge était supérieur à 9800W plus de 3sec et qui rebasculait en inverter Only si la charge < 9500W plus de 30sec.
Théoriquement je pourrais protéger le relais si quand la charge dépasse les 9800W et que je suis en Inverter Only je bascule en mode ON.
Autre chose, est ce qu’il y a un moyen pour renseigné quelle valeur du msg.payload utiliser dans un node victron, pour le SoC par exemple. J’ai un objet qui contient :
“tomorrowColor” : “BLUE”,
“soc” : 100,
“solarFc”: 18479.033279418945
et j’aimerais que le node ESS control utilise msg.payload.soc, c’est possible ou il faut obsolument que le msg.payload reçu par l’ESS control contienne uniquement la valeur a paramétrer ?
En tout cas merci pour toutes ces informations.
Actuellement, il faut que la valeur soit attribuée à la propriété payload uniquement. Donc, il faut reformater pour que le message arrive correctement au nœud suivant.
Un même nœud de type fonction peut sortir plusieurs messages sur une ou plusieurs sorties. Cette technique permet de ne pas multiplier les nœuds de type fonctions et permet de tout traiter en une fois pour tout envoyer aux différents nœuds suivants.
Deux exemples:
[{"id":"4f7b0a93c55ee47c","type":"inject","z":"606b655c5dab1a2b","name":"Push","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":1060,"wires":[["34109ca32c578b6e"]]},{"id":"34109ca32c578b6e","type":"function","z":"606b655c5dab1a2b","name":"Test","func":"let msg1 = { topic: 'A', payload: 1 }\nlet msg2 = { topic: 'B', payload: 2 }\nlet msg3 = { topic: 'C', payload: 3 }\n\nreturn [msg1,msg2,msg3];","outputs":3,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":250,"y":1060,"wires":[["54f494fb64e95490"],["dad25bc19c0a64b2"],["d6b0115031f4104a"]]},{"id":"d6b0115031f4104a","type":"function","z":"606b655c5dab1a2b","name":"Msg3","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":390,"y":1100,"wires":[]},{"id":"dad25bc19c0a64b2","type":"function","z":"606b655c5dab1a2b","name":"Msg2","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":390,"y":1060,"wires":[]},{"id":"54f494fb64e95490","type":"function","z":"606b655c5dab1a2b","name":"Msg1","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":390,"y":1020,"wires":[]}]
Chaque message est envoyé sur une sortie différente. Le nombre de sortie doit être correctement défini dans l’onglet Setup.
[{"id":"f4ac1bb7b975cfe5","type":"inject","z":"606b655c5dab1a2b","name":"Push","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":1240,"wires":[["e369a4e879cd0284"]]},{"id":"e369a4e879cd0284","type":"function","z":"606b655c5dab1a2b","name":"Test","func":"let msg1 = { topic: 'A', payload: 1 }\nlet msg2 = { topic: 'B', payload: 2 }\nlet msg3 = { topic: 'C', payload: 3 }\n\nreturn [[msg1,msg2,msg3]];","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":250,"y":1240,"wires":[["08de2729793b1e82"]]},{"id":"b26555d5c16f2b23","type":"function","z":"606b655c5dab1a2b","name":"Topic C","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":540,"y":1280,"wires":[]},{"id":"719c7e0c4a54334c","type":"function","z":"606b655c5dab1a2b","name":"Topic B","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":540,"y":1240,"wires":[]},{"id":"3f3c860ff5917251","type":"function","z":"606b655c5dab1a2b","name":"Topic A","func":"node.status({fill:'grey',shape:'dot',text:msg.payload})\nreturn null;","outputs":0,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":540,"y":1200,"wires":[]},{"id":"08de2729793b1e82","type":"switch","z":"606b655c5dab1a2b","name":"","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"A","vt":"str"},{"t":"eq","v":"B","vt":"str"},{"t":"eq","v":"C","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":390,"y":1240,"wires":[["3f3c860ff5917251"],["719c7e0c4a54334c"],["b26555d5c16f2b23"]]}]
Tous les messages sont envoyés sur une seule sortie. Le nœud suivant traite les messages séquentiellement, un par un en respectant l’ordre d’arrivé.
C’est une solution élégante. Parfait
Merci !
Bonjour,
Je viens de comprendre : en fait le SoC limit que l’on paramètre dans le VRM via la console n’est pas celui pris en compte par le système.
J’ai lu la notice ainsi que d’autre forum et si je comprends bien le active soc limit change de jour en jour suivant les conditions afin de charger les batteries à 100% si les 100% n’ont pas était atteint en 24h c’est ça ?
Est ce que ça dégrade la batterie si par exemple sur une semaine le soc de la batterie oscille entre 25% et 70% donc n’atteint jamais 100 %
Si oui il faut donc charger la batterie à 100% une fois tous les combiens de jours pour qu’elle ne soit pas dégradé ?
Mettons que je programme le Min SoC à 100% à 22h et le retour à 20% à 6h. Si la batterie atteint ses 100% à 3h, que fais le système pendant les 3h restantes ? Je demande pour savoir si il est impératif de remettre le Min SoC à la valeur basse quand les 100% sont atteint ou si on peut laisser le système tel quel.
L’ESS Minimum SOC est celui qu’on paramètre dans VRM. C’est celui que j’utilise pour mes usages.
Ca, ca dépend de ta batterie.Pour une batterie avec des cellules LiFePo4 (et seulement ce cas):
J’ai implémenté tout mon contrôle sur Node Red pour justement en avoir la maitrise (aussi bien pour les conditions de lancement de charge, que le comportement à suivre une fois la cible SOC atteinte). Je ne sais donc pas ce que fait le système Victron par défaut, mais j’imagine que ca dépend du mode de l’ESS.
Matt
Ok, merci des infos. Je vais programmer une charge complète par semaine minimum alors pour éviter la dérive du SOC.
Et autre chose, les noeuds inject sont en UTC. Tu as déjà répondu à unnovice sur le forum, j’ai lu le thread. L’heure du cerbo est bien réglée et je l’ai rebooté mais rien à faire. Un inject à heure précise est décalé d’une heure …
M’est avis qu’un top charge par mois suffit amplement si c’est un sujet qui te tracasse.
De base, le Dynamic ESS prévoit une charge complète chaque 2 semaines, paramétrable. Je pense qu’il maintient à 100% pendant au moins 3h.
Comme dit Matt, une fois par mois, ça me semble déjà très bien. Surtout que dès que les beaux jours seront de retour, probablement déjà en mars, il sera simple d’atteindre et maintenir les 100% pendant une ou deux heures en pleine journée. En gros, il faut seulement s’en soucier à cette période de l’année pour bien faire.
Le top charge n’a vraiment de sens que pour disposer d’une donnée SOC raisonnablement juste, et éventuellement lancer un équilibrage des cellules via le balancer (mais ça, ça dépend beaucoup de l’homogénéité et état des cellules de la batterie). J’ajouterai à cela qu’il faut vraiment comprendre le fonctionnement d’une batterie pour s’assurer des bons réglages pour charger, et surtout ne pas chercher à trop monter en tension car cela sera préjudiciable
A titre d’info, je n’ai volontairement pas fait de top balancing pendant 3 mois et le soc du Smartshunt avait dérivé de 4.5% par rapport au réel (celui de mon BMS n’étant pas fiable, je n’en parle pas), ce qui est négligeable dans l’absolu tant qu’on a bien une surveillance de la batterie en place sur les tensions (ce que le BMS a par nature, mais il faut idéalement implementer les actions ad hoc sur l’onduleur).
Ca, ca dépend de ta batterie.Pour une batterie avec des cellules LiFePo4 (et seulement ce cas):
une telle batterie peut tout à fait vivre sans atteindre 100% pendant un bon moment sans aucun dommage - tant qu’on reste en dehors de ses zones extrême de tension, RAS. Entre 25% et 70%, tu reste de toute façon sur la zone plate de tension des cellules, aux environs de 3.2/3.3v par cellule, donc ca ne change rien pour la chimie de la batterie. Et ca peut être ainsi durant des semaines sans problème. Ce qui risque de se passer est que tu disposes d’une information de SOC qui dérive dans le temps. Faire un top charge permet de faire un reset 100% du SOC donc te redonner une lecture facile de ton état de charge. C’est pour cette raison que ma surveillance de batterie dans node red est faite sur le SOC ET la tension (autant la tension cellule ou du pack complet ne fourni aucune indication sur le niveau de charge la quasi-totalité de sa capacité, autant sur les extrêmes, les tensions montent ou s’effondrent vite (et c’est là qu’il faut agir - au tout début de ces rampes))
je ne suis pas vraiment d’accord, le plus gros probleme de ne pas recharger c’est de favorisé un déséquilibrage cellule, si on ne monte pas régulièrement on en arrive a des dérives que les équilibreur auront du mal a compenser !
ne pas utiliser le battery life est même une exclusion de garantie sur nos batterie plomb et lfp !
Vrai pour un balancer passif ou un actif qui n’aurait d’actif que le nom (je pense par exemple du balancer de Seplos qui va avec mon BMS, qui ne vaut pas grand chose)
Un balancer actif un minimum correct devrait s’en sortir (et si il ne s’en sortait pas, alors un tel déséquilibre des cellules du pack sur une période d’un mois m’inquiéterait sur les cellules elles mêmes ).
A la rigueur, ça a du sens que les batteries victron s’appuient sur ces fonctions. C’est un tout, comme chez Apple
De mémoire battery Life pour les autres lfp n’est d’intérêt/preconisé que si il y a un balancer passif.
pour info le delta vcell de ma pylon sur le mois de decembre optimisation sans batterie life avec un soc autour de 55% ( donc mode stockage pour du lithium ) vu que la batterie n’est utilisée en ce moment que pour les recharges en hc rouges en effet l’energie de mes pv part essentiellement dans le ce dont le routeur solaire est prioritaire :
on remarquera que les deviations correspondent à l’utilisation en jours rouges 
