rtrbt

Das ist sehr interessant. Hast du die aktuelle Wallbox-Firmware laufen? In Firmware 2.1.2 oder älter gab es das Problem, dass das Lastmanagement die CP-Trennung stört.

Guter Punkt. Füge ich gleich ein. Die ist egal. Die Modbus-TCP-Implementierung ignoriert die Slave-ID komplett.

Ah, sorry. Ich meinte z.B. Register 1000 (der Ladezustand). Den zu schreiben ergibt keinen Sinn, deshalb hat das keinen Effekt wenn du das tust. Das sind alles 32-Bit-Werte also brauchst du 16 (Write Multiple Holding Registers). Wenn der Wert, den du schreiben willst nur 16 Bit groß ist, kannst du aber auch 06 benutzen, wenn die anderen 16 Bit (also das andere Register) schon auf 0 steht. Also wenn du z.B. 6000 (in Hex 0x1770) auf das Holding Register 1003 schreibst (mit 06) dann setzt es den Ladestrom auf 6 Ampere. "Korrekter" wäre aber auf Register 1002 mit Code 16 eine 0x00001770 zu schreiben. Funktionieren sollte beides.

Die Keba-Register sind (obwohl du sie nur lesen, nicht schreiben kannst) Holding Register, die du mit Function Code 3 (Read Multiple Holding Registers) lesen kannst. Bei unserem Registersatz sind Register, die du nur lesen kannst Input Register, die du mit Function Code 4 (Read Input Registers) lesen musst. Edit: Die Register sind in der Tat 16 Bit lang, aber fast alle Werte sind 32 Bit lang und liegen deshalb in zwei Registern hintereinander. Das ist bei dem Keba-Registersatz aber auch so.

Dafür musst du dir die Firmware nicht bauen, du kannst den CP-Disconnect per API kontrollieren. Den aktuellen Zustand siehst du unter Wallbox -> Ladestatus, Low-Level-Zustand aufklappen, 3. Zeile der GPIO, der letzte in der Zeile (ist links auch beschriftet als CP-Disconnect). Wenn der Pin auf Low steht, ist CP verbunden, wenn er auf High steht, ist CP getrennt. CP trennen kannst du im einfachsten Fall auf der Kommandozeile mit curl. Zum Trennen: curl http://warp2-abcd/evse/control_pilot_disconnect -d true Zum Verbinden: curl http://warp2-abcd/evse/control_pilot_disconnect -d false Falls du kein curl zur Hand hast, kannst du die Recovery-Seite der Wallbox benutzen: Unter http://warp2-abcd/recovery bei API folgendes zum Trennen eintragen: {"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": true} Zum Verbinden: {"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": false} Und dann auf Call API klicken. Wenn es klappt bekommst du darunter eine 200 angezeigt. Wenn du das testen willst, solltest du davor unter Wallbox -> Ladeeinstellungen den Fahrzeugwegruf deaktivieren damit der Ladecontroller nicht selbst CP-(Dis)connects auslöst während du testest.

Dann ist das auf jeden Fall das Problem: Die Wallbox trennt im Moment für 4 Sekunden, weil die IEC-Spezifikation das so vorgibt. (Fairerweise als Minimum und im Abschnitt "Information on difficulties encountered with some legacy EVs for wake-up after a long period of inactivity (informative)" ) Ich bespreche mal mit meinem Kollegen, wie wir damit umgehen.

Der Corsa scheint das Problem nicht zu haben: Wir haben einem davon heute 6 Stunden lang angeschlossen gehabt und erst danach den Strom freigegeben. Er hat sofort angefangen zu laden. Nur sicherheitshalber: Hast du unter Wallbox -> Ladeeinstellungen den Fahrzeugweckruf aktiviert? Wenn das nicht aktiv ist, wäre das eine gute Erklärung.

Im Moment ist uns da nichts bekannt. Wir testen morgen nochmal mit einem der Corsas. Eventuell verhalten die sich seit einem Update anders.

Wenn alles richtig verkabelt ist, und der Ladecontroller den Stromzähler findet, solltest du sofort auf der Statusseite den Ladeverlaufsgraphen (am Anfang leer, weil die Wallbox erst anfängt Daten zu sammeln), die aktuelle Leistungsaufnahme und im Menü die Stromzählerunterseite bekommen:

Gute Idee, ist erledigt: https://github.com/Tinkerforge/esp32-firmware/commit/08b7d250

Im Moment funktioniert das nicht, weil zwischen Ethernet und WiFi (und auch dem WiFi Access Point und der WiFi Verbindung) nicht geroutet wird. Siehe auch https://github.com/Tinkerforge/esp32-firmware/issues/14

Das primäre Problem, dass der Lastmanager dir nur 6 Ampere zuteilt ist behoben, ja (schon in 2.1.4). Issues 263 und 264 sind leider noch offen.

Ja. Auch dafür bräuchte es die 248€ Platine von hier: Kurz zum Vergleich: Die (alte) Kommunikation über IEC 61851 ist im Endeffekt eine PWM-Spannung auf der CP-Leitung zu erzeugen und einen Widerstand zu lesen. ISO 15118 ist ein komplexes Protokoll über CAN-Frames über IPv6 (-> deutlich kompliziertere Software) über Powerline (-> deutlich kompliziertere Hardware) auf der CP-Leitung.

Solange kein Auto angeschlossen ist, ist das korrekt. Das Lastmanagement teilt einer Wallbox erst Strom zu, wenn sie den auch braucht. Die traditionelle erste Frage: Benutzt du ioBroker? Dessen MQTT-Broker ist nicht standardkonform und macht gerne mal Probleme. Siehe z.B. hier:

Moin, In den letzten Monaten haben wir daran gearbeitet, dass der WARP Energy Manager mit Stromzählern und Wechselrichtern kommunizieren kann, die das SunSpec-Protokoll implementieren. Damit muss bei unterstützten Stromzählern und Wechselrichtern nicht mehr ein zusätzlicher Stromzähler für den Energy Manager verbaut werden. Der Energy Manager kann dazu jetzt bis zu 7 Stromzähler verwalten und einen beliebigen dieser Stromzähler zur Regelung des PV-Überschussladens verwenden. Changelog (1.0.91 - Beta 2) Invalid Address Fehler bei Gerätesuche für SMA-Geräte repariert Changelog (1.0.92 - Beta 3) Sonderbehandlung für falsche Werte bei KOSTAL-Geräten hinzugefügt. Detektion von Wechselrichter-Messwerten in der Nacht repariert; betrifft insbesondere SMA-Wechselrichter. Performance von SunSpec-Geräten mit float-Modellen verbessert; reduziert das Risiko von Timeouts beim Auslesen. Changelog (1.0.93 - Beta 4) Anzeige der Wechselrichterleistung repariert. Anzeige der Phasenströme bei SMA-Wechselrichtern repariert. Leseperformance verbessert, insbesondere bei ModBus-RTU-Bridges. Changelog (1.0.94 - Beta 5) Wechselrichterleistung wird jetzt in der Tabelle und im Graph angezeigt. Unterstützte Stromzähler Der Energy Manager sollte jetzt Messwerte von allen Geräten auslesen können, die eins der Wechselrichter-Modelle 101 bis 103 bzw. 111 bis 113, oder eins der Stromzähler-Modelle (201 bis 204 bzw. 211 bis 214) anbieten. Eine Liste von zertifizierten Geräten findet sich hier: https://sunspec.org/certified-registry/ (die jeweils unterstützten Modelle werden als "ModBusModels" aufgelistet) Konfiguration eines SunSpec-Stromzählers Gegebenenfalls muss SunSpec zuerst beim Stromzähler oder Wechselrichter aktiviert werden! Unter Energiemanager -> Stromzähler kann ein neuer Stromzähler konfiguriert werden. Aktuell kann die Nummer (von 0 bis 6) des neuen Stromzählers frei gewählt werden. Nach Auswahl der Klasse "SunSpec" können der Hostname oder die IP, sowie gegebenenfalls der Port gewählt werden, auf dem der Wechselrichter oder Stromzähler erreichbar ist. Danach kann eine Gerätesuche gestartet werden. Gefundene Geräte werden aufgelistet, durch Klick auf ein gefundenes Gerät wird es übernommen und kann hinzugefügt werden. Nach Speichern und Neustart sollte der konfigurierte Stromzähler erscheinen: Geänderte API Die Unterstützung von mehr als einem Stromzähler hat dazu geführt, dass wir die Stromzähler-APIs grundlegend geändert haben. Wenn die SunSpec-Unterstützung die Beta-Phase verlässt, werden wir (über ein Legacy-API-Modul) die alte Zähler-API nachbilden, in dieser Beta ist die alte API aber noch nicht implementiert. Wenn eine externe Steuerung (EVCC, Node-RED usw.) die Zählerwerte des Energy Managers lesen oder schreiben soll, wird das mit dieser Beta-Firmware NICHT funktionieren. Dann bitte auf der alten Firmware bleiben, bzw. auf die frisch veröffentlichte 1.0.8 aktualisieren. Wir freuen uns wie immer auf euer Feedback, insbesondere interessiert uns: - Mit welchen Geräten funktioniert die SunSpec-Anbindung (nicht)? - Tauchen unerwartete Messwerte auf? Ein Beispiel, dass wir bei einem KOSTAL Smart Energy Meter beobachtet haben (Später werden wir für solche Fälle Work-Arounds einbauen): Edit: Veraltete Firmware entfernt.

Zum zweiten ja. Ich habe gerade Firmware 2.1.5 mit TLS-Zertifikatsverwaltung veröffentlicht. Wenn du das auch in der WARP-on-Steroids-Firmware brauchst, musst du @poohnet nochmal anpingen.

Firmware: WARP Energy Manager 1.0.8 Support für Reverse-Proxys verbessert Konfiguration des alternativen DNS-Servers repariert Anleitung des API-Aufrufs auf der Recovery-Seite repariert Verlorene MQTT-Subscriptions und Nachrichten nach Verbindungsaufbau repariert Sichergestellt, dass Konfigurationen nicht über MQTT durch einen nicht-standardkonformen Broker zurückgesetzt werden Sichergestellt, dass API bei gleichzeitigem Zugriff über verschiedene Backends (MQTT, HTTP) konsistent bleibt Zuverlässigkeit und Performance des WebSocket-Verbindungsaufbaus verbessert Performance des Flash-Speichers verbessert Hinzugefügt, dass Ereignis-Log-Nachrichten sofort angezeigt und im Browser gesammelt werden Auto-Scrolling zu Ereignis-Log hinzugefügt Problem mit der Größenberechnung von Tabellen in Firefox behoben Übersetzungen verbessert Sichergestellt, dass Nulllinie nicht außerhalb eines Graphen gezeichnet wird Lücke in der Datenaufzeichnung direkt nach Neustart behoben Download: WARP Energy Manager 1.0.8

Firmware: WARP 2.1.5 und WARP2 2.1.5 (Nur WARP2) Verwaltung für TLS-Zertifikate hinzugefügt; eigene Zertifikate können für die OCPP-Verbindung verwendet werden Support für Reverse-Proxys verbessert Konfiguration des alternativen DNS-Servers repariert Anleitung des API-Aufrufs auf der Recovery-Seite repariert (Nur WARP2) OCPP-Verbindungsstabilität verbessert (Nur WARP2) OCPP-Unterseite, -statusanzeige und -debugausgabe verbessert Verlorene MQTT-Subscriptions und Nachrichten nach Verbindungsaufbau repariert Sichergestellt, dass Konfigurationen nicht über MQTT durch einen nicht-standardkonformen Broker zurückgesetzt werden Sichergestellt, dass API bei gleichzeitigem Zugriff über verschiedene Backends (MQTT, HTTP) konsistent bleibt Zuverlässigkeit und Performance des WebSocket-Verbindungsaufbaus verbessert Sichergestellt, dass externe Steuerung bei Aktivierung auf freigegeben (32 Ampere) gesetzt wird Performance des Flash-Speichers verbessert Hinzugefügt, dass Ereignis-Log-Nachrichten sofort angezeigt und im Browser gesammelt werden Auto-Scrolling zu Ereignis-Log hinzugefügt Problem mit der Größenberechnung von Tabellen in Firefox behoben Übersetzungen verbessert Sichergestellt, dass Nulllinie nicht außerhalb eines Graphen gezeichnet wird Download: WARP 2.1.5 bzw. WARP2 2.1.5

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.