MatzeTF

Wenn du den Neustart-Button benutzt, wird anschließend das Webinterface nicht neu runtergeladen, was jedes Mal ein 256 KiB großer Blob ist. Dementsprechend lädt die ganze Seite schneller und Timouts sind weniger wahrscheinlich. Wenn das Problem nochmal auftritt, mach die Browser-Konsole auf und lade die Seite neu. Dann sollte man sehen können, aus welchem Grund die Anfragen fehlschlagen.

Schreibst du zufällig 32000 (also 32 A) rein? Das ist der Default und wird als „Freigegeben“ angezeigt, da es das höchstmögliche Limit ist.

Ja, das solltest du in evse/external_current schreiben. In der GUI findest du den Wert unter „Wallbox → Ladestatus → Ladestromgrenzen → Externe Steuerung“. Den „Konfigurierten Ladestrom“ findest du in der selben Liste unter „Konfiguration. Dieser Wert wird bei jeder Änderung im Flash gespeichert und sollte deswegen besser nicht per API geändert werden. Beide Ladestromgrenzen sind voneinander unabhängig. Von allen Ladestromgrenzen aus der Liste gilt immer das Minimum.

Im zweiten Screenshot werden die billigen Stunden am folgenden Tag nicht mit einbezogen weil du in den Eco-Einstellungen eine maximale Standzeit von 12 Stunden eingestellt hast. Es werden also nur die billigsten 4 Stunden innerhalb der nächsten 12 Stunden ausgewählt. Im ersten Screenshot wird aus dem gleichen Grund der erste grüne Block ausgewählt. Zusätzlich wird aber noch der zweite Block ausgewählt, da in den zwei Stunden der Börsenstrompreis unter 1 ct liegt, was du als Strompreis eingestellt hast, unter dem immer geladen werden soll.

Was passiert, wenn du die MAC-Adresse der Version ohne PoE für die Version mit PoE verwendest? Schreib’ dir die PoE-MAC vorher auf, da es dafür keinen Reset-Button gibt, IIRC. Hat der Switch, den du verwendest, STP, Loop Protection, Port Security oder MAC-Filter auf dem Port für die Ethernet Extension aktiviert?

Noch eine Idee: Steckt die Extension auf dem Master, wie sie sollte? Ich vertausche die gerne mal und wenn die Extension unter dem Master sitzt, wird sie zwar erkannt, kann aber keine Verbindung aufbauen.

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?