rtrbt

wss sollte eigentlich gehen, probiere ich gleich nochmal aus. Ich gehe davon aus, dass die Ladeprobleme von den kaputten Zeiten kommen. Das ist ein Problem mit dem iso8601-Zeitstempel-Parser, das ich eigentlich behoben hatte, aber scheinbar habe ich den Fix beim Einbinden von TFOCPP als Abhängigkeit wieder verloren. Das muss ich nochmal kurz nachvollziehen. Das muss so sein: OCPP ist darauf ausgelegt, dass du pro Charge Point mehrere Connectoren haben kannst (wie bei so einer großen DC-Ladesäule an der Autobahn z.B.). Connector 0 addressiert den ganzen Charge Point und die eigentliche Verbindung zum Auto geht dann bei uns immer über Connector 1.

Und ich dachte beim Einfügen der Funktionen noch "Das brauchen wir erstmal nur im EVSE_V2" :D Zieh mal bis 887f0e95 nach, dann sollte es gehen.

Das OCPP-Modul ist jetzt im esp32-firmware-Git. (Sorry hatte es heute erst geschafft. Da hing mehr dran als ich in Erinnerung hatte.) Edit: Bau am besten gegen den Stand von 8aef2cd4, das sollte funktionieren.

Stimmt, das fehlt im Repo. Kommt morgen.

Prinzipiell ist es keine gute Idee, wenn du in einer Schleife ohne irgend eine Art von Limitierung die GUI zu verändern. Außerdem solltest du mal testen, ob die Schleife überhaupt beendet wird. Ersetze den Code-Schnipsel mal durch z.B. Do Until volt > 2 txt_Motor_Lift_Pos.Text = "volt " & volt Thread.Sleep(100) Loop Dann solltest du sehen können, was die Schleife tut.

Okay ich habe raus, was da schief gelaufen ist. Die Firmware hält sich an einer Stelle nicht an die Spezifikation (Nachrichten mit einer Liste von Stromzählerwerten müssen mindestens einen Wert enthalten), das versucht die OCPP-Integration von Home Assistant als Fehler zu melden, hält sich aber dabei selbst nicht an die Spezifikation und das wiederum versteht die Firmware dann nicht. Daraus entsteht dann die deserialize-Katastrophe. Ich habe das Problem in der OCPP-Integration bzw. in der Bibliothek die diese verwendet, mal gemeldet: https://github.com/mobilityhouse/ocpp/issues/381 Den Rest fixe ich gerade auf unserer Seite.

Das sieht interessant aus, danke! Gerade die JSON-Fehler muss ich mir mal genauer ansehen. Ich verwende da einen sehr minimalistischen Serializer, den ich eventuell an einer Stelle falsch benutze.

Das lag soweit ich das sehe an den Umbauten in der Config, die ich gemacht habe. Mit https://github.com/Tinkerforge/esp32-firmware/commit/102d7967be99aba3ba4c197675cd8553cbd23de4 sollte es wieder funktionieren. Sorry dafür.

Ja, das geht. (Auch mit mehr als 2 Karten)

Moin, Kannst du das Problem mit der Firmware im Anhang immer noch erzeugen? (Nicht von der Versionsnummer verwirren lassen: Das ist ein Abkömmling der OCPP-Beta-Firmware, aber ohne dass OCPP reinkompiliert ist) warp2_firmware_2_0_90_63453d05_merged.bin

Sorry, hatte überlesen, dass du von Warp1 redest. Prinzipiell ist es so, dass es die OCPP-Beta erstmal nur für Warp 2 gibt. Wenn das ganze "Feature-Complete" ist, werden wir uns nochmal in Ruhe ansehen, ob wir OCPP auf Warp 1 zum Laufen bekommen. Nein, OCPP geht auch mit dem alten Ladecontroller. Das ist im Moment ein reines RAM-Verbrauchsproblem vs. die Priorisierung die wir natürlich vornehmen müssen um überhaut mal was fertig zu bekommen ;)

Not Authorized als Fehler ist interessant. Hast du bei deinem MQTT-Broker Benutzername und Passwort konfiguriert? Dann musst du das in der EVCC-Konfiguration eintragen. Frag ansonsten am besten auch mal im EVCC-Forum: https://github.com/evcc-io/evcc/discussions

Das sollte problemlos funktionieren. Callbacks bekommen immer alle verbundenen Clients, egal von welchem Host. Der Client muss aber auf das Callback registriert sein.

For that you can use the IP connection's enumerate callback. See here for an example: https://www.tinkerforge.com/en/doc/Software/IPConnection_C.html#enumerate This will report all connected Bricks and Bricklets with their UID and more.

Das ist wirklich interessant. Hattest du dazu schonmal was geschrieben? Wenn du das reproduzieren kannst würde mich ein Ladeprotokoll interessieren (kannst du auf der Ladecontroller-Unterseite erzeugen)

Leider nicht. Die Fahrzeugerkennung läuft über https://de.wikipedia.org/wiki/ISO_15118, was ein extrem kompliziertes Protokoll ist, das von den ganzen Schnell-(Gleichstrom-)ladern implementiert wird. Das kann unsere Hardware nicht. Die Kommunikation an den meisten Wallboxen (so auch am WARP Charger) läuft über https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung, was sehr viel einfacher funktioniert, aber nur den Fahrzeugstatus (will/darf laden) und den erlaubten Ladestrom kommunizieren kann. Wenn du nicht direkt den Weg über NFC-Karten gehen willst, kannst du über die API des WARP Chargers NFC-Tags faken: https://www.warp-charger.com/api.html#nfc_inject_tag Da müsstest du dir aber selbst etwas programmieren.

Ja. Siehe z.b. hier:

Ja, es gibt eine erste Beta-Version hier:

Möglicherweise bist du zu ungeduldig: Wenn du das Auto ansteckst sollte die LED an der Wallbox das "gib mir ein Tag"-Blinken machen. Wenn du das NFC-Tag an die Box hältst und sie das "bestätigende Blinken" macht, dann bleibt die Tag-Freigabe erhalten bis du das Auto abziehst. Die LED sollte dann nicht mehr blinken. Es kann jetzt aber sein, dass EVCC eine Weile braucht, bis die Ladung freigegeben wird. Wenn du jetzt das Tag ein zweites Mal dranhältst sollte wieder das "bestätigende Blinken" kommen, danach macht die Wallbox aber wieder das "gib mir ein Tag"-Blinken. Die Wallbox interpretiert das Tag beim zweiten Mal also als wieder abmelden bzw. blockieren. (Hintergedanke ist, dass man das Tag auf das geladen wird wechseln können soll, ohne das Auto abzuziehen) Du kannst im Webinterface übrigens sehen, was gerade das Laden blockiert: Einmal bei "Erlaubter Ladestrom" auf der Statusseite, da sollte 0 A durch Benutzer stehen wenn das Tag fehlt und 0A durch externe Steuerung wenn EVCC blockiert. Für Details gibt es unter Ladecontroller noch die Ladestromgrenzen.

Hattest du davor eine der Testversionen laufen, die wir im Forum veröffentlicht haben? Falls ja ist vermutlich die EVSE-Firmware-Versionsnummer durcheinander gekommen. Das kannst du ad-hoc testen, indem du im Webinterface unter Ladecontroller den Low-Level-Zustand aufklappst und da ganz unten auf "Neu flashen" klickst. Dann sollten die Meldungen aufhören. Wenn das bei dir klappt, würde ich kurzerhand 2.0.9 veröffentlichen, mit einer reparierten Ladecontroller-Firmware-Versionsnummer. Das betrifft dann vermutlich auch alle die diese Firmware hier installiert hatten.

Firmware: WARP2 2.0.90 Details hier:

ACHTUNG: Dieser Thread über die OCPP Unterstüzung ist veraltet, biete diesem Thread folgen: Moin, Die vergangenen Monate habe ich an einer OCPP-Implementierung für den WARP Charger gearbeitet. Als erste Vorschau hier eine Beta-Version. Was funktioniert bereits? Aktuell unterstützt wird das Core Profile von OCPP1.6J, folgende Funktionen sind mit einem OCPP-Server möglich: Starten/Stoppen von Ladevorgängen Autorisierung von Ladevorgängen über NFC-Tags Steuerung der Verfügbarkeit Anzeige des aktuellen Status der Wallbox Einstellen diverser Konfigurationen Übertragung von Zählerwerten an den Server Neustart der Wallbox Es gibt noch ein paar Einschränkungen bezüglich der Zählerwert-Historie: Laut Spezifikation können Zählerwerte über einen Ladevorgang auf der Wallbox gesammelt werden und beim Ende des Ladevorgangs auf einmal übertragen werden. Das unterstützen wir derzeit nicht. Diese Einschränkung ist aber nach OCPP-Spezifikation erlaubt, sollte also hoffentlich bei keinem Server zu Problemem führen. Bisher ist die OCPP-Implementierung mit SteVe 3.4.9: (https://github.com/steve-community/steve) sowie https://web.ecarup.com/ erfolgreich getestet worden. Weitere OCPP-Server werden wir im Zuge der Weiterentwicklung testen. Was fehlt? Neben den genannten Einschänkungen bzgl. der Zähler-Historie fehlen noch folgende (geplante) Features bzw. bestehen folgende Probleme: Bessere Einbindung ins Webinterface: Aktuell kann OCPP aktiviert, sowie die Server-URL eingetragen werden. Außer im Ereignis-Log gibt es kein Feedback über den OCPP-Betrieb. Entkopplung in eine eigene Ladestromgrenze: Aktuell benutzt OCPP die "externe Steuerung"-Ladegrenze, blockiert damit also andere Steuerungen wie z.B. EVCC oder eigene Scripte. Wir werden deshalb OCPP eine eigene Ladestromgrenze zuweisen. Bessere Verzahnung mit anderen Features der Wallbox: Im Moment läuft OCPP komplett parallel neben anderen Features wie der NFC-Tag/Benutzerverwaltung. Künftig werden diese Funktionen stärker gekoppelt, sodass z.B. nur entweder die Ladefreigabe per OCPP, oder die lokale Freigabe per NFC-Tag aktiv ist, um Verwirrung zu vermeiden. Um weitere OCPP-Server (z.B. EVCC) zu unterstützen, werden wir möglicherweise weitere Profile, insbesondere das Smart Charging Profile, mit dem Ladeströme gesteuert werden können, implementieren. Wie kann ich die OCPP-Implementierung testen? Zum Testen wird ein OCPP-Server benötigt. Lokal kann SteVe (siehe oben) ausgeführt werden. Alternativ bietet https://web.ecarup.com kostenlose Accounts an. Nach dem Flashen der Beta-Firmware steht im Webinterface der neue Menüpunkt OCPP zur Verfügung. Hier kann die URL des Endpoints eingetragen werden. Es werden sowohl ws (WebSocket), als auch wss (WebSocketSecure)-URLS unterstützt. Wir empfehlen zweiteres, damit die Kommunikation verschlüsselt stattfindet. Die Firmware beinhaltet ein Zertifikats-Bundle mit den üblichen Root-Zertifikaten (siehe hier für Details). In einer späteren Version werden wir hinzufügen, dass ein eigenes TLS-Zertifikat auf die Wallbox hochgeladen werden kann. Neben dem Aktivieren von OCPP und dem Eintragen der Endpoint-URL muss im Moment außerdem unter Ladecontroller die externe Steuerung aktiviert werden. Bei einem erfolgreichen Verbindungsaufbau sollten Nachrichten ähnlich zu den folgenden im Ereignis-Log auftauchen: 5,790 Sending boot notification. 5790 0 60000 60000 5,801 Sending status Available for connector 1 5,933 Received message [3, "0", {"status":"Accepted","currentTi 2022-09-14 15:45:33,000 Sending status Available for charge point 2022-09-14 15:45:33,011 Sending status Available for connector 1 2022-09-14 15:45:33,183 Received message [3, "2", {}] 2022-09-14 15:45:33,298 Received message [3, "3", {}] und der OCPP-Server die Wallbox registrieren. Warum nur für WARP2? Der ESP32 Brick, der in der WARP1 verbaut ist, verfügt über 320kB RAM. Der ESP32 Ethernet Brick der in der WARP2 verbaut ist hat zusätzliche 4MB PSRAM. In aktuellen WARP1-Firmwares ist der verfügbare RAM zu knapp für die OCPP-Implementierung. Im Moment ist unklar, ob OCPP auf der WARP1 möglich sein wird. warp2_firmware_2_0_90_6321dac1_merged.bin

Im Moment kannst du Ladevorgänge nur über NFC Benutzern zuordnen. Es gibt aber die Möglichkeit, ein NFC-Tag nicht physisch vor die Box zu halten sondern per API vorzutäuschen. Das ist auch was EVCC tut. (Das funktioniert im Moment aber nur wenn zumindest ein NFC-Bricklet angeschlossen ist: https://github.com/Tinkerforge/esp32-firmware/issues/133) Ladevorgänge über das Webinterface Nutzern zuzuordnen ist im Moment noch nicht implementiert, steht aber auf der TODO-Liste (und jetzt auch in einem Issue, das fehlte seltsamerweise: https://github.com/Tinkerforge/esp32-firmware/issues/161)

Moin eweri, Auf dem Firmen-Mac funktionierts mit genau dieser Firmware-, macOS- und Safari-Version. Hast du das Problem mit Firmware 2.0.7 (gerade frisch veröffentlicht, deshalb die späte Rückmeldung) immer noch? Falls nein: Drück mal Command+Option+I, geh auf Konsole und versuche dann nochmal das Ladelog runterzuladen. Bekommst du da irgendwelche Meldungen ausgegeben?

Firmware: WARP 2.0.7 und WARP2 2.0.8 Lastmanagement-Konfigurationsseite überarbeitet Automatische Suche nach Wallboxen via mDNS zu Lastmanagment hinzugefügt Unterstützung für Hostnamen zu Lastmanagement hinzugefügt Wiederherstellungsmodus über Taster hinzugefügt Hinzugefügt, dass unbekannter Benutzer umbenannt werden kann (WARP1) Start-Button im Webinterface deaktiviert, wenn Wallbox über den Schlüsselschalter gesperrt ist (WARP2) Auflösung des dem Auto kommunizierten Ladestroms verbessert (durch Update auf Ladecontroller-Firmware 2.1.7) (WARP2) Verzögerung von 30 Sekunden zwischen Fehler- und Ladezuständen hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.7) (WARP2) Berechnung der angezeigten PP/PE-Spannung verbessert (durch Update auf Ladecontroller-Firmware 2.1.7) (WARP1) Sichergestellt, dass Tastendrücke ignoriert werden wenn Fahrzeug nicht lädt (durch Update auf Ladecontroller-Firmware 2.1.4) (WARP1) Verzögerung von 30 Sekunden zwischen Fehler- und Ladezuständen hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.4) (WARP1) Berechnung des CP/PE-Widerstands verbessert (durch Update auf Ladecontroller-Firmware 2.1.4) Recovery-Seite verbessert Hinzugefügt, dass Firmware-Updates über die Recovery-Seite erzwungen werden, selbst wenn ein Fahrzeug angeschlossen ist HTTP-API-Benutzung vereinfacht: POST für Kommandos erlaubt GET und POST für Kommandos ohne Payload erlaubt Aktualisierung von Konfigurationen ohne "_update"-Suffix erlaubt Mehr Prüfungen auf Fehler in der statischen IP-Konfiguration hinzugefügt Darstellung der X-Achsen-Beschriftung der Stromzähler-Diagramme auf sehr kleinen Bildschirmen verbessert Weitere WebSocket-Verbesserungen vorgenommen Doppelte NFC-Tag-Detektion behoben Hinweis auf Neustart bei Löschen aller aufgezeichneten Ladungen hinzugefügt HTTP-Fehler beim Senden aufgezeichneter Ladungen behoben Behandung der Benutzer-IDs verbessert Behoben dass Status-Seite kurz sichtbar war, wenn andere Unterseite neu geladen wurde Zeitzonen-Datenbank aktualisiert Links zu Anleitung und Firmwares repariert Benutzerfreigabe-Einstellung auf Benutzer-Unterseite verschoben Übersetzungen verbessert Download: WARP 2.0.7 bzw. WARP2 2.0.8