poohnet

Kein Problem: Die größte Herausforderung (nach 20 Jahren "Lötabstinenz") war tatsächlich, den Stecker der Stromversorgung vom ESP32-Brick abzulöten und auf dem ESP32-Ethernet-Brick wieder anzulöten. Ansonsten habe ich lediglich ein paar neue Löcher in die Abdeckplatte gebohrt und die Abstandshalter entsprechend versetzt, sodass der größere Brick draufpasst, ohne die Aussparung des Tasters zu überdecken. Danach noch die Firmware entsprechend angepasst (d. h. Modul EVSE anstelle von EVSE_V2 verwenden) und fertig... 🙃 EDIT: So sieht das jetzt aus.

'n Abend @rtrbt, nachdem ich meine WARP1 nun auf den ESP32-Ethernet-Brick umgebaut und die (auf den alten EVSE angepasste) WARP2-Firmware geflashed habe, finde ich leider keinen Menüpunkt "OCPP". Kann es sein, dass der Code noch gar nicht im master-Branch drin ist? Bis auf ein define in EVSE(_v2) finde ich nämlich auch kein passendes Modul... Danke & Gruß Thomas

So, der Umbau meiner WARP1 auf den ESP32-Ethernet-Brick (d. h. WARP2 "Lite") ist abgeschlossen, hat alles problemlos funktioniert...🙂

Ok, der Umbau einer WARP1 auf ESP32-Ethernet-Brick gestaltet sich doch (etwas) komplizierter. Mein Brick hat leider keinen Anschluss für die Stromversorgung und passt auch nicht so ohne weiteres auf die Abdeckplatte (zumindest nicht, ohne entweder die Aussparung für den Taster zu überdecken). Da muss ich die Platte wohl erstmal entsprechend bearbeiten...

Danke Eric, funktioniert wieder 🙂 Ihr wisst ja, ich stehe gerne als Betatester zur Verfügung. Besser die Bugs fallen auf bevor die Firmware öffentlich zur Verfügung steht...

Hallo zusammen, nach zwei Monaten habe ich euren master-Branch nun nochmals in meinen Fork gemerged, die Firmware gebaut und auf meine WARP1 geflashed. Dabei ist mir aufgefallen, dass die Zeitsynchronisation per NTP nun leider nicht mehr funktioniert. Dabei ist es auch egal, ob man die Zeitserver per FQDN oder per IP-Adresse hinterlegt. Bis einschließlich 2.0.7 funktioniert das problemlos innerhalb von 15-30 Sekunden. Könnt ihr das Problem reproduzieren? Danke & Gruß Thomas P. S. Das Problem scheint nicht an meinen Anpassungen zu liegen, denn es tritt auch in der Konfiguration "warp" auf...

Ich denke auch, dass man TF hier absolut keinen Vorwurf machen kann. Ich selbst habe (seit 1 1/2 Jahren) auch eine WARP1 Smart mit ext. Stromzähler, die weiterhin regelmäßig mit Updates und Erweiterungen versorgt wird. Neue Features erfordern aber manchmal eben auch neuere und/oder leistungsfähigere Hardware. Ein kompletter Umbau auf WARP2 wäre sicherlich eine (leider doch recht kostspielige) Möglichkeit, eigentlich sollte es aber doch ausreichend sein, nur den ESP32-Brick gegen den ESP32-Ethernet-Brick auszutauschen und die Firmware entsprechend anzupassen (insbesondere hinsichtlich Stromzähler und Ladecontroller). @rtrbt Was meinst du? Setzt die OCPP-Implementierung auch den neuen Ladecontroller voraus oder würde der o. g. Weg funktionieren? Einen ESP32-Ethernet-Brick habe ich bereits und Firmware-Anpassungen habe ich ja mittlerweile auch schon mehrere durchgeführt. OCPP würde mich nämlich ebenfalls interessieren… Gruß Thomas

Hallo @borg, zwischenzeitlich habe ich den Passat GTE mehrfach komplett aufgeladen und das Problem ist mit der neuen Kalibrierung nicht mehr aufgetreten 😊 Vielen Dank nochmals! Gruß Thomas

Vielen Dank, ich habe die angepasste Kalibrierung hochgeladen und werde das in den kommenden Tagen nochmals testen. Es wäre natürlich interessant zu wissen, warum der Passat da manchmal diese Widerstandswerte zurückliefert… Gruß Thomas

Hallo @borg, so, anbei jetzt das Ladeprotokoll. Beim ersten Versuch war das Webinterface irgendwie nicht mehr erreichbar, das hat sich dann aber selbst geheilt, nachdem ich einmal die URL /info/ws aufgerufen hatte. Daher die zwischenzeitlichen Verbindungsabbrüche... Gruß Thomas evse-debug-log-warp-SMH-2022-07-19T16-21-45-314.txt

Danke @borg. Im Moment ist der Wagen voll geladen, aber sobald wieder etwas "Platz" im Akku ist, werde ich das testen... Gruß Thomas

Hallo zusammen, hin und wieder kommt es vor, dass mein WARP-Charger das Schütz im Sekundentakt ein- und wieder ausschaltet, wenn mein Passat GTE vollständig geladen ist oder ich den Ladevorgang per VW-App (und nicht über EVCC oder das Webinterface) vorzeitig beende. Leider tritt das Problem nicht bei jedem Ladevorgang auf, gestern konnte ich aber mal ein Debug-Log sichern. Habt ihr eine Idee, wodurch das Verhalten verursacht wird? Vielen Dank und Gruß Thomas evse-debug-log-warp-SMH-2022-07-16T11-40-00-487.txt

... und am Besten jetzt direkt die aktuellste Firmware installieren. Gruß Thomas

Der Stromzähler (SDM630) ist nicht im WARP-Charger verbaut sondern in der Unterverteilung und wird über eine Modbus TCP/IP-Bridge (Raspberry mit RS485-Hat) im Netzwerk zur Verfügung gestellt. NodeRED liest die Daten aus und überträgt diese per MQTT an WARP. Parallel kann auch der SMA Data Manager Zählerstände, Leistung etc. abfragen und in das Sunny Portal hochladen. Gruß Thomas

Sehr gut 🙃

Ich weiß aktuell nicht, wie der Default ist, aber sollte bei "fw2" nicht ein "true" stehen? Gruß Thomas

Moin Thomas, wie sieht denn deine "chargers"-Definition in der evcc.yaml aus? Ich musste da nach dem letzten Update von EVCC gestern Abend auch nochmal ran. Meine Config sieht so aus und funktioniert mit v0.93 problemlos: chargers: - name: wallbox1 type: template template: tinkerforge-warp fw2: true host: 192.168.100.8 port: 1883 user: xxxxx password: xxxxx topic: warp/SMH timeout: 30s Gruß Thomas

Hallo zusammen, da die einzelnen Ladevorgänge ja jetzt einzeln getracked werden, wäre es möglich ein "Zähler Dashboard" einzubauen, wo die geladenen kWh pro Monat u. Jahr (d. h. über die letzten 48 Stunden hinaus) angezeigt werden? Im Moment lese ich meinen Zähler parallel aus und speichere die Daten im SMA Sunny Portal. Da gibt's dann u. a. folgende Ansicht: Schön wäre es, wenn das auch direkt im WARP so angezeigt werden könnte... 😍 Besten Dank und Gruß Thomas

Moin, ohne das jetzt ausprobiert zu haben, würde ich sagen, dass die beiden Zeilen "csvfile1.close()" und "input("Press key to exit\n") # Use raw_input() in Python 2" getauscht werden müssen. Wenn der Callback aufgerufen wird, ist die Datei ansonsten nämlich schon wieder geschlossen... Gruß Thomas

Ja, ein ähnliches Problem hatte ich auch (s. https://www.tinkerunity.org/topic/7639-webinterface-kaputt-durch-meterall_values_update/), seit dem Update läuft das aber jetzt problemlos. Einfach die Box neustarten und sofort die 2.0.4 installieren... Gruß Thomas

Moin Erik, man soll den Tag zwar nicht vor dem Abend loben, aber das Webinterface läuft nun schon seit fast zwei Tagen stabil 🙂 Vielen Dank für die (wie immer) tolle Unterstützung hier, viele Grüße und ein schönes Wochenende Thomas

So, die Commits sind nachgezogen und die neue Firmware ist drauf. Mal schau'n, was nun passiert 🙃

Bingo! Das sind die letzten Einträge im Log: 2022-05-04 11:32:43,032 keep_alive_fds 55 -1 -1 -1 -1 2022-05-04 11:32:43,033 keep_alive_pongs 72310851 0 0 0 0 2022-05-04 11:32:43,033 queue_len 20 2022-05-04 11:32:43,044 worker_active yes

Hier noch ein (vielleicht hilfreicher) Hinweis: Auch wenn das Webinterface an sich nicht mehr (richtig) reagiert, die Zählergrafik funktioniert weiterhin:

Moin Erik, tja, das hat leider auch nicht geholfen, das Webinterface ist eben schon wieder kaputt gegangen 🙁 Hat das Problem evtl. etwas mit der Fehlermeldung "httpd_ws_recv_frame failed to get frame len with -1" zu tun? Ich bin mir nicht ganz sicher, aber es scheint, dass die auftritt, wenn ich das Webinterface per iPhone oder iPad öffne. Kann ich noch irgendwas testen, bevor ich ein "reboot" per MQTT sende? Vielen Dank & Gruß Thomas