rtrbt

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): energy_manager_firmware_1_0_94_65578f18_e09f667df6273d1_feature-meters-7_merged.bin

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.

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.