MatzeTF

Die Signalquelle ist EEBUS. Die Kommunikation zwischen WEM und Wallbox erfolgt nicht über EEBUS. Steuerbox ↔ EEBUS ↔ WEM ↔ WARP-Lastmanagement ↔ Wallbox Du musst allerdings im obigen Screenshot die Option für die kontrollierten Wallboxen aktivieren, damit das funktioniert.

Hast du schon wokelnschauflers Tipp ausprobiert? Unter Schnittstellen → Modbus/TCP den Keba-Modus aktivieren und dann bei FENECON eine Keba-Wallbox hinzufügen.

Was genau möchtest du damit erreichen? Der WEM steuert Wallboxen nicht über EEBUS, sondern nur über das WARP-Lastmanagement. Wenn ich das richtig sehe, ist die Wallbox bereits im Lastmanagement eingetragen.

Wie viel ist „über 6A“? Mehr so 7A oder 16A? Starte mal eine Ladung im PV-Modus und wenn dein Auto nach ein paar Minuten immer noch nicht so schnell lädt, wie du es erwartest, lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Was heißt „deaktiviert“? Hast du die Sicherung vom Speicher rausgeworfen?

Das Sichtfenster ist nur für die noch nicht verfügbare Eichrechts-Variante relevant, da es dort vorgeschrieben ist, dass der Zähler von außen ablesbar sein muss. Bei der MID-geeichten Pro-Variante ist das Fenster nur vorhanden, damit sich niemand beschwert, den Zähler nicht ablesen zu können. Im Gehäuse ist nämlich nicht genug Platz, um den Zähler so einzubauen, dass man ihn bei abgenommener Frontplatte ablesen könnte. Außer, dass du den Zähler nicht direkt ablesen kannst, hat das keine anderen Konsequenzen für dich.

In nicht luftdichten Verteilerdosen sammelt sich doch auch kein Kondenswasser, oder? Ansonsten: Vielleicht tut’s auch eine Ladung Fugensilikon aus dem Baumarkt, wenn man nichts anderes hat. 🤷

Laut Debug-Report hast du eine Pro. Anscheinend fehlt einfach nur das Fenster, sodass du den Zähler nicht direkt ablesen kannst und die Werte nur im Webinterface der Wallbox siehst. Ist das für dich okay? Ich leite das mal an die Mitarbeiter in der Produktion weiter, damit deine Wallbox ein Einzelstück bleibt. 😉

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.