MatzeTF

Wenn das kein Standardformat wie z. B. JSON ist, wirst du das selbst auseinandernehmen müssen. Dafür haben wir aktuell nichts. Es gibt vom Arduino ESP32-Framework aber sicherlich einen TCP-Server, den du dafür benutzen kannst. Du musst dann ein Modul in unserer Firmware anlegen und in der (pre_)setup-Phase den TCP-Server starten und entweder per Callbacks oder polling in der loop-Funktion eingehende Daten behandeln.

Mit reinen Strings statt JSON könnte man das ggf. machen, aber wenn du einfach nur einen Port mit Daten bewerfen willst, kannst du die Config-Objekte nicht nutzen. Läuft das Ganze überhaupt über TCP oder UDP? Vermutlich wirst du nach einer TCP- oder UDP-Server Lösung mit dem Arduino ESP32-Framework suchen müssen, das wir verwenden. Für UDP kannst du auch einen Blick in cm_protokoll.cpp werfen und nach „recvfrom“ suchen. Das ist aber nicht sehr einsteigerfreundlich.

@TMA84 @kagehisa Um das Problem weiter eingrenzen zu können, brauche ich ein Debug-Protokoll (System → Debug → Protokoll erstellen), auf dem der Schützfehler aufgezeichnet ist. 10 Sekunden vor der Phasenumschaltung, die das Problem verursacht, bis 10 Sekunden nach der Sicherheitsabschaltung reichen. Es wäre auch hilfreich, wenn ihr in Hörweite des Schützes das normale Ereignis-Log im Auge behaltet könntet und darauf achtet, zu welchem Zeitpunkt rund um das Auftreten des Fehlers ihr das Schütz schalten hört, also eher beim Auslösen der Schützüberwachung oder beim Übergang in „state 3“. Könnt ihr außerdem ein Foto machen, auf dem WEM, Schütz, die Verkabelung dazwischen und ggf. andere Geräte in direkter Nähe möglichst gut sichtbar sind? Was und wie hast du das gemessen? Hast du auf den Schraubkontakten vom Stecker am WEM gemessen, zwischen 12 V und Eingang 4? Welche Spannungen hast du gemessen? Im einphasigen Modus, also bei offenem Schütz, sollten da 11-12 V anliegen, im dreiphasigen Modus, also bei geschlossenem Schütz, nahe 0 V. Was mich am Fehler_log.txt verwundert, ist, dass der Schützfehler einfach so nach einiger Zeit aufgetreten ist, obwohl zu dem Zeitpunkt keine Phasenumschaltung durchgeführt wurde. 🤔 Hier wäre es sehr interessant, ob du irgendwas am Schütz hörst, wenn du die Einstellung in EVCC änderst, die das Problem verursacht. Zu schnell abspielen kann sich da eigentlich nichts. Während eine Phasenumschaltung durchgeführt wird, werden weitere Anfragen blockiert. Erst nach Abschluss der Umschaltung kann wieder eine neue Umschaltung angefordert werden und wenn man unbedingt möchte, kann man nach einer Umschaltung sofort die nächste anfordern, so oft man will. Das Schütz kann permanent angezogen bleiben, wenn EVCC das so möchte. Bei aktivierter externer Steuerung bleibt die Phasenumschaltung immer in dem Zustand, den EVCC als letztes angefordert hat. Hat EVCC dreiphasig angefordert und will 24 Stunden lang nichts anderes, bleibt das Schütz halt 24 Stunden angezogen.

Der Debug Brick ist nur zum Debuggen von allem im Stapel geeignet. Bei den alten Bricklets mit 10-poligem Stecker lief der Code auf einem Master-Brick, sodass man die auch damit debuggen konnte. XMC-basierte Bricklets mit 7-poligem Stecker kann man damit leider nicht debuggen. Zum Debuggen deines XMC-Codes kannst du die serielle Schnittstelle vom Logger auf einen Pin legen und dort einen TTL-Seriell-zu-USB-Wandler anschließen.

EVCC kann mit einem Schützfehler eigentlich nichts zu tun haben, da Ansteuerung und Überwachung vom Schütz hardwareseitig passieren. Die Logik dafür ist auch recht trivial: Der Zustand vom Überwachungskontakt muss der gewünschten Schaltstellung vom Schütz entsprechend. Während des Umschaltens gibt es eine Totzeit von 0,5 s oder so. Das ist üblicherweise ausreichend, da das Schütz innerhalb von 0,1 s reagieren sollte. Dass der Schützfehler nach einem Neustart weg war, ist zu erwarten. Sobald ein Fehler erkannt wird, bleibt der EM permanent im Fehlerzustand, damit man auch bemerkt, dass es ein Problem gab. War das Problem nur temporär, ist nach einem Neustart erstmal alles ok. Es kann allerdings sein, dass dann bei der ersten Phasenumschaltung auf dreiphasig wieder ein Schützfehler erkannt wird. Die häufigste Ursache für sporadische Schützfehler sind schlechte Verbindungen. Anhand deiner anderen Posts vermute ich, dass du auch ein Bastler bist. Kontrolliere doch mal alle Schraub- und Steckverbindungen von EM und Schütz, insbesondere der Schützüberwachung, ob irgendwo ein Draht neben der Klemme locker anliegt oder die Isolierung mit unter der Klemme sitzt. Wenn das Problem nochmal auftritt, schau mal ins Ereignis-Log und poste das hier. Da sollte stehen, wann ein Schützfehler aufgetreten ist und wann er wieder verschwunden ist, in Relation zu den eigentlichen Schritten der Phasenumschaltung.

Sekundenkleber ist leider kein guter Wärmeleiter und daher nicht zu empfehlen. Du brauchst entweder Wärmeleitkleber oder selbstklebende Wärmeleitpads. Für beides solltest du die Reste vom alten Wärmeleitkleber abkratzen. Für Pads sollten auf Chip und Kühlkörper keine Reste mehr sein. Falls klein Reste bleiben, ist Wärmeleitkleber wahrscheinlich die bessere Wahl.

Hast du dir schon das Tutorial zur ESP32 Firmware angesehen? Fast die gesamte Firmware verwendet das Konzept, dass Config-Objekte angelegt und unter bestimmten URLs registriert werden. Als Konvention wird "/config" für speicherbare Einstellungen, die einen Neustart überleben sollen, verwendet, und "/state" für Laufzeit-Zustände. Im Tutorial wird eine Config unter "tutorial_phase_#/config" und "tutorial_phase_#/config_update" registriert und enthält den Wert "color", der ein String sein muss. Über HTTP übertragen wird das Ganze als JSON. Du könntest dir also eine Config bauen, die die von dir benötigten Werte enthält, und mit api.addCommand() einen Handler dafür registrierten, der beim Setzen der Config ausgeführt wird. Daten schickst du dann einfach JSON-formatiert an die entsprechende URL. PC-seitig verwendest du entweder auch eine JSON-Bibliothek oder du baust dir triviales JSON selbst zusammen. Wie das aussehen muss, siehst du, wenn du die per api.addState() registrierte Adresse im Browser öffnest. Falls dein Browser das hübsch formatiert, musst du noch die Rohansicht im Browser auswählen.

Offiziell gibt es eine solche Tabelle nicht. Ich kann natürlich nicht ausschließen, dass sich schon jemand anders die Mühe gemacht hat, allerdings weiß ich davon nichts. Wir hatten auch schon daran gedacht, die API zwischen den Bricklets zu vereinheitlichen. Leider ist das alles historisch gewachsen und deshalb nicht einheitlich. Rückblickend würden wir das sicherlich anders machen. Aktuell ist da noch nichts geplant, da wir im Moment nicht die Zeit haben, bei den Bricklets alles umzuwerfen.

Hier noch ein paar Infos zur neuen Zähler-API. Aktuell sollten die meisten externen Anwendungen über die Legacy API weiter funktionieren. Wir empfehlen allerdings, auf die neue API zu wechseln. Bisher gab es die Endpunkte meter/values und meter/all_values, die intern auf zwei verschiedenen Datensätzen gearbeitet haben. Dabei gab es zwei Werte (power, energy_abs), die in beiden Datensätzen vorkamen, und unterschiedliche Werte annehme konnten. Zusätzlich gab es Werte, die nur in einem der beiden Datensätze vorkamen, sodass man eigentlich immer beide aktualisieren musste. Jetzt gibt es nur noch einen Satz Werte unter meters/#/values (# ist die Null-basierte Zählernummer), der allerdings je nach Fähigkeiten des Zählers unterschiedliche Werte enthalten kann. Welche das sind, findet man unter meters/#/value_ids raus. Dort finden sich in der gleichen Reihenfolge IDs, die den Typ des Zählerwertes in meters/#/values angeben. Alle Typen sind aktuell in unserem „esp32-firmware“ git in der Datei software/src/modules/meters/meter_value_id.csv dokumentiert. Entweder sucht man sich die „interessanten“ Werte raus, oder man bindet die CSV-Datei ein, um die Werte automatisch parsen zu lassen. Bei vielen Werten gibt es draw/Bezug bzw. feed/Einspeisung, die dem Messwert für die jeweilige Richtung entsprechen. Dazu gibt es noch „draw plus feed“/„Bezug plus Einspeisung“, was jeweils ein Absolutwert von Bezug und Einspeisung ist. Beispielsweise sind die Phasenströme immer positiv, egal ob Energy bezogen oder eingespeist wird. Dann gibt es noch „draw minus feed“/„Bezug minus Einspeisung“, was der meist sinnvollere vorzeichenbehaftete Wert ist: Bezug ist positiv, Einspeisung ist negativ. Wichtig ist da insbesondere „Wirkleistung (Bezug minus Einspeisung), Σ L1, L2, L3“, was die vorzeichenbehaftete Bezugsleistung summiert über alle drei Phasen ist. Das ist der Wert, der von saldierenden Zählern für den Netzbezug verwendet wird und in der Wallbox die aktuelle Ladeleistung angibt und vom Energy Manager für PV-Überschussladen verwendet wird. Mit der alten API war es prinzipiell möglich, die Werte des Wallbox-internen Zählers zu überschreiben, allerdings haben dann API und Zähler gegeneinander gekämpft und sich gegenseitig die Werte überschrieben. Das ist nun nicht mehr möglich, sondern über meters/#/values kann man die Werte von realen Zählern nur auslesen. Möchte man werte über die API setzen, z. B. weil man den Ladestrom der Wallbox extern misst oder bereits einen anderen Zähler am Hausanschluss hat, mit dessen Werte man den Energy Manager füttern möchte, muss man über das Webinterface einen Zähler vom Typ „API“ anlegen und die Werte auswählen, die man setzen möchte. Entweder kann man sich die Werte einzeln raussuchen, oder man wählt eine der SDM-Vorlagen aus, die man entweder komplett verwendet, oder man wirft die Werte raus, die man nicht nutzen möchte. Anschließend kann man ein JSON-Array mit den Werten an meters/#/update schicken. Hat man sechs Werte konfiguriert, schickt man „[111.111,222.222,333.333,444.444,555.555,666.666]“. Die Reihenfolge der Werte muss der Reihenfolge der im Webinterface konfigurierten Werte entsprechen. In der einfachsten Variante konfiguriert man nur den oben erwähnten Wert für die Wirkleistung und schickt ein Array mit einem Wert: „[111.111]“. Es ist nicht mehr notwendig, meter_type über die API zu setzen, da die gewünschten Werte fest konfiguriert werden und der API-Zähler nach dem Start sofort nutzbar ist. Die empfohlene Update-Frequenz ist weiterhin ein Update pro Sekunde. Die alte API, die jetzt Legacy API heißt, verwendet übrigens immer den ersten Zähler (also Position 0). Wenn man seinen Energy Manager schon auf „Benutzerdefinierter Zähler“ eingestellt hatte, wird bei einem Firmware-Update automatisch als erster Zähler ein API-Zähler eingerichtet, der über die Legacy API befüllt werden kann. Wer seine Wallbox bisher über die API mit Zählerwerten versorgt hat, muss einmal den standardmäßig an erster Stelle eingerichteten Wallbox-internen Zähler löschen (bzw. editieren) und durch einen API-Zähler ersetzen. Das gilt auch für Smart-Wallboxen, die für einen internen Zähler vorkonfiguriert sind. Für WARP1-Nutzer: Wer sich einen Zähler nach- oder umrüstet, muss nicht mehr händisch über die API override_meter_type setzen. Wenn der Zähler nicht automatisch korrekt erkannt wird, kann der richtige Typ einfach über das Webinterface eingestellt werden. Wer seinen Zähler regelmäßig über das Webinterface zurücksetzt, wird feststellen, dass sich der rücksetzbare Wert ändert und plötzlich viel größer ist. Das liegt daran, dass bisher nicht der korrekte Wert vom Zähler dafür verwendet wurde (Import + Export) und jetzt der Korrekte (nur Import). Dafür wurde bisher aber noch kein Reset durchgeführt, weshalb der Wert dann zuerst dem Gesamtimport entspricht. Wer diesen Sprung nicht haben möchte, sollte das Update erst dann einspielen, wenn der nächste Zählerreset ansteht, z.B. am Monatswechsel.

Kannst du bei einem Login-Version den Traffic zwischen PC und Wallbox mit Wireshark mitschneiden und uns zukommen lassen? Wir können dann die Berechnungen nachvollziehen und herausfinden, an welcher Stelle irgendwer falsche Daten schickt. Ansonsten müssen wir noch deinen Benutzernamen kennen, da der mit in die Berechnung einfließt. Falls du den nicht öffentlich posten willst, kannst du mir auch eine private Nachricht schicken.

Ich konnte einen Windows-PC auftreiben und habe den Login mit Edge 120.0.2210.77 und Warp2 2.1.5 getestet, konnte dein Problem allerdings nicht reproduzieren. Als Passwort habe ich per Firefox „abcd!:.abcd“ gesetzt und konnte mich mit Edge problemlos einloggen. Du könntest testweise dein Passwort auf „abcd!:.abcd“ ändern und es dann nochmal probieren. Funktioniert es dann, hat dein eigentliches Wallbox-Passwort irgendeine Eigenschaft, mit der Edge in der aktuellen Version nicht zurechtzukommen scheint. Funktioniert es nicht, habe ich aktuell auch keine Idee.

Dann reicht es wahrscheinlich, wenn ich dich darauf hinweise, dass die Benutzeranmeldung der Wallbox kein POST verwendet, sondern HTTP Digest Authentication, bei der UTF-8 erwartet wird. 😉 Da (deutsches) Windows an vielen Stellen immer noch CP-1252 als Zeichensatz verwendet, war das auch nur eine spontane Vermutung meinerseits, die zumindest in diesem Fall nicht relevant war. Wir haben leider keine Version 120.0.2210.77 da und haben auch sonst noch nicht von Problemen gehört. Da HTTP Basic Auth komplett browserseitig berechnet wird, weiß ich gerade auch nicht, wie wir das debuggen können, da ein anderer Browser bei dir funktioniert und es somit auch wallboxseitig funktioniert. Wäre nett, wenn du das im Blick behalten könntest, wenn es eine neue Edge-Version gibt.

Enthält dein Passwort zufällig deutsche Sonderzeichen wie ä, ö, ü, ß oder €? Microsoft-Browser sind leider nicht dafür bekannt, sich gut an Standards zu halten. Falls dein Passwort entsprechende Zeichen enthält, wäre meine Vermutung, dass Edge Passwörter nicht als UTF-8 codiert, wie das alle anderen Browser machen und alle Webseiten erwarten. Sonderzeichen wie !<>=&?()-:@+%"';_[]^\/{}*#$|~` sollten keine Probleme verursachen, da sie im ASCII-Zeichensatz enthalten sind, was eine Untermenge von UTF-8 ist. Ansonsten sind natürlich A-Z, a-z und 0-9 erlaubt. Alles andere, wie die Umlaute, kann Probleme verursachen und sollte nicht in Passwörtern verwendet werden.

Bei der Wallbox-Firmware ist das leider nicht möglich, da sie als ein monolithischer Block bereitgestellt wird. Wenn eine Community-Erweiterung nutzbar sein soll, muss sie fest reinkompiliert werden. Ab der nächsten Firmware-Version wird es eine viel flexiblere API für Stromzähler geben, sodass externe Software einfacher Werte an die Wallbox liefern kann. Eine Community-Erweiterung für einen Zähler könnte dann z.B. ein Python-Script sein, dass der Nutzer auf einem Raspberry Pi laufen lassen kann.

Wallboxen sind ein Produkt für den Massenmarkt und ein signifikanter Teil unserer Kunden hat keine Ahnung von Open Source oder Community-Erweiterungen. Es ist für solche Leute schwer verständlich, warum sie, wenn sie ein in sich abgeschlossenes Produkt gekauft haben, für einige Funktionen keinen Support bekommen. Wir hatten schon überlegt, einige Option „FritzBox-Style“ hinter einem Expertenmodus zu verstecken. Dort könnte man vielleicht auch Community-Erweiterungen verstecken, aber das ist leider immer noch ein Punkt auf unserer ewig-langen Todo-Liste. 😒

Die Idee hatten wir auch schon. Das Problem dabei ist, dass wir die von der Community bereitgestellten Anbindungen testen und warten müssen, wofür wir sämtliche benötigte Hardware vor Ort einsatzbereit halten müssen und mindestens ein Mitarbeiter muss sich hinreichend mit den Geräten auskennen. Das können wir aktuell leider noch nicht leisten.

Ja, schön wäre das, allerdings gibt es mehr herstellerspezifische Lösungen als wir unterstützen können. Fängt man mit einer davon an, ist die Frage, wo man aufhört. Deswegen unterstützen wir aktuell keine herstellerspezifischen Lösungen und haben stattdessen das herstellerübergreifende SunSpec implementiert.

Ist der SDM630 noch verbunden oder hast du ihn abgeklemmt? Wenn der noch verbunden ist, kämpfen der SDM und deine manuellen Updates gegeneinander. Spätestens nach einer Sekunde werden deine Werte immer vom SDM630 überschrieben. Außerdem musst du in den WEM-Einstellungen unter Energiemanager → Stromzähler-Einstellungen den Stromzähler-Typ auf „Benutzerdefinierter Zähler (MQTT/HTTP)“ stellen. Wenn der SDM630 aktuell noch verbunden ist und du ihn abklemmen will, solltest du den WEM dafür stromlos machen, damit er den Zähler auch wirklich vergisst. Ein Neustart über das Webinterface reicht dafür nicht. Wir arbeiten aktuell an einer neuen Zählerverwaltung, die den Konflikt zwischen SDM und API beseitigt. Man muss dann manuell auswählen, ob man den angeschlossenen Zähler oder einen per API befüllten Zähler nutzen möchte. Wenn man den API-Zähler auswählt, ist es dann egal, ob ein anderer angeschlossen ist oder nicht. Man kann auch beide Zähler gleichzeitig Werte anzeigen lassen und auswählen, welcher von beiden für PV-Überschussladen verwendet werden soll. Was mir gerade noch einfiel: Wenn du die Zählerwerte per MQTT an die API schickst, musst du als Topic „wem/UID/meter/values_update“ angeben. Auf /values kannst du nur Werte lesen aber nicht setzen.

Hast du nach den curl-Befehlen manuell einen Neustart durchgeführt? Ich hatte leider nicht darauf hingewiesen, dass du das machen musst, und es sieht so aus, als wäre noch kein Neustart gemacht worden und die Änderung von "verbose" auf true wurde noch gar nicht angewandt. Sorry. 😑

Die 8 A hatten wir auch schon in Verdacht. Interessant, dass es da einen Zusammenhang zu geben scheint. Wir haben uns also einen weiteren Test für dich überlegt: Deaktiviere das Lastmanagement auf der Wallbox, damit der Energy Manager keinen Einfluss mehr hat. Aktiviere die manuelle Ladefreigabe. Stell in der Wallbox den konfigurierten Ladestrom auf 8 oder 6 A. Auto anschließen und einschlafen lassen. Irgendwann per „Start“ die Ladung starten. Damit kannst du testen, ob sich der Peugeot möglicherweise nicht mit einem niedrigen Ladestrom aufwecken lässt. Ich würde den Test zuerst mit 6 A machen, in der Hoffnung, dass das Problem dann wahrscheinlicher auftritt. Wir haben ansonsten noch eine weitere Idee, allerdings testen wir das erst hier. Bei Gelegenheit könntest du schon mal einen Debug-Report (von der Unterseite „Ereignis-Log“) von dem Energy Manager mit den 8 A hier anhängen.

Korrektur: Ursprünglich war das nicht vorgesehen, aber es gibt den Standard ISO 15118, der meines Wissens für DC-Schnellader entwickelt wurde und dort notwendig ist, inzwischen aber auch optional bei AC-Wallboxen eingebaut werden kann. Leider verursacht die Unterstützung dafür zusätzliche Kosten und ist erst bei entsprechend hohem Absatz realistisch machbar. Da den hohen Kosten als einziger Vorteil Plug & Charge gegenübersteht, bieten die meisten AC-Wallboxen, wie auch der WARP Charger, das aktuell leider noch nicht an. Wir sind aber sehr interessiert daran und behalten das weiter im Auge, damit wir auch eine Unterstützung dafür anbieten können, sobald das realistisch machbar ist.

Nein, das ist bei Wallboxen mit Typ 2-Stecker leider nicht möglich, da die Information nicht übers Kabel übertragen wird.

Genau das Feature ist schon geplant und steht auf unserer Todo-Liste, existiert aber leider noch nicht. Das Github-Issue dazu findest du hier.

Ich weiß zugegebenermaßen nicht, wie EVCC die Werte erhält, aber ich kann dir zumindest die andere Seite erklären: Sobald du im WEM einen MQTT-Server eingetragen hast, werden die Zählerwerte automatisch dorthin übertragen. Aktuell findest du sie unter dem Topic wem/ABC/meter/values bzw. /all_values. Demnächst gibt es eine neue WEM-Firmware mit neuer API dafür und dementsprechend wäre es sinnvoll, noch etwas zu warten. Das Prinzip bleibt das gleiche, allerdings werden die Werte dann z.B. unter wem/ABC/meters/0/values veröffentlicht. Manche Hausautomatisierungen bieten dir schon die Möglichkeit, MQTT-Daten weiter zu verarbeiten. Alternativ kann man mit etwas Programmiererfahrung die Werte recht einfach z.B. mit der MQTT-Bibliothek für Python verarbeiten und beliebig weiterschicken.

Per Modbus TCP können prinzipiell mehrere Clients einen Host abfragen. Problematisch wird es allerdings, wenn der Host eine Modbus RTU-Bridge ist und jede Anfrage über eine lahme serielle Verbindung an einen Zähler geht. In dem Fall wird die serielle Schnittstelle der Flaschenhals sein und du wirst häufig Timeouts bekommen. Hat der Host die Werte selbst, können problemlos mehrere Clients sie abfragen. Wenn du EVCC verwendest, steuert das wahrscheinlich das Überschussladen. In dem Fall braucht der EM die Werte gar nicht. Ansonsten kannst du die Werte per MQTT bekommen. Der EM stellt alle ihm bekannten Stromzählerwerte per MQTT zur Verfügung.