Ich habe keinen Einblick in welcher Speicher verbaut ist, gibt es dazu Unterlagen?
Regelparameter, welche man braucht um die eigenen und teuren Batterien zu schonen, führen zur Abnutzung der Geräte. In meinen Augen politisch ausgedrückt: “nicht nachvollziebar”.
hallo,
du kannst sehr wohl regelparameter benutzen, die nicht dazu fuehren, dass staendig etwas auf den speicher geschrieben wird. allerdings funktionieren einige dinge nur mit einer recht aktuellen firmware, andere auch mit aelteren versionen.
aber man muss immer node-red benutzen oder bestimmte parameter ueber mqtt beschreiben.
tschuess
Sorry, aber das sind Wutbürger-Verschwörungsmythen ohne jede faktische Grundlage. Da werden wieder mal nur völlig unsubstantiierte Bauchgefühl-Befürchtungen zur einer alternativen “Wahrheit” erhoben.
Es wäre was anderes, wenn wir wirklich massenhaft ausfallende SSDs in unseren GX Geräten erleben würden. Das geschieht aber gar nicht. Ich habe noch von keinem einzigen solchen Ausfall erfahren.
Wer sich ein wenig informiert, der erfährt schnell, dass Flash-Speicher maximal mehrere 100.000 Schreibvorgänge auf das gleiche Bit überleben. Aber man erfährt dann eben auch schnell, dass SSDs entweder schon selbst Maßnahmen dagegen enthalten, dass draüber hinaus die Treiber der SSDs in den Betriebssystemen ebenfalls Maßnahmen dagegen enthalten. Wenn ein einzelnes Datum wiederholt auf eine SSD geschrieben wird, dann wird es nicht ständig auf die gleiche Speicherstelle geschrieben. Die SSD bzw das Betriebssystem sorgt also von alleine dafür, dass die SSD in ihrer gesamten Speicherkapazität einigermaßen gleichmäßig belastet wird.
Große Teile der auf der SSD lagernden Daten bleiben unverändert gleich, aber die Lage dieser Daten auf der SSD wird ständig so verschoben, dass die SSD gleichmäßig belastet wird. Man kann ein einzelnes Datum also auch viele zig Millionen mal auf die SSD schreiben, ohne dass ein einziges Bit der SSD öfter als 100.000 mal beschrieben wird.
Wer die gleichen Sorgen hat wie der OP, der möge bitte erst mal recherchieren, wie oft SSDs tatsächlich wg zu hoher Zahl von Schreibzugriffen tatsächlich versagen.
Schwachsinnige Aussage leider….
Ich habe geschrieben, dass ich nicht weiß, welcher Speicher verbaut ist, steht das wo?
Rechne einfach mal, 20x pro Minute ändert man einen Wert (muss nicht, kann man aber ohne weiters machen, nimm 10 Werte die sich 2x ändern), alles läuft auf ein file hinaus. Das sind im Jahr über 10 Mio. Änderungen bzw. Schreibzyklen. Ja das kann - ich sage nicht, dass es bei mir so ist, aber man kann durchaus durch ständige Eingriffe von Regelalgorythmen das praktizieren - NIEMAND sagt, dass das ein Problem ist! und erfragen muss man sich, was man eigentlich darf bzw. kann um nicht in so ein Problem zu kommen. Ich habe 2 Jahre jetzt richtig geregelt, das ist sinnvoll in meiner Anlage und muss nun einen anderen Weg gehen, nachdem ich jetzt drauf gekommen bin, dass es ein Problem ist!
Welche wären das?
Nochmalss: Du verstehst es nicht. Du hast Dir was angelesen, nimmst diese Info isoliert und glaubst nun, Du hättest alleine die Weisheit gefressen.
Nein, 10 Mio Änderungen einer Datei auf einer SSD pro Jahr bedeutet eben nicht, dass die gleichen Flash-Speicherzellen 10 Mio mal pro Jahr beschrieben werden. Die werden, je nach Größe der SSD und der Datei - dadurch nur ein paar tausend mal beschrieben. Die Treiber der SSD bzw des OS sorgen dafür, dass die Daten immer wieder in anderen Flash-Zellen geschrieben werden, und sorgen so dafür, dass alle Bereiche der SSD gleichmäßig oft beschrieben werden.
Sorry, aber Du solltest, bevor Du solch wilde Befürchtungen verbreitest und dabei auch noch Victron diffamierst, doch erst mal die relevanten Fakten recherchieren: Von wie vielen Ausfällen von SSDs wg zu vieler Schreibzugriffe hast Du denn lesen können? Warum speichern Milliarden von Menschen ständig wichtige Daten auf dutzenden Milliarden SSDs?
Nein, darauf bist Du nicht gekommen, sondern hast Dir was angelesen, hast keine 10% davon verstanden, und verfällst in den üblichen Panik-Modus der Wutbürger. Fakt ist: das Problem, das Du angeblich erkannt haben willst, existiert in der realen Welt gar nicht.
Falls Du die Aussage, auf die Du Dich beziehen willst, auch zitieren würdest, könnte man dem Thread leichter folgen. Du willst wissen, mit welchen Maßnahmen in NodeRed man Schreibzugriffe auf die SSD minimieren kann.
Das einfachste ist, den Filter-Node dazwischen zu schalten. Der reicht Daten nur dann an den nächsten Node weiter, falls diese sich gegenüber dem letzten Zyklus verändert haben. Wenn ein Node also einmal pro Sekunde was ausliest, und daraus dann einen Regelwert errechnet, den es im System speichert, dann wird nur dann noch was gespeichert, falls dieser Regelwert sich geändert hat.
naja, dafür gibt es den Antwortbutton, da kann man sehen auf was sich jemand bezieht….
Nochmal! ich weiß nicht welche Art von Speicher verbaut ist. Eine SSD lebt lange, hat selbst Algorithmen um das ständige schreiben auf die selbe Speicherzell zu verhindern und kann auch umsetzen usw. Ja ist denn eine verbaut ??? Wo findet sich diese Information, oder ist eine Annahme deinerseits?
Du findest im Netz alles, dfalls es Dich wirklich interessiert. Und nein: anders als Du verbreite ich keine wirren Annahmen, die alleine auf mein Bauchgefühl gestützt sind.
Es gibt unterschiedliche Arten von Flash-Zellen, also auch unterschiedliche Arten von SSDs. In USB-Sticks werden vermutlich andere verbaut als in SSDs, aber welche Art in den SSDs des Cerbo verbaut ist, weiß vermutlich noch nicht mal Victron selbst. Die kaufen den RaspberrryPi auch nur ein, und da wird das verbaut werden, was der Markt gerade günstig liefern kann. Vermutlich wird Dir niemand sagen können, was für eine Art SSD in Deinem GX Gerät verbaut ist.
Aber das muss man auch nicht wissen, wenn man einfach nur mit etwas Vernunft an die Sache ran geht. Du brauchst ja nur zu recherchieren, von wie vielen SSD Ausfällen Du bei den GX-Geräten lesen kannst. Hier im Victron Forum ist mir noch kein einziger Fall bekannt geworden.
Hi @ESSGobel
A little late and excuse my writing in English, but…
The /BatteryOperationalLimits/MaxChargeCurrent variable is NOT - repeat NOT - written on the non-volatile memory.
It’s ephemeral dbus - hence RAM - variable, so you can write it as many times you want, with any frequency you want.
You can check with dbus-spy and see that when you disable BMS control in DVCC, those paths (/BatteryOperationalLimits/*) will contain nothing, will be null.
And they are filled from the info from external sources (BMS) so therefore there is no purpose to store them in non-volatile memory, as they are not settings, they are dynamic information.
1 Like
hallo,
bms-emulation ueber node-red oder setzen der battery-parameter fuer den multi, wenn KEIN bms vorhanden ist. allerdings kann man mit der 2. methode nur den ladestrom des multis steuern, nicht der mppts!
fuer die mppts gibt es noch die moeglichkeit, die parameter auf dem /link/-pfad zu setzen, damit kann man strom und spannung der mppts steuern.
das sind dann alles werte, die nie gespeichert werden und die zyklisch gesetzt werden muessen, sonst werden sie ungueltig oder es gibt eine bms-fehlermeldung.
ich benutze inzwischen alle 3 methoden, abhaengig davon, ob ein bms oder ein multi vorhanden ist.
hier findest du auf jeden fall schon einmal ein beispiel fuer das bms:
eine andere variante, die ich auch noch benutze, ist die direkte steuerung von vedirect-geraeten ueber eine eigene software. als ich die geschrieben habe, gab es naemlich die moeglichkeit mit dem venus-os noch nicht! dafuer kann die software aber auch beliebig viele systeme steuern und nicht nur eines.
tschuess
1 Like
Hi @alexpescaru , may I ask, you are from Victron?
If I change the MaxChargeCurrent, the value is written to the settings.xml. Each time. The file is on the ssd? - non-volatile memory?
No, not from Victron.
There is a difference between /Settings/MaxChargeCurrent and /BatteryOperationalLimits/MaxChargeCurrent.
The first is stored on non-volatile, but the later is not.
The paths may not be exact, but I wanted to suggest that there is a MaxChargeCurrent that you are setting in each MPPT/Charger/Inverter and that is stored in non-volatile and there is a MaxChargeCurrent that is dynamically processed and sent to each device based on the battery needs.
This last one is not stored in non-volatile and is ephemeral.
If you take a look inside the DVCC script, you will see a lot of maxchargecurrent variables… quite confusing sometimes, but you’ll get used.
in first post, orange and blue, which one do you mean.
orange - not written to non-volatile
blue - written to non-volatile
Correct.
As an empiric rule, all that have “settings” inside the name is written on non-volatile and may be subject of wear. Otherwise no.
That seems logical, but unfortunately, Eco Lithium BV gave me the exact opposite information (in their response to my support ticket)…
So, the orange nodes are the ones you should use and can write to as often as you like.
Or have I misinterpreted this information? :
Ok so you change both multi’s charge current as DVCC?
Better only use DVCC: changing the setting too often could wear out that memory location .
@ESSGobel Um die Haltbarkeit deinen Akkuspeicher zu verdoppeln gibt es eine ganz einfach Möglichkeit. Verdoppel einfach die Akkugröße.
Wenn du dir sorgen darüber machst, das ein zu großer Ladestrom deinen Akku beschädigst, liegt die Vermutung nahe, das das Verhältnis von PV zu Akkukapazität ungünstig ist. Ich wüsste nicht warum man sonst den Ladestrom begrenzen sollte?
wirtschaftlicher Unfug. aber ja, man könnte so handeln.
es geht aber nicht darum vollgas jeden Tag den Akku um 10h Vormittags voll zu haben….
im Winter zu wenig, im Sommer zu viel, will man das jeden Tag manuell korrigieren… nein.
Ob das wirtschaftlich Unfug ist, hängt natürlich von deinen System ab, da ich das nicht kenne mag ich mir da kein Urteil bilden.
Du kannst ja alternativ in den Vormittagsstunden den Überschussverbrauch erhöhen, dann bleibt weniger für dein Akku übrig.
Aber egal, die Lösung steht ja schon weiter oben, einfach den Wert nutzen, der im RAM gespeichert ist.
Überschussverbrauch erhöhen, auch wieder so ein unsinniger Gedanke, mein System ist optimiert und soll jetzt - nicht manuell - sondern automatisiert - irgend welche Verbraucher aktivieren, wenn grad keine Wolke da ist und das System voll in die Batterie reinballert. Oh mann….