habe gerade Kontakt mit einem Victron Support member, denke aber er ist vom NKON Team, egal.
Er meinte meine Art den maximale DC Ladestrom ständig zu ändern, würde den Speicher zu sehr beanspruchen und zum Defekt vom Gerät führen.
Ahhhh, solche Aussagen sind ja schon heftig, daher muss ich da dringend nachforschen.
ich habe ihm dieses Bild von meinem Node Red gezeigt, ich bin mir nicht ganz sicher, aber ich denke er meinte hier den orangen Befehl:
welche aenderungen zu schreibzyklen auf die ssd fuehren, kann man leicht feststellen:
ssh-zugang aktivieren
ssh-schluessel auf den cerbo kopieren, damit man nicht staendig ein pw eingeben muss
die datei /data/conf/settings.xml 2 mal mit einem groesseren zeitabstand kopieren und vergleichen
also das aendern der max wechselrichterleistung wird im minutentakt gespeichert, wenn der wert oft geaendert wird. zu anderen einstellungen kann ich aktuell nichts dagen, da ich auch noch dabei bin, zu analysieren, wie oft welche werte gespeichert werden. man kann zwar die schreibvorgaenge minimieren, da aber auch die kWh-zaehler fuer das vebus-system hier regelmaessig gespeichert werden, wird die datei wohl auf jeden fall mindestens einmal am tag gespeichert!
mir waere es ja am liebsten, wenn nur die werte, die man von hand aendert gespeichert werden, aber nicht die, die man von node-red aus oder ueber mqtt aendert. aber leider hat victron das anders geloest.
seit gestern 18:00 hat sich die Datei nicht geändert, sobald PV reinknallt schalte ich die Regelung an die per Node Red den DVCC max Charge Current ansteuert.
er trägt die Änderungen in der settings datei ein, allerdings ändert sich die Größe nicht. (oder im Byte Bereich)
dh. bei jeder Änderung (via Red Node auf die blauen DVCC Blöcke) wird auf den endlichen Speicher geschrieben…..
es gibt werte, die werden staendig in die config-datei geschrieben und andere nur in groesseren zeitabstaenden.
die dvcc-einstellungen gehoeren zu den werten, die sehr schnell gespeichert werden, deshalb sollte man die nicht so oft aendern. ich habe deshalb auch schon einige programme in node-red geaendert. ansonsten bin ich dabei festzustellen, welche werte ich bedenkenlos aendern darf, ohne dass sie staendig geschrieben werden.
um dieses problem mit den dvcc-einstellungen zu umgehen, habe ich das vorhandene bms in ein virtuelles bms gespiegelt und aendere dynamisch die bms-paramter. da diese informationen ja vom bms kommen, werden sie auch nicht in der config-daten gespeichert.
Interessant, das war auch mein Ansatz, die BMS Parameter zu manipulieren. Es geht ja nur darum die Ent-/Ladeströme und Spannung anzupassen.
Grundsätzlich bin ich ja kein Freund von, Systemrelevante Dinge anzugreifen, diese Werte sind wichtig und mM Sicherheitsrelevant.
Wenn es denn sein muss, dann muss es, aber optimal ist das auf keinen Fall.
werd mir deinen Flow ansehen! dachte aber durch die direkte Ve-Can Bus Anbindung wird das direkt vom Cerbo übernommen?
du erzeugst eine virtuellen Batteriestruktur, wo ist die Magie, diese Werte ins System zu übertragen?
ich kenne leider nur die moeglichkeiten, das ganze ueber dvcc zu machen, wobei jede aenderung der einstellungen sofort gespeichert wird, oder ueber die emulation eines bms. fuer den multi gibt es noch die moeglichkeit, das ganze ueber die vebus-battery-parameter zu machen, ob sich da die stromeinstellung dann auch auf die mppts auswirkt, weiss ich nicht, aber ich glaube nicht. wenn kein bms vorhanden ist, wird aber die maximale ladespannung von den mppts uebernommen und ich regele den ladestrom lieber ueber die ladespannung als ueber eine strombegrenzung.
du musst dich also entscheiden: dvcc mit speicherung aller aenderungen mindestens einmal in der minute oder du benutzt eine variante, bei der nichts gespeichert wird oder du beschraenkst die aenderungen auf ein minimum, da die settings.xml normalerweise sowieso mindestens 1-2 mal am tag gespeichert wird. zumindest wenn die vrm-verbindung aktiviert ist.
eine weitere variante waere es, die bms-einstellungen zu aendern, aber das geht bei vielen nicht, wie z.B. pylontech und das muss dann fuer jedes bms gemacht werden!
in meinem flow steuert die function 10 den ladestrom abhaengig von verschiedenen parametern. die aktuelle version arbeitet zwischen 8 und 16 uhr mit der ladezeit. ein hoher soc bedeutet dann eben, dass von anfang an nur mit einem niedrigen ladestrom geladen wird!
aber vieleicht kannst du victron ja dazu ueberreden, aenderungen der dvcc-einstellung ueber node red garnicht oder nur einmal am tag zu speichern.
die blauen Nodes sind die Infos die vom BMS über Ve.Can kommen. Wo wird die direkte Verbindung zum Cerbo unterbrochen, dass dieser nicht die Werte sofort übernimmt? Dann schreibst du auf die gelben Nodes, die sind Variablen des Akku Nodes? Was ist der Akku Node? was ist der “Virtual Device”, gibt es dazu ein Plugin odgl.?
Offtopic: oft sieht man den Wald vor lauter Bäumen nicht ! Was ich brauche ist mein 2. ESS MP2 System, welches mir nur die Batterie lädt, auszubremsen. Das kann ich doch schon ganze einfach machen! Warum - weil das 2. ESS per Mqtt Batterie die Werte bekommt, na die brauch ich ja einfach nur verändern. Mann so einfach…. dazu mache ich aber einen eigenen Thread auf, dieser soll diese Thematik weiter verfolgen.
der akku ist das gelbe node ohne verbindung und ueber die gelben nodes werden die werte des akkus gesetzt.
die werte werden vom cerbo immer direkt uebernommen, nur muss man unter dvcc einstellen, dass jetzt das neue virtuelle bms benutzt wird, anstatt des can-bus-bms, das muss natuerlich angeschlossen bleiben, da die werte davon je benoetigt werden!
die dafuer noetigen nodes sind auf dem gx bereits ab einer bestimmten firmware vorhanden.
im einfachsten fall erstellst du auf beiden systemen ein virtuelles bms, uebernimmst die daten vom can-bus-bms, einmal direkt und einmal ueber mqtt und begrenzt den ladestrom einfach prozentual fuer die systeme, also z.B. ein system 70% und das andere 30%.
alternativ kannst du auch noch den ladestrom vom ersten system abrufen und vom ccl abziehen, so dass das 2. system nur noch den bis zum ccl fehlenden strom ergaenzen darf.
wie gesagt, das funktioniert sehr gut, allerdings regele ich den ladestrom ueber die spannung, denn die muss ich dann nicht so viel aendern, wenn sich andere werte aendern. obwohl es in dem fall auch kein problem ist, wenn sich der ccl schnell aendert. zur sicherheit wuerde ich auf dem 2. system nur ca. 90% des moeglichen ccl eintragen oder einfach einen festwert abziehen, immerhin gibt es ja noch die regelverzoegerung!
von Victron keine Unterstützung erhalten. Öffnet man ein Ticket bei Victron, wird man an einen Händler weitergeleitet, der soll sich darum kümmern. Dort gibt es meist nur die Antwort - frag die Community. Das wars und somit ist für mich der Victron Support “schlecht” ! Auch wenn ich über den Händler vor Ort gehe, bekommt man wenn nur nach vielen Wochen / Monaten einen zweisilbige Antwort. Alles in Allem - “INAKZEPTABEL” !!
da muss ich dir recht geben, aber man kann mit den produkten von victron nun einmal mehr machen als mit produkten von anderen herstellern und im gegensatz zu anderen herstellen, kann man bei victron auch viele probleme umgehen, wenn es sich nicht gerade um hardwarefehler oder schwerwiegende firmwarefehler handelt! manche firmware-fehler kann man aber auch einfach ignorieren, wenn man die funktion nicht braucht, wie die history bei den mppts!
frueher war das jedenfalls besser, da konnte man sich auch als endkunde noch an den victron-support wenden, aber irgendwann ging das nicht mehr!
die HW kritisiere ich nicht, bin sehr zufrieden, aber wenn mir das Teil wegen einem defekten Speicher abkackt, dann bin ich sauer. Und es ist nicht möglich da eine Information zu bekommen, was geht da ab…
die probleme mit dem speicher kenne auch, vor allem von meinen kleinen arm-system. im ersten hat die speicherkarte den ersten systemupdate nicht ueberlebt!
inzwischen pruefe ich die geraete darauf, welche dateien geaendert werden und das sind hauptsaechlich die flows von node-red, wobei ich dann immer die aenderungen durchfuehre und die settings.xml auf der data partition. und was dort geaendert wird, kann man feststellen. aber mehrer schreibvorgaenge am tag sind kein problem, aber jede minute eventuell schon! deshalb versuche ich das zu verhindern.
allerdings ist mir schon aufgefallen, dass die ziel-ip des ssh-vrm-tunnels ebenfalls immer in der settings.xml gespeichert wird. das sollte aber kein problem sein.
allgemeine informationen, wie oft ein flash-speicher geschrieben werden kann, kann man im internet finden. wie oft eine bestimmte datei auf eine ssd geschrieben werden kann, ist dann aber auch von der verwaltung abhaengig, ob die immer an die gleiche stelle geschrieben wird oder nicht!
mein aeltestes gx, eine venus-gx, ist inzwischen seit ueber 10 jahren im einsatz und es lebt immer noch und auch die aktuelle firmware laeuft noch darauf. allerdings ist es fuer die meisten dinge zu langsam, so dass es jetzt in meinem test-ess seinen dienst tut, dort ist nicht viel angeschlossen.
das system mit dem programm ist bei mir jedenfalls auf RO gesetzt, lediglich die datenpartition kann geschrieben werden und ich denke, falls die mal defekt sein sollte, kann man das auch noch auf eine sd-karte umbiegen.
aber es gibt noch einige andere kriterien, die zum totalabsturz fuehren koennen und eines ist die netzwerkverbindung!
Since I also manipulate the CCL with nodered I found this theme interesting.
I checked with Cloude,ai and we came to this conclusion:
Node-RED CCL control without wearing Cerbo flash — simple fix
Many people use Node-RED to dynamically control DVCC MaxChargeCurrent on the Cerbo GX. As discussed in this thread, writing to /Settings/SystemSetup/MaxChargeCurrent on every trigger cycle writes to settings.xml on flash storage — potentially thousands of times per day.
The cleanest solution without building a virtual BMS is to add a simple filter in Node-RED that only writes when the value actually changes:
javascript
var lastCCL = context.get('lastCCL');
if (msg.payload === lastCCL) return null;
context.set('lastCCL', msg.payload);
return msg;
Place this function node between your CCL calculation and your victron-output-custom Write DVCC CCL node.
Why not use the built-in rbe node? The rbe node in Node-RED should do the same thing, but on Cerbo GX it shows a configuration warning after deploy and does not filter correctly in practice. The function node above is a reliable alternative.
Result:settings.xml is only written when your CCL actually changes — which for a typical adaptive charging curve is only a handful of times per session, not every 5 seconds.
This does not solve the underlying issue completely — writes still happen — but reduces them to a level comparable to normal system activity.
Victron ist halt immer noch ein kleines Unternehmen, welches durch seine Erfolge an seine Grenzen gebracht wird. Daher ist die Philosophie von victron recht einfach. Nutze das bereitgestellte System wie es gedacht ist, dann erhälst du auch den Support. Wenn du die Vorzüge (z.B. NodeRed) nutzen möchtest, dann bist du aber auch dafür verantwortlich, und kannst halt keinen Support mehr erhalten. Das würde den Rahmen sprengen.
Zum eigentlichen Thema. Wie oft ein Speicher beschreibbar ist ist von der Technologie abhängig, und kann grob im Internet erlesen werden. Das bezieht sich dann aber auf eine Speicherzelle. Wenn du das Schreiben über ein Dateisystem machst, was ja bei Dateien der Fall ist, so ist das nicht mehr definiert. Das hängt dann vom verwendeten Dateisystem und der verwendeten Integration des Speichers in das Dateisystem und sogar vom Speicher selbst ab. Im Idealfall kümmert sich das Dateisystem um defekte Speicherzellen/-blöcke, und verwendet diese nicht mehr wenn sie einen Fehler aufweisen. Bei USB-Sticks geschieht dies z.B. im Speichercontroller. Somit wird der zur VErfügung stehende Speicher mit der Zeit immer kleiner. Um welchen Zeitraum es sich hier aber handelt ist sehr schwer zu definieren.
Du hast nun mehrere Möglichkeiten.
Du schonst den Speicher und änderst einfach nichts
Du verwendest das System so wie dun denkst, und trägst dann eben auch das Risiko, das es irgendwann nicht mehr funktioniert
Vielleicht ist der Ansatz ständig den Wert zu ändern auch der Falsche. In meinem System wird der max ChaargeCurrent nur gelegentlich durch das BMS geändert.
