MatzeTF

Lade bitte einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Für die Wallbox gibt es bei den Downloads eine Bohrschablone mit Maßen.

Dann weiß ich leider auch nicht, wo das Problem liegen könnte.

Die Einstellungen sehen erstmal korrekt aus. Kannst du mal mit mosquitto_sub nachsehen, ob unter warp3/2i5B/# Nachrichten reinkommen und ob unter homeassistant/# irgendwas mit 2i5B im Namen steht?

20 A ist richtig für ein 2,5 mm²-Kabel. Die Beschriftung auf der Platine ist falsch; da hätten 20A und 32A stehen sollen.

Genau das ist das Problem dabei.

Dein EEBUS ist nicht richtig eingerichtet. Der Kollege meinte dazu:

Lade mal einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Die Smart hat keinen integrierten Stromzähler und kann somit nicht die tatsächliche Ladeleistung messen und hat dementsprechend keine Energieangaben im Ladeprotokoll. Manche Nutzer überrascht das. Ebenso kann sie ohne Zähler den SoC des Autos nicht sinnvoll anzeigen. Brauchst du keine dieser Funktionen, sollte die Smart reichen.

Verbinden von PP. Manche Autohersteller schauen fälschlicherweise auf PP und nicht CP, um die Verbindung zur Wallbox zu erkennen. …und ignorieren dadurch auch den Fall, dass man sein Ladekabel aus einer Wallbox mit Steckdose ausstecken und in eine andere Wallbox einstecken könnte, ohne den Stecker aus dem Auto zu ziehen. 🙄

Wenn dein Batteriespeicher bzw. Wechselrichter auf unserer Liste der kompatiblen Geräte steht, kannst du eine Automatisierungsregel anlegen, die bei einem gewissen Batteriestand in den reinen PV-Modus wechselt. Ist dann keine PV-Leistung vorhanden, wird die Ladung beendet. Du kannst anschließend manuell über die Octopus-App einen Ladevorgang planen, musst allerdings auch den Lademodus der Wallbox auf „Schnell“ ändern, damit die Wallbox einfach nur Strom freigibt und die Octopus-App die Ladung steuern kann. Den Energy Manager brauchst du dafür nicht; alles oben beschriebene kann der WARP Charger selbst.

Aus den Octopus Energy FAQs: Wenn du ein E-Auto der gelisteten Marken hast, sollte die Wallbox egal sein und somit auch ein WARP Charger funktionieren. Hast du kein E-Auto der gelisteten Marken, wird es mit einem WARP Charger nicht funktionieren, da sie nur zwei Wallboxhersteller unterstützen.

Schau mal auf das Webinterface der Wallbox, wenn du ein Fahrzeug absteckst. Springt der Ladestatus sofort auf „Getrennt” oder nur mit Verzögerung? Ansonsten ist das ein bekanntes Problem von EVCC, da das seinen internen Zustand nur in relativ groben Schritten aktualisiert. Die Wallbox stellt den Ladestatus mit Sekundenpräzision zur Verfügung, aber was EVCC und openHAB damit machen, kann sie nicht beeinflussen.

👍 Die Stacknutzung (der mittlere Wert) erhöht sich immer, wenn das erste mal ein mDNS-Paket empfangen wurde, das größer bzw. komplexer als die bisherigen ist. Somit hängt es ganz von den anderen Geräten ab, wie schnell die Stacknutzung wächst. Wird direkt nach einem Neustart das größte Paket empfangen, spring die Stacknutzung sofort auf das Maximum und es ändert sich dann nichts mehr. Werden erst andere Pakete empfangen, wächst die Stacknutzung langsam. Ohne zu wissen, von welchen Geräten welche Pakete kommen, hilft das also nicht weiter. Wenn du neugierig bist und du zu viel Zeit hast, kann ich dir eine Firmware bauen, die loggt, wann sich die Stacknutzung erhöht. Dann könntest du mit Port-Mirroring alle mDNS-Pakete loggen und nachsehen, welche Pakete es jeweils zu den Zeitpunkten waren, die die Stacknutzung erhöht haben. Damit könntest du gewissermaßen den „Übeltäter“ finden. Außer unsere Neugierde zu befriedigen macht es unterm Stricht aber keinen Unterschied, solange ich einfach die passende maximale Stacknutzung kenne, unabhängig vom Verursacher.

Du hast nicht zufällig vor dem Neustart heute morgen nach den Zahlen geschaut? Ich brauche den größten jemals gesehenen mittleren Wert und bei einem Neustart wird der Wert zurückgesetzt. 4280 ist weniger als der Wert von gestern Abend und hilft mir somit nicht weiter. Falls du nochmal neustarten musst, schau bitte vorher nach dem mittleren Wert und poste ihn hier, falls du mehr als 4312 siehst. Einen Debug-Report brauchst du nicht posten; der eine Wert reicht mir. Bitte schau auch vor deinem Urlaub nochmal danach und poste, ob und wie weit sich der Wert noch erhöht hat. Die ganzen auf -1 endenden Einträge sind Zeitüberschreitungen und die entsprechende Anfrage wird einfach wiederholt. Somit kannst du die bei der aktuellen Menge prinzipiell ignorieren. Im Zusammenhang mit den ganzen EEBUS-Verbindungen sehen wir uns das aber trotzdem mal an.

Wahrscheinlich wird das einfach funktionieren. Falls nicht, melde dich hier und wir sehen uns das an.

Ich habe die Stackgröße von 4096 auf 8192 erhöht. Da die maximale Stacknutzung aktuell bei 4312 Bytes liegt, hätte es mit der vorigen Firmware also bereits einen Crash gegeben. Lass das mal weiter laufen und beobachte, wie weit sich die Stacknutzung noch erhöht. Abhängig davon werde ich die neue Stackgröße festlegen. Die 8192 habe ich zum Testen absichtlich hoch angesetzt. Meine Vermutung ist, dass irgendein Gerät in deinem Netzwerk ein mDNS-Paket sendet, das viel Stack-Speicher zum Parsen braucht. Das würde zumindest erklären, warum außer dir kaum jemand das Problem hat und warum wir das hier nicht reproduzieren können: Wir haben dieses andere Gerät einfach nicht. Zum Vergleich: Bei mir liegt die maximale mDNS-Stacknutzung gerade bei 3680 Bytes, also unter dem bisherigen Limit von 4096 Bytes.

Das ist ein Ladeprotokoll. Bitte lade unter System → Ereignis-Log einen Debug-Report runter und hänge ihn hier an.

@CptHildi Danke fürs Ausprobieren. Wie sieht es ohne mDNS mit Crashes aus? Falls es mit ausgeschaltetem mDNS bisher keinen Crash gab, teste bitte diese Firmware und aktiviere mDNS wieder. Bei dieser Version findest du im Webinterface unter System den Punkt „Debug“. Im Abschnitt „Stack-Hochwassermarken“ sollte es eine Zeile namens „mdns“ geben. Die Stackgröße sollte dort als 8.192 B angezeigt werden. Lass das mal eine Weile laufen und wenn es nicht crasht, poste hier mal den Wert von mdns unter „Genutzter Stack“. Falls du morgen in den Urlaub fährst, würde es mir sehr helfen, wenn du vorher noch einmal diesen Wert postest. Alternativ postest du dann nochmal einen frischen Debug-Report, in dem der Wert auch enthalten ist. warp3_firmware_2_12_1_6a7471a0_3e374682bcdeabe_merged.bin

Wir brauchen einen Debug-Report, der nicht älter als ca. 40 Minuten nach den Ladeproblemen sein sollte. Prinzipiell sind keine privaten Daten wie z.B. Passwörter oder Mailadressen enthalten. Es stehen aber selbst vergebene Namen drin, wie z.B. der Wallboxname. Wenn du da deine komplette Adresse oder sowas reingeschrieben hast, würde das mit im Debug-Report stehen. Wenn du möchtest, kannst du dir den Debug-Report auch selbst ansehen. Das ist eine Textdatei, die zugegebenermaßen ohne Übung nicht gut verständlich ist. Eventuell unlesbarer Buchstabensalat am Ende der Datei enthält keine privaten Daten sondern Informationen über einen Crash, falls es einen gab.

Kannst du mal diese Firmware testen, falls du vor deinem Urlaub noch Zeit hast? Darin enthalten sind ein paar Änderungen an der Verwaltung von WebSocket-Verbindungen, bei der es vorher Netzwerkprobleme geben konnte. Edit: Veraltete Firmware entfernt.

Deswegen habe ich immer die momentane maximale Ladeleistung erwähnt. Wenn der Speicher fast voll oder zu warm ist, reduziert er seine maximale Ladeleistung (oder sollte das zumindest tun) und die eingestellte maximale Ladeleistung ist irrelevant. Außerdem nutzt nicht jeder die Batteriesteuerung und selbst wenn die Batteriesteuerung benutzt wird, muss nicht für jeden Speichertyp überhaupt die maximale Ladeleistung eingestellt werden. Bei vielen Speichern nutzen wir die Einstellung „unbegrenzt“. Leider nicht. Das liegt auf meinem Schreibtisch und ich war, wie rtrbt sagte, im Urlaub. Bisher kann ich das Problem hier auch noch nicht reproduzieren und da es anscheinend nur wenige Nutzer betrifft, statt weit verbreitet zu sein, vermute ich irgendeinen Zusammenhang mit lokalen Gegebenheiten im Netzwerk. Wir hatten z. B. mal einen Crash aufgrund von Jumbo Frames, die ein Nutzer in seinem Netz hatte, wir hier aber nicht und auch sonst kein Nutzer. Das habe ich nur durch Glaskugel und Kaffeesatz gefunden. 🙈 Edit zu dieser Frage: Das liegt daran, dass nach dem Anstecken die Willkommensladung läuft und nach einem Stop/Start nicht. Wegen dem beschriebenen Effekt bleibt die Ladeleistung immer im letzten Zustand hängen, also entweder ladend oder wartend.

Das ist ein bekannter Seiteneffekt vom PV-Überschussladen. Die Wallbox kennt nur den momentanen Überschuss am Netzanschluss und optional die momentane Speicherleistung. In deinem Fall sieht die Wallbox, dass der Netzanschluss ausgeglichen ist und die Batterie ihr Ding macht. Somit gibt es für sie keinen Grund, irgendwas zu ändern. Du weißt, dass der Speicher gerade auch mehr laden könnte und die Wallbox die Fahrzeug-Ladeleistung reduzieren sollte. Genau das weiß die Wallbox aber nicht, da sie dafür die momentan maximal mögliche Ladeleistung des Speichers wissen müsste, die sie aber nicht kennt. Du kannst diesen Effekt verringern, indem du bei den Einstellungen für das PV-Überschussladen das Regelverhalten auf einen der konservativen Werte änderst. In diesem Fall lässt die Wallbox immer die entsprechende Leistung übrig, die dann der Speicher nehmen kann. Das wiederholt sich dann so lange, bis sich einer von zwei stabilen Fällen einstellt: Der Speicher hat seine momentan maximale Ladeleistung erreicht und die eingestellte Regelleistung wird ins Netz eingespeist. Der restliche Überschuss geht ins Fahrzeug. Der Speicher beansprucht so viel Leistung, dass die minimale Ladeleistung der Wallbox unterschritten und die Ladung beendet wird. Das Regelverhalten beeinflusst, wie schnell sich einer dieser Fälle einstellt. Bei - 50 W dauert es länger, dafür wird weniger Leistung permanent ins Netz eingespeist. Bei - 200 W wird das Ziel schneller erreicht, dafür aber auch mehr Leistung permanent eingespeist. Zu deinem ursprünglichen Problem: Wie ich schon in dem anderen Thread schrieb, ist es nicht vorgesehen, dass es Überschuss gibt, den die Wallbox nicht nutzen kann. Der Workaround aus dem Thread ist aktuell die einzig sinnvolle Lösung. Für eine bessere Lösung müssten die momentane und maximale AC-Wechselrichterleistung bekannt sein. Ersteres rückt nicht jeder Hybrid-Wechselrichter raus und zweiteres ist manch unbedarftem Nutzer nicht mal bekannt.

Im von dir geposteten Debug-Report kann ich das so nicht sehen. Im Graphen von rtrbt sieht man, dass der Netzbezug die meiste Zeit gut ausgeglichen ist und im Durchschnitt ein paar Watt Bezug meldet. Der Batteriespeicher gleicht den gepulsten Verbraucher gut aus. Da der Speicher immer wieder entladen wird und bei der Wallbox das PV-Überschussladen so eingestellt ist, dass der Speicher bevorzugt wird, gehe ich davon aus, dass einfach der gesamte Überschuss in den Speicher geht und die Wallbox deswegen nicht lädt. Wird eine Ladung freigegeben, wenn der Speicher voll ist und weiter PV-Überschuss da ist?

Bei den Zählereinstellungen kannst du sehen, dass als SunSpec-Modell „Wechselrichter [101]“ gefunden wurde. Wie der Name schon sagt, ist das nur für Wechselrichter, weshalb der Messort fest auf „Wechselrichter“ eingestellt ist. Laut Spezifikation liefert das Modell auch nur positive Werte für die Wechselrichterleistung, die bei uns immer negativ als Einspeisung angezeigt wird. Für einen Netzbezugszähler braucht man aber einen vorzeichenbehafteten Leistungswert, der je nach Bezug oder Einspeisung positiv oder negativ ist. Mich würde wundern, wenn das tatsächlich die Werte vom Netzanschluss sind. Zähler 2 und 3 liefern ungefähr die gleichen Werte und 1 und 4 liefern ebenfalls ungefähr die gleichen Werte, die in deinem ersten Screenshot ca. 200 W höher als die von 2 und 3 liegen. Ich vermute stark, dass 2 und 3 einfach die Wechselrichterwerte sind, 1 und 4 die vom Netzanschluss sind und du zum Zeitpunkt des Screenshots ca. 200 W Eigenverbrauch hattest. Zähler 1 sollte also das sein, was du für PV-Überschussladen nutzen kannst.