poohnet

So, die ersten Tests waren so halbwegs erfolgreich. Ich habe einen eCarUp-Account angelegt und zunächst die wss-URL (wss://www.ecarup.com/api/Ocpp16/xxxx) verwendet. Leider erhalte ich damit nur die Fehlermeldung "OCPP WEBSOCKET DISCONNECTED". Die Umstellung von wss auf ws hat das Problem dann aber erstmal (temporär) gelöst, WARP verbindet sich und erscheint sowohl im eCarUp-Portal als auch in der App - und zwar direkt mit dem richtigen Status (frei bzw. verbunden) 🙂 Leider lässt sich aber die Ladung nicht starten. EVCC ist freigegeben und die OCPP-Startanforderung kommt auch an - nur es passiert nix. Interessant ist auch der Zeitstempel der OCPP-Meldungen, diese scheinen etliche Jahre aus der Zukunft zu kommen: 8,343 Network connected. Stopping soft AP 8,381 MQTT: Connected to broker. 16,188 OCPP WEBSOCKET CONNECTED 16,201 Sending BootNotification.req. 16201 0 60000 60000 16,351 Received message [3, "1", {"status":"Accepted","currentTi (len 86) 16,352 Received BootNotification.conf for connector 0. Interval 60 2028-02-29 09:29:49,000 Sending StatusNotification.req: Status Available for charge point 2028-02-29 09:29:49,001 Sending StatusNotification.req: Status Preparing for connector 1 2028-02-29 09:29:49,138 Received message [3, "2", {}] (len 12) 2028-02-29 09:29:49,139 Received StatusNotification.conf for connector 0 2028-02-29 09:29:49,344 Received message [3, "3", {}] (len 12) 2028-02-29 09:29:49,344 Received StatusNotification.conf for connector 1 2022-10-25 15:54:13,808 NTP synchronized at 24,778! 2022-10-25 15:54:55,650 This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 2022-10-25 15:54:55,730 Tag timeout! 2022-10-25 15:54:55,730 NO_TAG -> FINISHING_UNLOCKED 2022-10-25 15:54:55,731 Sending StatusNotification.req: Status Finishing for connector 1 2022-10-25 15:54:55,838 Received message [3, "4", {}] (len 12) 2022-10-25 15:54:55,839 Received StatusNotification.conf for connector 1 2022-10-25 15:55:05,287 Sending Heartbeat.req. 76258 76258 136258 60000 2022-10-25 15:55:05,381 Received message [3, "5", {"currentTime":"2022-10-25T13:5 (len 52) 2022-10-25 15:55:05,382 Received Heartbeat.conf for connector 0 2028-02-29 09:31:48,907 Sending Heartbeat.req. 136271 136271 196271 60000 2028-02-29 09:31:49,009 Received message [3, "6", {"currentTime":"2022-10-25T13:5 (len 52) 2028-02-29 09:31:49,010 Received Heartbeat.conf for connector 0 2028-02-29 09:31:56,360 Received message [2, "15ed0004-bf5d-47d0-5242-b4e5ec3cc10 (len 119) 2028-02-29 09:31:56,361 Received RemoteStartTransaction.req for connector 1 and tag 5PXVQ7NNERYRYRJKGDBQ 2028-02-29 09:31:56,372 Sending RemoteStartTransaction.conf Accepted 2028-02-29 09:31:56,386 FINISHING_UNLOCKED -> TRANSACTION 2028-02-29 09:31:56,421 Sending StatusNotification.req: Status SuspendedEVSE for connector 1 2028-02-29 09:31:56,495 Received message [3, "7", {}] (len 12) 2028-02-29 09:31:56,495 Received StatusNotification.conf for connector 1 2028-02-29 09:32:39,023 Received message [2, "5df50004-4331-3795-c346-bdee912be3c (len 119) 2028-02-29 09:32:39,024 Received RemoteStartTransaction.req for connector 1 and tag 6PE6E4DYL7RCZGAYDFXQ 2028-02-29 09:32:39,035 Sending RemoteStartTransaction.conf Accepted 2028-02-29 09:32:39,050 Ignoring remote start transaction in state TRANSACTION 2028-02-29 09:32:48,898 Sending Heartbeat.req. 196282 196282 256282 60000 2028-02-29 09:32:49,011 Received message [3, "8", {"currentTime":"2022-10-25T13:5 (len 52) 2028-02-29 09:32:49,012 Received Heartbeat.conf for connector 0 So sieht der EVSE aktuell aus: @rtrbt, hast du vielleicht noch eine spontane Idee? EDIT: Was mir noch aufgefallen ist: Die Heartbeats kommen für Connector 0, die Steuerungsbefehle für Connector 1. Gibt's da vielleicht noch irgendwo ein "+/-1 Problem"? Oder muss der Ladepunkt bei eCarUp noch weiter konfiguriert werden? Vielen Dank & Gruß Thomas

Yeah, das hat funktioniert 🙂 Jetzt werde ich das mal testen... Vielen Dank @rtrbt!

Moin @rtrbt, kein Problem, besten Dank. Die reguläre WARP2-Konfiguration lässt sich erfolgreich bauen, aber wenn ich das Modul "EVSE_V2" durch "EVSE" austausche, dann erhalte ich leider eine ganze Menge Compilefehler. Einige lassen sich durch kleine Codeanpassungen beheben, aber spätestens bei "get_ocpp_current()" bzw. "set_ocpp_current()" hört's dann doch auf, da diese Methoden bislang nur in "EVSE_V2" implementiert sind. Zieht ihr das noch in das Modul "EVSE" nach oder muss/soll ich mich da selbst drum kümmern? Vielen Dank & Gruß Thomas

Danke für die Blumen, @floho Ich halte meinen Fork des Repos eigentlich immer relativ aktuell, d. h. ich kann hier gerne auch die kompilierte Firmware zur Verfügung stellen. "WARP1 on Steroids" gefällt mir 🙃 Gruß Thomas

Hallo @Little_Company, ich habe die vorhandenen Abstandshalter lediglich etwas versetzt, sodass die Aussparung für den Taster frei bleibt; der Stecker der Stromversorgung passt dann durch den länglichen Schlitz (unterhalb des Bricks). Der Umbau selbst war eine Sache von 1 1/2 Stunden und die Kosten von ca. 60,-€ für den ESP32-Ethernet-Brick sind m. E. überschaubar. Allerdings kann man nicht die hier im Forum gepostete Beta-Firmware für WARP2 verwenden (wegen EVSE_V2), sodass man diese definitiv entsprechend anpassen und selbst bauen muss. Aber auch das ist kein Hexenwerk… Leider ist der Code für das OCPP-Modul noch nicht im GitHub-Repository, daher konnte ich diese Funktionalität bislang noch nicht testen. Ich gehe aber davon aus, dass @rtrbt das Repo in den nächsten Tagen entsprechend aktualisieren wird. Das „normale“ Laden inkl. Steuerung durch EVCC funktioniert aber problemlos. Ich halte dich auf dem Laufenden… Gruß Thomas

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