rtrbt

Der von dir verlinkte Post bezieht sich auf den DC Brick, nicht das DC Bricklet. Das DC Bricklet musst du immer selbst mit Strom versorgen. Über den 7-Pol-Stecker zwischen Master Brick und DC Bricklet werden nur 3,3V und 5V verbunden.

Das tun Autos in der Tat, per ISO 15118. Um per ISO 15118 zu kommunizieren, braucht es allerdings deutlich komplexere Hardware, als die, die typischerweise in Wallboxen verbaut ist. Die "normale" Kommunikation, also das Vorgeben eines Ladestroms und die Stromanforderung des Autos läuft über IEC 61851 (was auch die WARP2 verwendet). Es gibt noch eine andere Möglichkeit, diese Daten auszulesen: EVCC kann die Informationen über die Auto-Hersteller-Clouds auslesen. Das aufzusetzen ist etwas Bastelei, wir haben hier: https://www.warp-charger.com/evcc.html eine Anleitung

Erzeuge am besten ein Ladeprotokoll, wenn das das nächste Mal auftritt. Dazu unter Wallbox -> Ladestatus unter Lade­proto­koll erstellen auf Start klicken, dann beginnt die Aufzeichnung (in deinem Browser, also den Tab nicht schließen!). Dann lass es ein paar Mal zwischen 2 und 3 pendeln, und klicke dann auf Stop + Download. Das Protokol kannst du auch hier posten, dann sehen wir hoffentlich genauer, was das Problem ist.

The LocalAuthList allows the charger to authenticate some NFC tags without asking the server. However the server is still notified of the transaction. Also this is not implemented yet. We currently support the Core and SmartCharging profiles. If I understand you correctly, you want to charge without the server being notified, if you use a locally configured tag? That is AFAIK not possible with OCPP, because the server is at least notified about every transaction and can use a RemoteStopTransaction request to stop a running transaction. A possible solution (depending on your provider) could be to register a (set of) NFC card(s) that you use for local (payed by yourself?) charges and another (set of) NFC card(s) that you use for "official" charges.

Was für ein Bricklet und Callback benutzt du genau? Ich habe ad-hoc ein RGB LED Button Bricklet getestet und das funktioniert zumindest: $ tinkerforge listen 127.0.0.1 connected 127.0.0.1 sent 'dispatch rgb-led-button-bricklet Enx button-state-changed\n' b'state=button-state-pressed\n' sent to 127.0.0.1 b'state=button-state-released\n' sent to 127.0.0.1 b'state=button-state-pressed\n' sent to 127.0.0.1 b'state=button-state-released\n' sent to 127.0.0.1 b'state=button-state-pressed\n' sent to 127.0.0.1 b'state=button-state-released\n' sent to 127.0.0.1 mit netcat habe ich dispatch... geschickt und dann die state= Pakete empfangen als ich den Knopf gedrückt habe: $ netcat localhost 4217 dispatch rgb-led-button-bricklet Enx button-state-changed state=button-state-pressed state=button-state-released state=button-state-pressed state=button-state-released state=button-state-pressed state=button-state-released

https://github.com/Tinkerforge/esp32-firmware/commit/22ea2412 sollte das fixen. Ich nehme mal auf die TODO-Liste auf, Jenkins beizubringen das Repo immer mal "clean" neuzubauen. Im Moment machen wir das absichtlich nicht, damit die 14 Firmwarevarianten nicht so lange kompilieren :D

We've sent them an e-mail. In theory this should work. I'm not 100% sure how EVCC behaves if the OCPP server does not allow a charge to start. But I have not tested this in a long time, maybe it works just fine now.

This should just work because OCPP is an open standard, so every server and client implementation should be able to talk to one another. There are however some OCPP related bug fixes that will be released with the next firmware (~ this or next week). As far as I know, nobody has tested the implementation against lastmilesolutions.com yet. So please report back when you had the chance to test this.

Das hängt davon ab, wie du EVCC konfigurierst. Laut deren Dokumentation gibt es resetOnDisconnect, damit kannst du festlegen, ob, wenn das Fahrzeug abgezogen wird, wieder in den Standardlademodus gewechselt, oder der aktuelle Lademodus beibeihalten wird. Wenn die Steuerung ausfällt, kannst du prinzipiell mit dem letzten Strom, den EVCC gesetzt hatte, weiterladen. Wenn EVCC als letztes blockiert hatte (also 0 Ampere vorgegeben) dann lädt die Wallbox erstmal nicht. Es könnte jetzt sein (habe ich durch spontanes Suchen im EVCC-Repo nicht herausgefunden), dass EVCC einen last-Will setzt. Das ist eine MQTT-Nachricht, die wirken soll, wenn die Verbindung abbricht o.Ä.. Wenn das der Fall wäre, dann könnte EVCC das Laden freigeben, wenn es abstürzt. Auf Wallbox-Seite gibt es im Moment keinen Watchdog o.Ä. der auslöst, wenn die externe Steuerung seit langem nicht gesetzt wurde. Das ist ein interessanter Gedanke, habe ich hier: https://github.com/Tinkerforge/esp32-firmware/issues/284 mal aufgeschrieben, damit er nicht verloren geht. Wenn EVCC ausfällt, dann musst du die externe Steuerung aber nicht komplett deaktivieren. Du kannst dann unter Wallbox -> Ladecontroller die Ladestromgrenze der externen Steuerung (auf 32 Ampere) zurücksetzen: Das hat den Vorteil, dass wenn EVCC wieder läuft, du dann nicht erst die externe Steuerung wieder aktivieren musst.

Wenn ich das Log richtig interpretiere, ist: Zwischen dem 19.04 und dem 24.04 die Kommunikation zum Zähler abgerissen. D.h. entweder ist er, oder das EVSE kaputt, oder die Kabel sind nicht richtig verbunden. Zwischen dem 20.06 und dem 23.06. das EVSE neugestartet. Vermutlich weil du Firmware 2.1.3 installiert hast (die wurde am 23.06. veröffentlicht) Firmware 2.1.3 ist die erste Firmware mit Zählerüberwachung. Mit älteren FIrmwares hat eine Wallbox nicht gespeichert, ob sie eine Smart oder Pro ist, sondern bei jedem Start wird geprüft ob ein Zähler gefunden wird. Die Zählerüberwachung wird deshalb erst aktiviert, wenn mit Firmware >= 2.1.3 mindestens einmal ein Zähler gefunden wird (sonst würden wir auf allen Smart-Wallboxen das Laden blockieren). Da dein Stromzähler seit April nicht erreichbar ist, wurde die Zählerüberwachung also nie aktiviert und deshalb konntest du weiter laden. Das heißt, dass sich wirklich der Stromzähler aufgehangen haben muss, oder zumindest Teile von dessen Software (da er ja prinzipiell weitergelaufen ist, aber die RS485-Kommunikation nicht). Das EVSE und der ESP wurden im Zuge des Firmware-Updates im Juni neugestartet und das offensichtlich hatte nicht geholfen. Da der Zähler jetzt gefunden wurde, kannst du unter Wallbox -> Ladeeinstellungen nachsehen, ob die Zählerüberwachung jetzt aktiviert ist.

Das habe ich mal an die Chefs weitergegeben. Gute Idee! Nächste oder übernächste Woche kommen neue Firmwares, da wird das Zertifikatsmanagement zumindest für OCPP enthalten sein.

Manchmal braucht es ja einfach noch eine Erinnerung ;) https://www.warp-charger.com/evcc.html?v=2#evcc-wem-mqtt Relevante Änderungen sind dieser Abschnitt und beim Ausführen von evcc configure, dass der Energy-Manager-Topic-Präfix angegeben werden muss.

Das müssen wir in der Anleitung anpassen. Die Manpage von Mosquitto sagt Also muss man in der Tat den Pfad zur Config-Datei mitgeben, bzw. mosquitto als systemd-Service starten. Danke für den Hinweis!

Oder statt dem warp-Environment das warp_with_ocpp-Environment kompilieren.

Wenn du die Phasenumschaltung nachrüsten willst, sieh dir mal an. Da die Umschaltung mit dem Umbau in der Wallbox hinter dem Zähler passiert, hast du dann auch nicht mehr das Problem, dass der Stromzähler neustartet.

Hast du eine WARP1 Pro? Wenn ja, dann verträgt das der eingebaute Stromzähler (SDM72 ohne V2) nicht. Der Zähler startet alle ~ 20 Sekunden neu, wenn man ihn nicht dreiphasig mit Strom versorgt. Falls du einphasig mit Strommessung laden möchtest, kannst du den Stromzähler durch einen SDM630 oder einen SDM72V2 ersetzen, die Software unterstützt beide. Bei einer WARP1 Smart kannst du das problemlos so machen. Ja. Nein. Gut. Das kann im schlimmsten Fall (alter Renault Zoe) das Auto zerstören.

Hm die Widerstandsmessung kommt da wieder nicht weit genug runter: Wenn du das nochmal hast, fahr nochmal von 16 bis 6 Ampere ab, eventuell können wir nochmal nachjustieren.

Falls sich da auf ioBroker-Seite nichts geändert hat, kannst du dessen MQTT-Broker weiterbenutzen, wenn du "Publish own states on connect" deaktivierst. Siehe z.B. hier: Mit Mosquitto sollte es aber auf jeden Fall funktionieren.

Sehr gut :)

Immer gerne. Jetzt sollte auch die Auto-Erkennung des Zählers wieder funktionieren, falls du das noch probieren willst.

Ich habe jetzt erst bewusst auf die Bilder von deinem Umbau geguckt. Beim RS485-Bricklet sind die DIP-Schalter falsch gesetzt. Die musst du auf "Half-Duplex Terminated", also die ersten drei Schalter auf On, der vierte auf Off, so wie hier rechts unten: Wenn du die Box gerade offen hast: Sieh nochmal nach, ob die Verkabelung zwischen RS485-Bricklet und Zähler richtig ist. Siehe Stromlaufplan hier: https://www.warp-charger.com/documents/WARP_Stromlaufplan.pdf

Dann würde ich erwarten, dass die Fehlerzähler hochzählen. Ich fürchte du musst dir mal Brick Viewer installieren, damit wir nachsehen können, was wirklich passiert. Anleitung dazu gibt's hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html (Du brauchst nur den Brick Viewer, nicht Brick Daemon) In @poohnets Firmware ist der Proxy-Modus schon aktiv, d.h. du kannst, wenn du den Brick Viewer installiert hast ihn starten, unter Host die IP oder den Hostnamen der Wallbox eintragen, und dich mit "Connect" verbinden. Du solltest dann u.A. einen Tab für das RS485-Bricklet bekommen. In dem Tab werden die Pakete vom Zähler aufgeführt. Was mich jetzt interessieren würde ist, wenn du noch Auto-Detect (255) aktiv hast, ob dann regelmäßig ein "Read Holding Registers Response" auftaucht und wenn ja was der Data-Wert ist. Wenn du von Auto-Detect auf SDM72 (1) umschaltest, sollten stattdessen "Read Input Registers Response"-Einträge, also das Lesen dern Zählerwerte, auftauchen, weil die Kommunikation dann ja klappt. Das ganze sieht ungefähr so aus: Ich habe für die Fehler am Anfang den Zähler physisch getrennt. Danach klappt das Lesen des Holding Registers (Ich habe einen SDM630 mit Meter-ID 0070) und die Wallbox fängt an die "normalen" Zählerwerte zu lesen.

Das wundert mich auch. Die Erkennung funktioniert ja so, dass wir ein spezifisches Register vom Stromzähler lesen, in dem dessen Typ-ID steht. Es müsste also im Eventlog immer mindestens eine der folgenden Meldungen auftauchen SDM72DM detected. (oder anderer typ) Found unknown meter type 0x%x. Assuming this is a SDM72DM. (das würde die unbekannte ID ausgeben) Meter type override set to SDM72DM. (oder anderer typ) Wenn keine der Meldungen auftaucht, dann antwortet der Zähler nicht auf den Lese-Request. @Little_Company hattest du garkeine dieser Meldungen als du den type_override noch nicht gesetzt hattest? Wenn du das nochmal testen willst, kannst du die Auto-Erkennung wieder aktivieren. Mit der neuen Firmware: {"method":"PUT", "url":"/meter/type_override_update", "payload":255} bzw. mit der alten {"method":"PUT", "url":"/meter/type_override_update", "payload":"255"} Da du einen SDM72DM (V1) hast, vermute ich dass du einen hast, der als ID entweder 0x0200 (dann hätte es funktionieren sollen) oder 0x0084 (dann hätte die Found unknown meter type... Nachricht ausgegeben werden sollen). Das liegt vermutlich an https://github.com/Tinkerforge/esp32-firmware/commit/c3fa0ab6 Ich hatte da das Problem falsch verstanden (der Payload war davor ein String mit JSON drin, also z.b. mit escapten Anführungszeichen) und seit dem Commt ists direkt genestetes JSON. In eurem Fall also nicht {"method":"PUT", "url":"/meter/type_override_update", "payload":"1"} sondern {"method":"PUT", "url":"/meter/type_override_update", "payload":1} Nach kurzer Diskussion haben wir uns intern geeinigt, dass Variante 2 in der Tat sinnvoller ist, ich habe die Anleitung auf der Recovery-Seite gerade angepasst und editiere gleich meinen alten Post, falls den nochmal jemand findet.

Moin, Auffällig im Debug-Protokoll ist, dass sich der CP-PE-Widerstand (darüber läuft die Kommunikation mit dem Auto) und auch der PP-PE-Widerstand (der gibt an wie viel Strom das Ladekabel verträgt) beide der Maximalwert (also nicht verbunden) sind. Das kann passieren, wenn der rot markierte Stecker in der Wallbox nicht richtig gesteckt ist: Mach am besten die Box einmal stromlos und sieh nach, ob der Stecker richtig steckt. Außerdem sollte zwischen der obersten und untersten Klemme des Steckers ein Widerstand gesteckt sein. (Blau im Bild)

Hm, das wird mit EVCC nicht funktionieren. Kurz zusammengefasst: EVCC kann eigentlich nur NFC/RFID-Tags über die Wallbox lesen, aber nicht Tags injecten. Es gibt da noch einen Spezialfall, aber nur für Keba-Wallboxen. Ich zitiere mal aus der Mail und D.h. selbst bei der Keba wird immer nur ein und dieselbe Tag-ID geschickt, egal welches Fahrzeug erkannt wurde. Wenn du also die Ladefreigabe/SoC-Laden über EVCC und zur Abrechnung pro Fahrzeug/Benutzer verschiedene NFC-IDs an die WARP2 schicken willst, musst du das entweder physisch machen (also das Tag dranhalten wenn du das Auto ansteckst), oder über die APIs mit einem Script, FHEM, o.Ä. steuern.