MatzeTF

Die Fehlermeldung deutet üblicherweise darauf hin, dass das Herunterladen vom Ereignis-Log zu lange gedauert hat, was üblicherweise entweder ein Netzwerk- oder ein Browserproblem ist. Die fehlenden Daten bei der Energieanalyse werden auch durch eine Zeitüberschreitung verursacht. Ich glaube daher nicht, dass deine Wallbox stirbt. Zuhause habe ich das gleiche Problem, wenn ich von meinem alten PC auf die Wallbox zugreife. Der ist nämlich nicht schnell genug, um den Einblend-Effekt beim Laden der Seite anzuzeigen. Bis die Seite komplett geladen wurde, ist das Herunterladen des Ereignis-Logs dann schon in eine Zeitüberschreitung gelaufen. Meinst du mit „Anmelden“ den Fernzugriff oder die Benutzeranmeldung der Wallbox? Bzw, tritt das Problem nur über den Fernzugriff, nur per LAN oder bei beidem auf? Falls das Gerät, mit dem du das Webinterface anzeigst, schon älter bzw. langsamer ist, kannst du mal ein anderes Gerät testen?

CP ist normalerweise eine durchgehende Leitung vom Stecker zum anderen Ende. PP ist normalerweise direkt im Stecker über einen Widerstand mit PE verbunden und wird nicht durch das Kabel geführt. Viele Ladekabel haben aber trotzdem zwei Signalleitungen, obwohl nur eine gebraucht wird. Vermutlich schließt Metron beide parallel an, was den Vorteil hat, dass bei einem Kabelbruch in einer der beiden Signalleitungen alles weiterhin funktioniert. Unser Standardkabel hat einfach nur eine Signalleitung für CP und nicht mehr.

Ist der integrierte Accesspoint noch aktiv? Falls ja, verbinde dich einfach mit einem Smartphone damit. Das Passwort steht auf einem Aufkleber hinten auf der Anleitung. Falls der AP nicht an ist, hast du ihn vielleicht auf den Fallback-Modus gestellt. Dann musst du das LAN-Kabel trennen und nach 30-60 Sekunden sollte der AP aktiviert werden. Hast du den AP komplett abgestellt oder kannst dich aus einem anderen Grund nicht damit verbinden, musst du den Wiederherstellungsmodus nach Anleitung aktivieren (Kapitel 11.2 in der Online-Anleitung). Dabei werden alle Netzwerkeinstellungen und die Benutzeranmeldung zurückgesetzt, aber alle anderen Einstellungen bleiben erhalten. Über den AP kannst du dann auch beobachten, was passiert, wenn du das LAN-Kabel wieder verbindest. Im Ereignis-Log (unter „System“) werden alle Netzwerk-Ereignisse protokolliert. Wenn du dich wieder mit dem AP verbinden kannst aber LAN immer noch nicht funktioniert, lade bitte einen Debug-Report runter und hänge ihn hier an.

Dein Wunsch wurde gewissermaßen schon erhört. Bei WARP3 gibt es die Abzweigleitung für die Schützüberwachung nicht mehr und ein Standardkabel kann prinzipiell direkt angeschlossen werden. Das Ladekabel wird während der Fertigung angeschlossen und soll dann eigentlich auch angeschlossen bleiben. Dementsprechend ist die Kabelführung für die Fertigung optimiert, nicht für späteren Austausch. Im Gegensatz zu den meisten anderen Wallboxen kann man beim WARP Charger das Ladekabel prinzipiell tauschen, aber der Austausch des Ladekabels ist nicht speziell ein Feature der Wallbox. Eine Service-Anleitung gibt es nicht. Zu den beiden Extrakabeln des Metron-Kabels kann ich nichts Genaues sagen. Wenn du ein Multimeter hast, miss doch mal den Durchgang von der Aderendhülse zu den CP- und PP-Kontakten im Stecker.

Bei einem Reboot über das Webinterface wird der Ladevorgang bereits ordnungsgemäß beendet. Die Wallbox hat zwei Prozessoren: Einer sitzt auf der EVSE-Platine und ist zuständig für die Kommunikation mit dem Fahrzeug, das Schalten vom Schütz und die Überwachung vom DC-Schutz, usw. Der Andere sitzt auf der ESP-Platine und ist für alle höheren Aufgaben zuständig, also Webinterface, Auslesen von Zählern, PV-Überschussregelung, NFC, WLAN, usw. Wenn du einen Neustart über das Webinterface auslöst, wird nur der ESP neugestartet, nicht aber das EVSE. Im Log ist zu erkennen, dass das Fahrzeug nach dem ESP-Neustart auch weiterhin normal am Laden ist. Da nach dem Neustart aber die Logik für das PV-Überschussladen erst die Stromsituation analysieren muss, wird dem EVSE gesagt, es solle den Ladevorgang regulär beenden, was es dann auch macht. Hast du kein PV-Überschussladen oder sonstiges Lastmanagement aktiviert, wird ein Ladevorgang übrigens nicht mal unterbrochen, wenn der ESP neugestartet wird. Warum dein Auto in diesem Fall gemeckert hat, dass der Strom plötzlich weg war, kann ich nicht sagen. Prinzipiell war das aber kein anderes Ladeende als alle anderen, die von der Wallbox ausgelöst wurden.

Hast du eine Pro oder Smart? Lade doch mal einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an. Was ist das für eine Meldung? Die sieht nicht aus wie eine Meldung der Wallbox. Die unterbrochene Linie kommt daher, dass du zu selten Werte lieferst. Die Wallbox möchte sekündlich Werte bekommen, damit PV-Überschussladen ordentlich funktioniert. Ansonsten bedeuten negative Werte Überschuss, der eingespeist wird. Mit positiven Werten wirst du die Wallbox nicht zum Laden bekommen. Nö, eine WARP Smart ohne Zähler kann problemlos PV-Überschlussladen machen. Der Großteil unserer Nutzer hat von github und Issues keine Ahnung. Die Nutzer ohne Ahnung rufen üblicherweise bei uns an und für die Nutzer mit Ahnung sollte das Forum die erste Anlaufstelle sein. Die Issues auf Github sind für tatsächliche Software-Bugs und geplante Änderungen und Features, die wir nicht vergessen wollen. Anwenderprobleme wie „ich kriege PV-Überschussladen nicht ans Laufen“ gehören da nicht hin. Die Idee mit Links auf die Produktseiten und Release-Notes der Firmware gefällt mir.

Je nachdem wie der Stecker hängt, kann sich Wasser in der Kappe sammeln. Das führt aber üblicherweise zu sehr auffälligen, grünlichen Ablagerungen an CP und PE. Die sehen bei dir aber gut aus. Wenn du die Box öffnest, zieh einmal alle Schraubverbindungen im Innern nach, insbesondere am Zähler, und achte auf auffällige dunkle Verfärbungen an 230 V-Verbindungen. Wenn du dir Messen an 230 V zutraust, kannst du auch an der Abgangsseite vom Schütz messen, ob da 230 V zwischen Neutral und allen drei Phasen anliegen, wenn die Wallbox bei angeschlossenem Auto den Strom durchschaltet.

Ein Export und Import aller Einstellungen steht schon länger auf unserer Wunschliste. In diesem Fall würdest du aber auch nicht deine gesamte Konfiguration anderen Nutzern zur Verfügung stellen wollen. Die Einstellungen eines einzelnen Zählers kannst du per JSON runterladen: http://warp3-2abc/meters/1/config Importieren kannst du die Einstellungen eines Zählers, indem du sie per HTTP PUT an exakt die gleiche URL schickst. Alternativ kannst du die gleichen JSON-Daten per MQTT unter warp3/2abc/meters/1/config ansehen und importieren kannst du sie, indem du sie an warp3/2abc/meters/1/config_update schickst. Wenn du einen API-Zähler mit mehreren Werten einrichtest, musst du alle als JSON-Array an …/meters/1/update schicken, also z.B. [123.4, 555, 42.3]. Funktioniert sowohl über HTTP als auch MQTT.

Ja, das ist immer noch so. Du müsstest die Daten umformatieren, damit die Wallbox sie versteht.

Schalte doch mal bei den MQTT-Einstellungen der Wallbox die Option „Nur Lese­zugriff“ wieder aus. Dann nimmt die Wallbox deine Daten auch an. 😉

@pvbastla Inzwischen glaube ich, deine Frage falsch verstanden gehabt zu haben. Ich dachte, du möchtest eine stundenweise Summe über alle PV-Flächen, aber so wie ich das nun verstehe, möchtest du nur die Tagesgesamtwerte haben. Da wir die Tagessummen jetzt auch im Backend brauchen, gibt es sie jetzt auch auf der API. Wenn du möchtest, kannst du die aktuelle Beta-Firmware installieren. Du findest die Werte dann in solar_forecast/state.

Die Firmware-Dateien im ersten Post wurden aktualisiert. Unter anderem wurden kleinere WLAN-Probleme behoben.

Das kann ich bei uns weder mit WARP1, noch WARP2 oder WARP3 reproduzieren. Ich baue jetzt aber noch zusätzlich ein, dass zwischen AP aktivieren und HT20 setzen auf das Interface gewartet wird. Vielleicht hilft das. Vielen Dank vor allem an dich für deinen Einsatz zum Testen, Bug melden und dann auch noch aufwändig das Problem einkreisen. Du machst das hier ja schließlich alles freiwillig! 👍

Okay, über WLAN kann ich das Problem bei uns auch reproduzieren. Dass das Zählermodul der Multicastgruppe beitritt, bevor die WLAN-Verbindung steht, ist prinzipiell kein Problem. Im funktionierenden Fall werden die entsprechenden IGMP-Pakete sofort nach Aufbau der Verbindung rausgesendet, auch wenn der entsprechende Aufruf im Zählermodul schon ein paar Sekunden her ist, da sich irgendwas unten drunter anscheinend merkt, welchen Multicastgruppen man beitreten möchte. Das seltsame ist, dass wenn esp_wifi_set_bandwidth nach dem Multicast-Join ausgeführt wird, anscheinend alle Multicast-Mitgliedschaften vergessen werden und nach anschließendem WLAN-Verbindungsaufbau keine IGMP-Pakete rausgeschickt werden. Der aktuelle Master-Stand lässt sich reparieren, indem entweder der Aufruf von esp_wifi_set_bandwidth wieder in die setup-Funktion verschoben wird, wodurch er vor dem Multicast-Join ausgeführt wird, oder der Aufruf bleibt wo er ist und der Multicast-Join wird per Task Scheduler so lange verzögert, dass er wieder hinter dem esp_wifi_set_bandwidth-Aufruf ausgeführt wird. Da ich keine Lust habe, in dem Closed Source WiFi-Blob rumzustochern, werde ich den esp_wifi_set_bandwidth-Aufruf wieder in die setup-Funktion schieben und mit einem entsprechenden Kommentar versehen, damit ihn nicht nochmal jemand verschiebt. Die 58 Byte langen Pakete, die immer durchkommen, sind übrigens Broadcasts vom SHM. Als Broadcasts kommen sie auch ohne Multicast-Join an und aus irgendeinem Grund empfängt der Multicast-Port auch die Broadcasts. Das war schon immer so, ist nur niemandem aufgefallen.

Bitte einen Debug-Report runterladen (unter System → Ereignis-Log) und hier anhängen, wenn du die Freigabe per MQTT erteilt hast und das Auto eigentlich angefangen haben sollte zu laden, das aber nicht tut.

Das Minimum ist da immer 1380 W, da das auch für phasenumschaltbare Wallboxen im Lastmanagement greift.

HT20 hat einen besseren Störabstand als HT40. Heißt, bei gleicher Entfernung zum AP ist die Signalqualität besser. HT40 hat außerdem den Nachteil, dass es doppelt so viel Überlappung mit anderen WLANs in der Umgebung hat und somit die Wahrscheinlichkeit für eine Kollision höher ist. Bei viel Traffic in der Umgebung müssen also deutlich häufig Pakete neu gesendet werden. Dem gegenüber steht als einziger Vorteil, dass die Übertragungsrate theoretisch fast doppelt so hoch ist. Da der ESP nicht mal HT20 voll auslasten kann, ist das in diesem Fall aber kein Vorteil. Somit hat HT40 bei der Wallbox nur Nachteile. Dementsprechend habe ich auf HT20 umgestellt, um die bessere Signalqualität nutzen zu können. Letzteres hilft all denen, deren Wallbox schlechten Empfang hat. Für mobile Geräte ist WLAN ok, aber Wallboxen sind üblicherweise nicht so mobil.

Erstens: Gute Wahl. Zweitens: Warum funktioniert es dann nicht richtig, wenn man HT20 auf dem ESP auswählt? Ich weiß, dass ich mich wiederhole, wenn ich erwähne, dass ich eine Abneigung gegen WLAN habe…

Wird ja immer seltsamer… Wenn du den Aufruf mit HT40 drin hast, was steht dann im Ereignis-Log, wenn das WLAN verbunden ist? HT40 oder immer noch HT20? Weißt du zufällig, was von beidem dein AP aktiviert hat?

Die Umstellung von HT40 auf HT20 für die WiFi Station haben wir doch schon seit über einem Jahr drin, nur war sie vorher an anderer Stelle. Warum führt das jetzt dazu, dass Multicast-Packete abgeschnitten werden, obwohl alles andere noch funktioniert? Insbesondere, wenn die Verbindung in beiden Fällen angeblich mit HT20 hergestellt wird, selbst wenn HT40 nicht deaktiviert wurde. Meine Abneigung gegenüber WLAN bestätigt sich mal wieder. 🤢 Vielen Dank für deine umfangreiche Fehlersuche. Ich werde kommende Woche mal versuchen, das bei uns mit WLAN zu reproduzieren. Bisher haben wir unseren SHM 2.0 nämlich immer per LAN ausgelesen. Wenn du noch weiter motiviert bist, kannst du mal versuchen, den Code reinzunehmen, und im Aufruf von esp_wifi_set_bandwidth das WIFI_BW_HT20 durch WIFI_BW_HT40 zu ersetzen. Mich interessiert, ob der Funktionsaufruf an der Stelle das Problem ist, oder die gewünschte Einstellung.

Ja, das ist möglich. Im Gegensatz zum Eltako-Zähler möchte der aber mit GND angeschlossen werden. Ein passendes Kabel findest du bei den Warp2-Ersatzteilen.

Das ist … unerwartet. Wenn ich das richtig sehe, wurden da nur Dinge verschoben und die TX-Power von 21 dBm angefragt, was allerdings keinen Unterschied machen sollte, da sie in der DE-Zone eh auf 19,5 dBm begrenzt wird. Bist du zufällig motiviert, rauszufinden, welcher Teil von dem Commit das Problem verursacht? Edit: Wo ich so drüber nachdenke, haben wir ja die Reihenfolge, in der bei WiFi AP und Station gestartet werden, geändert. Ich frage mich, ob das nun dazu führt, dass die IGMP-Join-Nachricht für die Multicast-Nachrichten vom SHM 2.0 auf dem AP-Interface rausgeht, bevor das Station-Interface existiert. 🤔

Ich glaube, die Werte werden einzeln gelesen. Bei float32 also immer zwei Register auf einmal. Wäre super, wenn du das herausfinden könntest. Hast du zufällig einen ESP32, den du mit einer unserer Release-Firmwares flashes könntest? Da sowohl Release als auch Master mit dem SHM 2.0 bei uns funktionieren, würde mich interessieren, ob das Problem eher bei deinem Fork oder einer Inkompatibilität mit deinem SHM 2.0 zu suchen ist. Meinst du mit „upstream/master“ eigentlich, dass du unseren Master-Stand ohne eigene Änderungen gebaut hast?

Hm, interessant. Der SHM 2.0, den wir haben, lässt sich problemlos auslesen. Sehen wir uns an. Meinst du mit deinem „ursprünglichen Modul“ eigentlich deine Variante vor dem Merge in unseren Code oder die die direkt nach dem Merge von uns umgeschriebene Variante? Die Wallbox braucht mindestens alle zwei Sekunden neue Daten. Ab 2,5 Sekunden wird der Graph unterbrochen gezeichnet. Wenn ich mir das Log ansehe, dauert es ca. 4 Sekunden, um alle 72 Werte auszulesen. Auf Seiten der Wallbox ist keine Verzögerung drin, also kann ich mir nur vorstellen, dass die Modbus-Bridge die Daten zu langsam liefert. Teilweise werden nur sieben Werte innerhalb einer Sekunde ausgelesen. Kann es sein, dass noch ein anderer Prozess über die Bridge Daten aus dem Zähler liest und die Daten nicht gecacht werden? Ja, gibt es. Wir benutzen die kostenlose Variante vom Vorhersageserver, die nur 12 Abfragen pro Stunde erlaubt. Das Firmennetz hängt auf einer öffentlichen IP, sodass wenn wir alle gegen den richtigen Server testen würden, in kürzester Zeit das Limit überschritten wäre. Da wir zum Testen immer unsignierte Firmwares bauen, haben wir die Testdaten damit gekoppelt. Um deine implizite Frage zu beantworten: Du kannst das gerne auskommentieren und richtige Daten verwenden. Wenn du zu häufig, bzw. zu schnell, neustartest, wirst du aber das Limit treffen. Alternativ erstellst du dir ein eigenes Zertifikat und baust auch signierte Firmwares.

Es gibt LAN-Erdkabel mit unterschiedlichen Durchmessern. Je größer der Durchmesser, umso größer ist der beim Verlegen benötigte minimale Biegeradius. Die Kabeleinführungen unserer Wallboxen sind nur bis 8 mm Durchmesser geeignet. Dickere Kabel sollten nicht verwendet werden, da im Innern der Wallbox nicht genug Platz für die großen Biegeradien ist.