Akku wird nicht entladen / System Setzt #7

Ich habe ein kurzes Video vom Verhalten gemacht.
Was darin nicht zu sehen ist: Nach einiger Zeit zeigt das System selbstständig den Fehler #7 an und wechselt in den BatteryLife-Modus.
Manchmal passiert das ziemlich schnell, manchmal dauert es etwas – aber früher oder später tritt es immer auf.

Seplos BMS 2.0 (EEL SmartBMS 200A) – Victron ESS + NEEY Balancer

Nachdem mein JK BMS gestorben ist, hab ich ein klassisches 16s 280Ah LiFePO₄-System mit dem EEL SmartBMS200 / Seplos BMS 2.0 (4815010E) aufgebaut – und dachte, das wird easy. War’s nicht.

:white_check_mark: Systemübersicht

  • :electric_plug:Victron MultiPlus-II 48/5000 im 3-Phasen-ESS-Betrieb
  • :battery: Seplos 2.0 BMS mit 16s 280Ah LiFePO₄
  • :fire_extinguisher: NEEY Active Balancer, BMS-internes Balancing deaktiviert
  • :sun: Div. Victron SmartSolar-Regler + 2 Hoymiles 2250 + 1 HMS1600
  • :house_with_garden: AC-Out1 versorgt das ganze Haus, daran hängen die Hoymiles Mikrowechselrichter

:cross_mark: Fehlerbeschreibung: Victron ESS – ständiger Fehler #7, BatteryLife & Entladung blockiert

:wrench: System:

  • 3× Victron MultiPlus-II 48/5000 (je Phase einer)
  • Cerbo GX (neu aufgesetzt)
  • 16s 280Ah LiFePO₄ Akku
  • Seplos BMS 2.0 (Firmware CAN1101 V16.06.05_PN01_230916_SP80)
  • NEEY Active Balancer
  • ESS-Modus: Optimiert ohne BatteryLife

:firecracker: Das Problem (seit über 1 Monat):

Das System geht permanent in Fehler #7:

„Der Benutzer hat ein Entladelimit von 0 % gesetzt“

Das passiert dabei automatisch:

  • BatteryLife wird selbstständig aktiviert, obwohl deaktiviert
  • Min. SOC wird auf 100 % gesetzt
  • Akku-Entladung wird sofort auf 0 % blockiert
  • Im Cerbo unter „ESS“ wird „Limit Inverter Power“ aktiviert und auf 0 gesetzt
  • Akku steht dauerhaft bei 100 % SOC
  • Im Menü steht „Externe Steuerung – ESS #7

:repeat_button: Was (manchmal) hilft – aber nicht dauerhaft:

  • Wechsel auf „Nur Wechselrichter“, dann zurück auf „Ein“
    → klappt manchmal, oft aber nicht
  • VE.Bus neustarten
    → dann kurze Entladung möglich, bis der Fehler sofort wieder auftritt

:white_check_mark: Was alles schon gemacht wurde:

  • Jeden MultiPlus Firmware update verpasst
  • ESS-Konfiguration komplett neu aufgesetzt
  • ESS-Assistent in VE.Configure mehrfach neu durchgeführt
  • Cerbo GX komplett neu installiert
  • BMS-Firmware aktualisiert
  • BMS-Einstellungen mehrfach überarbeitet
  • NEEY Balancer angepasst (BMS-Balancing deaktiviert, Schwellen korrekt gesetzt)

:brick: Ergebnis:

  • Der Akku bleibt bei 100 %
  • Das System entlädt nur für Sekunden (wenn überhaupt)
  • Der Fehler #7 kehrt immer wieder zurück
  • Das System ist dauerhaft blockiert, keine Entladung möglich

hallo,
was fuer ein ess-betriebsmodus ist eingestellt und hast du irgendwelche scripte laufen oder schreibst du daten ueber mqtt/modbus auf den cerbo?

und noch ein tipp: aendere einmal dein vrm-passwort!
darueber kann man naemlich auch einstellungen aendern, wenn die zweiwegekommunikation aktiviert ist!

du kannst auch mal die 2-wegekommunikation deaktivieren!

tschuess

Wie im Video zu sehen ist, war anfangs ESS ohne BatteryLife aktiv.
Nach einer gewissen Zeit stellt sich das System jedoch selbstständig auf ESS mit BatteryLife um.

Manchmal passiert es sehr schnell, manchmal dauert es, aber früher oder später passiert es immer.

Heute war es allerdings anders:
Seit Erstellung des Posts – also seit ca. 4 Stunden – bleibt das System konstant in meiner gewählten Einstellung.

Das ist eher ungewöhnlich, normalerweise verstellt es sich viel schneller.

Was aber trotzdem nicht funktioniert:

Eine Entladung des Akkus findet weiterhin nicht statt.


Technischer Hintergrund:

  • MQTT ist bei mir nicht aktiv.
  • Modbus TCP wurde bisher nur von Loxone verwendet (nur Lesen) – das habe ich zur Fehlersuche aber mittlerweile deaktiviert.
  • Der Cerbo liest via Modbus TCP den Carlo Gavazzi EM24 aus. Dieser erscheint in der VRM Übersicht als PV-Wechselrichter (mehrere Hoymiles).

Zum Thema VRM & Sicherheit:

Guter Hinweis – ich habe inzwischen das VRM-Passwort geändert und 2-Faktor-Authentifizierung aktiviert.
Ich gehe davon aus, dass das ausreicht.

Die Einstellung im VRM steht weiterhin auf “FULL” – ich nehme an, das ist gemeint mit “Zwei-Wege-Kommunikation”?

hallo,
mit der neuen firmware findet man das jetzt unter vrm portal, wo man aus, schreibgeschuetz oder vollstaendig auswaehlen kann. ich musste jetzt leider etwas suchen, da ich das noch nicht bemerkt hatte.

das problem ist, wenn jemand dein vrm-passwort kennt, hat er vollen zugriff auf dein system und kann alle einstellungen aendern.

und wie gesagt, einstellungen aendern sich nicht von selbst. hast du node-red laufen?

schau dir mal mit dem mqtt-explorer oder einem anderen programm den folgenden wert an:
N/id/system/0/Control/ActiveSocLimit

du kannst den wert ueber mqtt aus aendern:
W/id/system/0/Control/ActiveSocLimit

das ist der active soc limit fuer die entladung, der wird normalerweise nur vom system gesetzt und kann auch nur ueber den mqtt-server geaendert werden. wenn der auf 100% ist, spiel es keine rolle, was bei min soc eingestellt ist, der akku wird nicht entladen!

du kannst das mit dem mqttexplorer machen oder das large image mit node-red aktivieren!

das ist uebrigends auch ueber den mqtt-server des vrms moeglich und due kannst den mqtt-server auf dem cerbo auch nicht deaktivieren, du kannst nur den lokalen nertwerk-zugriff darauf blockieren.

wenn also jemand dein vrm-passwort hat, waere es kein problem dafuer zu sorgen, dass du bestimmte einstellungen nicht dauerhaft aendern kannst, solange das vrm vollzugriff hat!

also sicherheitshalber einmal auf schraibschutz stellen.

tschuess

**Lieber @d_ferdi **

ich habe heute so ziemlich den ganzen Tag mit dem Thema herumprobiert, mich intensiv mit MQTT beschäftigt, die KI damit gefüttert usw. – leider aber ohne Ergebnis.

Dann habe ich den Cerbo nochmal komplett neu geflasht. Beim Neueinrichten habe ich zunächst vergessen, den EM24, der bei mir via Modbus TCP eingebunden ist, zu konfigurieren. Und plötzlich hat der Akku einfach entladen, entladen und weiter entladen – das läuft jetzt schon seit über einer Stunde so.

Ich vermute, da stimmt irgendwas nicht. Ich verwende den EM24 vorerst mal nicht mehr und werde das Verhalten weiter beobachten.

Auf jeden Fall möchte ich dir herzlich danken – du hast dich mit Abstand am meisten für mein Problem eingesetzt. Vielen, vielen Dank dafür!:flexed_biceps:

gif

hallo,
hast du vieleicht den em24 falsch eingebaut? eingang und ausgang vertauscht oder phasen vertauscht?

tschuess

Nun ist zwar nicht alles abschließend geklärt, aber es gab insgesamt drei Probleme, die vorher nicht aufgetreten sind – und vermutlich hängen sie alle mit Modbus TCP zusammen (das inzwischen deaktiviert ist).

Lediglich der Netzzähler darf sich noch per Modbus TCP verbinden. Alles, was mit Loxone zu tun hatte, wurde entfernt, und der EM24 ist ausgebaut.
Als Netzzähler verwende ich ja den VM-3P75CT, der zwar über Modbus TCP kommuniziert – es aber irgendwie trotzdem tut, auch wenn man Modbus TCP deaktiviert. Muss keiner verstehen.

Sollte ich irgendwann ein neues Kabel in den Schaltschrank ziehen müssen (wird passieren), verbinde ich den Zähler über VE.Can. Dann kann auch mal das Netzwerk ausfallen, ohne dass das System gleich aussteigt.

Zusammengefasst stürzt das System komplett ab, wenn einer der folgenden Punkte eintritt:

  • zu viele oder überhaupt (nicht ganz geklärt) Modbus-TCP-Anfragen von Loxone
  • der EM24 kommuniziert via Modbus TCP (das kann aber auch erst nach mehreren Stunden passieren)
  • ich aktiviere die Zwei-Wege-Kommunikation zum VRM-Portal (auch hier dauert es oft mehrere Stunden, bis das System zusammenbricht)

Inzwischen bereite ich die Netz-Zählerdaten direkt am Cerbo mit Node-RED auf und sende sie über die WebSocket-API mittels node-red-contrib-loxone an Loxone.
Das läuft extrem stabil – und vor allem schnell.
Die AC-Wechselrichterdaten die vorher der EM24 ausgelesen hat kommen jetzt von der OpenDTU via Dbus-opendtu auch hier funktioniert das super. Loxone holt sie auch von dort. Ich Spare mir einen Zähler und kann in zukunft auch die Wechselrichter regeln um eine Netzparalele Nulleinspeisung zu realisieren (an dem arbeite ich noch)

Ursprünglich wollte ich alles von Victron nach Loxone per MQTT lösen, aber diese Verbindung ist nach einiger Zeit immer wieder abgebrochen. Erst nach dem Öffnen des VRM-Portals hat Victron wieder Daten gesendet.

Das Ganze mit Node-RED gefällt mir mittlerweile sehr gut – ich habe viel dazugelernt.

Bitter ist allerdings, dass ich die Zwei-Wege-Kommunikation zum VRM-Portal wohl nie wieder einschalten kann. Irgendwas wird dabei geladen, das das komplette System zerschießt – ich konnte es leider nie eindeutig reproduzieren.

Mir hat das Feature gefallen, denn so konnte ich mein System auch von der Arbeit aus steuern. Jetzt ist nur noch ein lesender Zugriff möglich – wirklich schade.
Man kann die Konfiguration im VRM-Portal leider nicht löschen, ohne gleich die komplette Statistik zu verlieren – das ist aus meiner Sicht ein echtes Manko.

hallo,
wenn du modbus auf dem cerbo deaktivierst, gilt das nur fuer anfragen an den cerbo, aber nicht fuer anfragen, die der cerbo macht! deshalb funktioniert der zaehler auch dann, wenn modbus deaktiviert ist.

ve.can hat eine laengenbegrenzung, was die kabellaenge angeht, da musst du aufpassen. das kann vor allem zu erheblichen problemen fuehren, wenn du auch noch can-bus mppts angeschlossen hast.

was die zweiwege kommunikation angeht, damit habe ich bisher keine probleme. was genau funktioniert denn nicht mehr, wenn du die aktivierst? stuerzt das system komplett ab?

mqtt braucht ein keep-alive, sonst stoppt es die datenuebertragung. allerdings reicht es, wenn ein system den sendet, dann bekommen auch alle anderen, die abfragen senden, ihre daten.

was die fernsteuerung angeht, benutz ein vpn. das geht mit einer fritzbox sehr einfach und auch viele anderen router bieten inzwischen ein vpn an.

tschuess

genau dann passiert all das oben geschriebene ^^ Das system läuft dann in der Regel 2 minuten und danach schaltet es sich ab. Ich bekomm das dann auch nicht mehr weg in dem ich die kommunikation deaktiviere. Das einzige was dann geht ist komplett neu flashen oder mit der sd karte zurück setzen ← aber ohne internetverbindung denn von grund auf ist die 2 wege kommunikation eingestellt und dann zieht er sich die daten wieder und dann geht es von vorne los. War eine Harte Nummer das raus zu finden ich hab ihn sicher 10x zurück gesetzt mittlerweile.

Ja das mit dem Keep-Alive hab ich nicht hin bekommen aber loxone ist ohnehin auf 16 anfragen beschränkt also verfolge ich das erstmal nicht weiter - geht ja so auch bestens.

nein das können wir in der Firma nicht machen. Veränderungen am System sind nicht möglich.

hallo,
hast du irgendwelche zusatzprogramme auf dem cerbo installiert?

hast du dich einmal ueber ssh angemeldet und nach der cpu-belastung? das geht nach dem ssh-login mit top und das kann man mit strg-c wieder beenden.

was doch sehr verwunderlich ist, ist die tatsache, dass man den cerbo neu flashen muss, wenn der fehler auftritt.

und abgeschaltet hat sich bei mir auch noch kein system, obwohl ich mein altes venus gx auch schon regelmaessig ueberlastet habe.

dass das teil nicht mehr funktioniert, tritt normalerweise nur auf, wenn die datenpartition komplett voll ist!

uebrigends, das system duerfte auch eine vpn-verbindung oder einen tunnel zum vrm-system aufbauen oder wenigstens eine ssl-verbindung. an welchem system kannst du nichts veraendern? es sollte doch kein problem sein, am internetrouter eine vpn-verbindung einzurichten, wenn der router das unterstuetzt.

ansonsten gibt es auch noch andere moeglichkeiten, eine vpn-verbindung einzurichten!

tschuess

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.