Du weißt doch, was du an Grundbedarf hast. Das kannst du doch auch schon tagsüber einstellen, dass der das abgibt. Wenn immer z.B. 200 W benötigt werden, würde ich doch den schon morgens die 200 W abgeben lassen, dann ist der auch nicht so schnell voll.
6-8 Stunden würd ich nun nicht als “so schnell” bezeichnen…
Mit den Entladezeiten versuche ich gerade rudimentär zu “steuern”, hängt aber immer am Tagesertrag und benötigtem Verbrauch.
Stimmt, dafür das es nur zwei 245er Panel sind bin ich zufrieden.
Gestern abend hat sich mein B2500 plötzlich ausgeschaltet. Während es anfing zu gewittern, aber keine Ahnung ob das nur ein Zufall war.
Reboot, etc, hat erstmal nichts geändert, der Speicher war nichtmehr zu erreichen, weder über WLAN noch vi BT mit der App.
Heute morgen kam er dann mit dem ersten PV-Ertrag doch wieder online. Hat aber weder geladen, noch eingespeist. Reboot, Hardwarereset… jetzt kriege ich den SoC mit 0% angezeigt (wegen dem Hardwarereset?) aber der Speicher lädt nicht. Von den Panels kommen nur 1-4W, trotz bedektem Tag heute sollten es aber trotzdem 50-100W sein. Auch wenn zwischendrin mal kurz die Sonne stärker rauskommt, ändert sich nichts.
Min_Temp und max_temp meldet 0°C, was aber nicht sein kann, aber evtl. das Laden verhindert? Die Temperaturen ändern sich allerdings auch nicht.
Jemand eine Idee, was man noch tun könnte?
Bin mal gespannt ob sich das wieder irgendwie einkriegt…
Der Speicher hat sich wieder eingekriegt.
Irgendwann hat er wieder angefangen zu laden. Zumindest hat der PV-Eingang was angezeigt. Nach einiger Zeit war das dann wieder vorbei und der Eingang schwankte wieder nur zwischen 0 und 4W.
Nach einem erneutem Neustart ist er dann aber wieder zum Leben erwacht, der SoC hat in mehreren Schritten auf 100% hochgezählt und auch der Ouput wurde wieder aktiv.
Soweit so gut.
Gerade eben: Wieder ein Gewitter, Speicher prompt wieder “tot”. Mit dem kleinen Unterschied, das noch Tageslicht vorhanden ist und der Input jetzt wieder bei 0-4W rumdümpelt. Online ist er also noch. Aber ich vermute das wird sich heute Nacht noch ändern.
Meine Theorie:
Der Speicher ist wohl doch nicht so ganz IP65, oder zumindest nicht mehr, die bisherigen 7 Monate hatte ich das Problem nicht.
Bei den kurzen aber heftigen Regenschauern dringt wohl doch irgendwo Wasser ein und verursacht ggf. sogar einen Kurzschluss. Das BMS schaltet daraufhin den Akku ab.
Die restliche Elektronik kann dann nur noch mit PV-Strom laufen (sofern vorhanden). Die pulsenden 0-4W sind das was die Elektronik verbraucht um weiterzulaufen. Nachts geht dann natürlich überhaupt nichts mehr solange das BMS aus bleibt.
Wenn dann irgendwann das Wasser wieder weg/verdunstet ist schaltet das BMS wieder ein und der Akku läuft wieder normal. Ggf. brauchts einen Neustart, damit das BMS tatsächlich wieder einschaltet.
Es wäre halt “schön”, wenn der Akku das irgendwie als Fehler melden würde oder halt irgendwas, an dem man erahnen könnte, was los ist.
Das 0-4W-Problem scheint “bekannt” zu sein. Wenn man danach googelt, findet man zumindest einiges. Allerdings habe ich bisher nur das Symptom gefunden. Was das eigentliche Problem ist hat wohl noch niemand rausgefunden.
Edit: Ja, wie erwartet, jetzt wo die Sonne weg ist, ist er offline.
Hallo zusammen,
mein B2500 ist plötzlich offline.
[12:06:40] DEBUG: Published to hame_energy/HMJ-2/App/nnnnnnnn/ctrl: cd=1
[12:06:40] DEBUG: Published to marstek_energy/HMJ-2/App/xxxxxxxxxxxxxxxxx/ctrl: cd=1
[12:07:10] WARN: No response received from nnnnnnnn within timeout period
Bis gestern lief er problemlos über die hm2mqtt-Integration als HMJ-2.
Alle Versuche, ihn zum Laufen zu bringen, schlugen fehl.
hm2mqtt neu gestartet –> kein Erfolg.
mosquitto neu gestartet –> kein Erfolg.
HA neu gestartet –> kein Erfolg.
Hat jemand ein Idee, was passiert sein könnte und wie man die Intergation wieder zum Laufen bringen kann?
Danke!
Den Marstek schon mal komplett abgeschaltet und wieder ein?
Noch nicht. Ist eine Idee. Danke.
Du meinst das 10 Sekunden drücken?
Ja. Bis die Led ausgeht. Danach wieder an.
Kann dann aber a bisserl dauern bis was kommt
Wenn ich die HA-Verbindung zum Speicher verliere, ist eigentlich das erste was ich mache immer mit der App via BT nachgucken, ob er damit noch erreichbar ist. Dazu muss man natürlich in der Nähe des Speichers sein.
Dann kann man den Speicher auch über die App neustarten.
Edit: Die App zeigt dir übrigens auch an, ob der Speicher eine WLAN-Verbindung hat (oder eben auch nicht). Wie schon öfter angemerkt wurde, ist die WLAN-Leistung des B2500 absolut unterirdisch. Leider zeigt nichts die Verbindungsqualität an. Weder die App noch die MQTT-Anbindung.
Und wenn du mit BT via App den Speicher schon nichtmehr findest, dann liegt das Problem nicht an deinem HA.
Ich habe den Eindruck, bei mir hat sich eine temporäre Anomalie manifestiert! 
Gestern um 22:45 Uhr (wärend einer normalen Entladeperiode) war der Akku ohn weiteres Zutun wieder aktiv. Als wäre nichts geschehen. Vorher hat es keine Aktivitäten meinerseits gegeben. Auffällig war nur, dass der Soc auf 0% stand.
Heute morgen war der Akku immer noch online und der SoC sprang von 0 auf 98%.
Für mich nicht erklärbar, aber was soll’s - jetzt schint wieder alles zu funktionieren.
Danke an die Tippgeber. Ich konnte den Restart (physisch oder per App) nicht testen, da ich im Moment unterwegs bin.
Also ich verwende auch hm2mqtt seit geraumer Zeit und hatte auch oft Verbindungsabbrüche. Ich habe dann den ESP dicht am Akku platziert und seitdem nicht einen einzigen Verbindungsabbruch gehabt. Warum das besser ist. Bluetooth hat nur eine geringe Reichweite, Wlan in der Regel eine höhere Reichweite. Die Daten kommen vom Akku über Bluetooth zum ESP, dieser leitet dann alles per Wlan zum HA weiter. Vielleicht hast du eine ähnliche Konstellation und es hilft.
Ich bin bei der Einrichtung dem Video und dem Blog von Simon gefolgt. Das hat wunderbar funktioniert. Einen ESP habe ich dafür nicht benutzt und ist auch nicht Einsatz.
In der Regel funktioniert alles problemlos.
Manchmal habe ich nur den Eindruck, dass Einstellungen, die ich in HA ändere (z.B. Entladezeiten), nur sehr verzögert im Akku ankommen.
Das war bei mir nach einem Hardwarereset der Fall. Der SoC meldet 0%, wohl weil das System dann keine Ahnung mehr hat, welchen Ladezustand der Akku hat. Der Akku war aber online, der Speicher war auch Nachts erreichbar, wurde also via Akku versorgt und hat tagsüber auch geladen, obwohl der SoC bei 0% blieb. Als der Akku dann voll war und ich den Akku nochmal neugestartet habe, ist er auf 100% gesprungen und hat auf einmal wieder normal funktioniert.
Während dieser “undefinierten” Phasen, stand auch die ganze Zeit min und max_Temperatur auf 0°C.
Ich verstehe auch nicht, was Marstek für Probleme mit dem ständig abdriftendem SoC hat. Ich rechne mir in HA einfach meinen eigenen SoC aus indem ich die Bat-In gegen die Bat-Out-Werte verrechne, also Werte die ja der Speicher selber misst und meldet. Der dadurch ermittelte SoC ist 1000mal genauer als diese “Schätzung” die Marstek abliefert, driftet fast gar nicht und Resettet sich auch nach irgendwelchen Problem nicht sonstwohin…
Nach meiner Beobachtung ist das “normal”.
Ich frage den Akku alle 15s ab. Wenn ich einen Wert ändere, z.B. DoD dann wird die wohl erst mit der nächsten Abfrage zum Akku geschickt, der Akku meldet aber im gleichen Zug den vorherigen Wert nochmal zurück, die Anzeige in HA springt dadurch wieder auf den alten Wert und erst nach der nächsten 15-Sekündigen Abfrage meldet der Akku dann wirklich den neuen Wert und HA zeigt dann auch wieder den neueingestellten Wert wieder an.
Wie machst du das mit dem errechneten SOC? Über eine Automation? Würdest du das teilen?
Ne, viel einfacher.
Ich hab einen Helper-Sensor namens “BatIn” vom Typ Utility Meter auf den Sensor “Daily Battery Charging” des Speichers eingerichtet. Der zählt also immer weiter hoch. Somit weiß ich auch jederzeit wieviel Strom insgesamt schon in den Akku geflossen ist.
Das gleiche dann natürlich nochmal mit Namen “BatOut” auf den Sensor “Daily Battery Discharge”.
Und dann einfach noch einen Template Sensor der einfach “BatIn - BatOut + Offset” rechnet.
Das Offset ermittelt man halt einmal, wenn der Speicher voll ist.
Und alle heilige Zeit korrigiert man das Offset halt, wenn der Speicher mal wieder voll ist.
Theoretisch könnte man sich auch noch einen Template Sensor “BatSoCOffset” einrichten, der immer wenn der Originale SoC 100% erreicht die Differenz updated, dann würde sich der manuell errechnete Offset sogar jedesmal automatisch selbst korrigieren, wenn der Speicher mal wieder voll wurde.
Okay danke. Das baue ich mal nach. Ich überlege nur, ob man nicht auch auf den Offset verzichten kann bzw ich check noch nicht, warum er regelmäßig angepasst werden muss.
Die beiden Utility Meter BatIn und -Out Werte starten ja jeweils “mitzuzählen” sobald du sie jeweils anlegst. Die sind also nicht zwangsläufig abgeglichen.
Die “starten” also z.B. mit 800Wh BatIn und 820Wh BatOut, weil du an diesem Tag an dem du das gerade einrichtest halt gerade genau diese Werte hast.
BatIn - BatOut wäre in dem Fall dann aber -20Wh. Was wohl definitv nicht der richtige SoC ist. 
Wenn du dann einmal volllädst, weißt du aber, das jetzt 2240Wh im Akku sein müssten. Der errechnet SoC ohne Offset ist dann z.B. 1536Wh. Also musst du als Offset 2240-1536 = +704Wh einrechnen. Dann steht dein manueller SoC auch bei genau 2240Wh.
Wenn ich 2-3 Zyklen (also 4,4-6,6kWh “Durchsatz”) laufen habe, ohne zwischenzeitlich 100% zu erreichen, dann ist der vom Gerät gemeldet SoC gerne mal schon um 400-500Wh zu niedrig. Der SoC zeigt dann z.B. 40% (896Wh) an, obwohl eigentlich noch ~1300Wh im Akku wären.
Der selbst mitgerechnete SoC bleibt über diese Zeit auch nicht 100% genau, aber statt Abweichungen von 400-500Wh, liegt der nur um 20-30Wh daneben. Und das korrigiert man dann halt gelegentlich über den Offset nach. Theoretisch sinkt die Kapazität des Akkus mit der Zeit ja auch. Das kann man dann natürlich auch irgendwann mitkorrigieren oder überhaupt daran bemerken.
Das behebt aber natürlich leider nicht das Problem, das bei einem eingestelltem DoD von z.B. 10% der Speicher den Output bei seinen selbst ermittelten 10% (224Wh) abschaltet, obwohl ja noch z.B. 650Wh drin wären.
Das Problem hatte ich vorallem im Winter, wenn da durchaus mal 1-2 Wochen lang nie 100% erreicht wurden, aber trotzdem jeden Tag 500Wh rein und raus gingen. Wenn du den Speicher dann nicht mal voll werden lässt, nur damit sich der SoC wieder korrigiert, wirst du feststellen, das der Speicher irgendwann 20% SoC meldet, obwohl eigentlich 80% drin wären. Das ist dann auch der bekannte Effekt das der Akku beim Laden durchaus mal von 30% auf 100% springt.
Man kann es auch ohne derartige Helferlein sehen. Ich hatte im Winter z.B. 40% DoD eingestellt. Der Tag fing also bei 40% an und Abends hat der Output bei 40% wieder ausgeschaltet. Daily Charging hat aber 600Wh gezählt, der Daily Discharge aber nur 400Wh… wo sind die fehlenden 200Wh hin (mal abgesehen von Wandlungsverlusten natürlich)? Genau, die sind nicht verschwunden, sondern der SoC ist mal wieder um 200Wh abgedriftet.
Danke dir für die ausführliche Antwort.
Habe mir die 2 Helper mal eingerichtet und warte jetzt auf den nächsten Drift.
Ja das mit dem DOD ist dann wirklich irgendwie doof, man kann das auch nicht verhindern, indem man ihn auf 100 stellt und einfach den Output auf 0 dreht, oder? Ich denke 80W ist Minimum und ich wüsste keinen Weg den komplett abzuschalten, oder?
EDIT: Oder könnte man die time period deaktivieren oder das zeitfenster so anpassen, dass es grad nicht gültig ist?!