rtrbt

Firmware: WARP 2.2.0 und WARP2 2.2.0 Blogpost über die neuen Features, sowie aktualisierte API-Dokumentation folgen in Kürze. Automatisierung hinzugefügt Unterstützung für WPA Enterprise (EAP-TLS, EAP-PEAP und EAP-TTLS) hinzugefügt Stromzähler-Implementierung überarbeitet: meters-API und Unterstützung von bis zu zwei Stromzählern hinzugefügt Auslesen von SunSpec-Stromzählern und -Wechselrichtern hinzugefügt Konfigurierbaren API-Stromzähler hinzugefügt (nur WARP2) Unterstützung der Eltako DSZ15DZMOD und YTL DEM4A Stromzähler hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.0) Zurücksetzbare Energie-Import- und -Export-Werte hinzugefügt Ladetracker usw. verwenden jetzt Energie-Import- statt wie bisher Import+Export-Wert. Wechsel findet beim nächsten Löschen der Ladevorgänge statt. Fehlenden "Durchschnittliche Spannung gegen Neutralleiter"-Messwert des SDM72v2 hinzugefügt (nur WARP2) Maximum der (lastgemanagten) Wallboxen, NFC-Tags und Benutzern auf 32 erhöht API um Ladelimits neuzustarten hinzugefügt Ausgabe im Ereignislog für Zählerüberwachung hinzugefügt (nur WARP2) OCPP-Transaktions-ID zu gemeldeten Stromzählerwerten hinzugefügt Übersetzungen verbessert MQTT-Performance verbessert (nur WARP2) OCPP-Nutzerinterface verbessert WLAN-Access-Point-Performance, falls gleichzeitig eine WLAN-Verbindung aufgebaut wird, verbessert Fehlermeldungen in Eingabefeldern verbessert (nur WARP2) DC-Fehler-Nutzerinterface verbessert. Unterstützung für X804-Sensor hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.0) (nur WARP2) Diodenprüfung verbessert (durch Update auf Ladecontroller-Firmware 2.2.0) Schütz- und PE-Fehler getrennt Unterstützung von TLS-Versionen vor 1.2 entfernt Hinzugefügt, dass WLAN-Access-Point bei instabiler WLAN-Verbindung länger geöffnet bleibt Sichergestellt, dass zum WLAN-AP mit der besten Empfangsqualität verbunden wird Subnetz-Konfiguration des WLAN-Access-Points repariert Sichergestellt, dass Lastmanagement erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind Sichergestellt, dass WLAN-HT40-Modus immer deaktiviert bleibt RFID-Tag-Register im Keba-Emulationsmodus ohne Stromzähler repariert Web-Interface-Labels die fehlende IDs referenzieren entfernt Änderung eines konfigurierten TLS-Zertifikats repariert Reparatur der Zuordnung von NFC-Tags zu Nutzern beim Start der Wallbox hinzugefügt Funktion des Zurück-Buttons bei Aufruf des Webinterfaces repariert Tastatureingabe in Datumsfeldern repariert Gemeldetes Intervall des Ladestroms in der MQTT-Auto-Discovery repariert Zeitzonen-Datenbank aktualisiert Anzeige der maximalen Anzahl von aufgezeichneten Ladevorgängen (7680) hinzugefügt Repariert, dass Watchdog des verfügbaren Stroms des Lastmanagements permanent auslöste Anzeige von LED-Blinkmustern während des Ladevorgangs erlaubt (durch Update auf Ladecontroller-Firmware 2.2.0 (WARP2) bzw. 2.1.9 (WARP1)) Sichergestellt, dass Ladevorgang nicht sofort blockiert wird, wenn die externe Steuerung aktiviert wird (durch Update auf Ladecontroller-Firmware 2.2.0 bzw. 2.1.9 (WARP1)) Download: WARP 2.2.0 bzw. WARP2 2.2.0

Danke! Teste mal die Kalibrierungsdatei im Anhang. Die kannst du unter Wallbox -> Ladecontroller hochladen (Low-Level-Zustand aufklappen, dann ganz unten unter Kalibrierung) Falls du damit den e-up mit 6 Ampere laden kannst, versuch bitte auch nochmal den Hyundai. Abgesehen davon würde ich gerne dem Ladeprotokoll-Problem mit Safari nachgehen wollen. Mit welcher Safari-Version hast du das probiert? Und auf was für einem System? calibration.json

The pin numbers have changed for the Pi 5. Try this instead:. bricklet.group0.spidev = /dev/spidev0.0 bricklet.group0.cs0.driver = gpio bricklet.group0.cs0.name = gpio422 bricklet.group0.cs0.num = 422 bricklet.group0.cs1.driver = gpio bricklet.group0.cs1.name = gpio421 bricklet.group0.cs1.num = 421 bricklet.group0.cs2.driver = gpio bricklet.group0.cs2.name = gpio424 bricklet.group0.cs2.num = 424 bricklet.group0.cs3.driver = gpio bricklet.group0.cs3.name = gpio425 bricklet.group0.cs3.num = 425 bricklet.group0.cs4.driver = gpio bricklet.group0.cs4.name = gpio426 bricklet.group0.cs4.num = 426 bricklet.group0.cs5.driver = gpio bricklet.group0.cs5.name = gpio423 bricklet.group0.cs5.num = 423 #bricklet.group0.cs6.driver = gpio #bricklet.group0.cs6.name = gpio406 #bricklet.group0.cs6.num = 406 bricklet.group0.cs7.driver = gpio bricklet.group0.cs7.name = gpio405 bricklet.group0.cs7.num = 405 bricklet.group0.cs8.driver = gpio bricklet.group0.cs8.name = gpio404 bricklet.group0.cs8.num = 404 Port G is disabled with this config, because the pin for port G is already marked as in use by Raspberry Pi OS. For this to work, you also have to enable the SPI device manually with raspi-config (Interface Options -> SPI) and then restart. If Brick Daemon starts with this config, please check again that the HAT firmware is up to date with Brick Viewer. Also open the HAT Bricks tab to check whether the HAT is stuck in bootloader mode. Brick Viewer will then show only this: If the HAT is stuck in bootloader mode, reflash the HAT and restart the Pi. Then I would assume that Brick Daemons output contains the following lines: 2024-01-22 15:19:08.678489 <I> <bricklet.c:304> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config 2024-01-22 15:19:08.678495 <I> <bricklet.c:341> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio422, num: 422) 2024-01-22 15:19:08.678530 <I> <bricklet_stack_linux.c:87> Using spidev backend for Bricklets (unsupported suffix 5 after 'Raspberry Pi' in /proc/device-tree/model) 2024-01-22 15:19:08.679837 <I> <bricklet.c:341> Found Bricklet port B (spidev: /dev/spidev0.0, driver: gpio, name: gpio421, num: 421) 2024-01-22 15:19:08.680329 <I> <bricklet.c:341> Found Bricklet port C (spidev: /dev/spidev0.0, driver: gpio, name: gpio424, num: 424) 2024-01-22 15:19:08.680708 <I> <bricklet.c:341> Found Bricklet port D (spidev: /dev/spidev0.0, driver: gpio, name: gpio425, num: 425) 2024-01-22 15:19:08.681120 <I> <bricklet.c:341> Found Bricklet port E (spidev: /dev/spidev0.0, driver: gpio, name: gpio426, num: 426) 2024-01-22 15:19:08.681975 <I> <bricklet.c:341> Found Bricklet port F (spidev: /dev/spidev0.0, driver: gpio, name: gpio423, num: 423) 2024-01-22 15:19:08.682363 <I> <bricklet.c:341> Found Bricklet port G (spidev: /dev/spidev0.0, driver: gpio, name: gpio406, num: 406) 2024-01-22 15:19:08.682811 <I> <bricklet.c:341> Found Bricklet port H (spidev: /dev/spidev0.0, driver: gpio, name: gpio405, num: 405) 2024-01-22 15:19:08.683247 <I> <bricklet.c:341> Found Bricklet port I (spidev: /dev/spidev0.0, driver: gpio, name: gpio404, num: 404) If you get "Found supported HAT..." the HAT and all ports should work again-

Da läuft vermutlich noch eine brickd-Instanz (eventuell als service). Du kannst dir die Logs aber auch in /var/log/brickd.log ansehen

Das Problem ist vermutlich, dass EVCC die externe Steuerung zwar benutzt, aber nicht einstellt, dass Ladevorgänge blockiert sein sollen, wenn die Wallbox komplett neustartet (wie z.B. nach einem Stromausfall). Im Webinterface der Wallbox gibt es dafür im Moment keine Einstellung, aber du kannst das von Hand machen: Gehe auf http://warp2-abcd/recovery (warp2-abcd durch den Namen deiner Wallbox ersetzen) und trage da im Abschnitt API in das obere Textfeld folgendes ein: {"method":"PUT", "url":"/evse/external_defaults_update", "payload":{"current": 0,"clear_on_disconnect": null}} Dann klicke auf "Call API" und dann sollte im unteren Textfeld eine 200 erscheinen. Ab dann ist bei einem kompletten Neustart die Wallbox blockiert, bis EVCC über die externe Steuerung das Laden freigibt.

Das ist sehr interessant. Anscheinend benutzt Raspberry Pi OS/Debian seit kurzen 16K Pages auf dem Raspberry Pi 5 und damit kann diverse Software nicht umgehen: https://github.com/raspberrypi/bookworm-feedback/issues/107 Mir ist spontan nicht klar, warum bei meinen Tests mit dem Pi 5 alles geklappt hatte und du da jetzt reinläufst, da müssen wir nochmal draufschauen. Ein paar Fragen dazu: Hast du Raspberry Pi OS oder ein "echtes" Debian von hier: https://raspi.debian.net/ installiert? Hast du das Betriebssystem frisch für den Pi 5 installiert oder eine ältere Installation für den Pi 5 weiter verwendet? Als einfachen Fix für dich: Laut https://github.com/raspberrypi/bookworm-feedback/issues/107#issuecomment-1773810662 kannst du auf einen Kernel, der 4K Pages verwendet, wechseln, indem du in /boot/config.txt folgendes einträgst: kernel=kernel8.img Damit sollten die Probleme weg sein.

Try extern Dimmer dimmer; and then void set_iao_out(uint16_t voltage) { tf_industrial_analog_out_v2_set_voltage(&dimmer.iao, voltage); } instead. This should work because all modules are instanciated in the generated file src/modules.cpp.

Was du angehangen hast ist ein Ladeprotokoll, aber aus irgendeinem Grund fehlt der relevante Teil in der Mitte. Hattest du den Browser zwischenzeitlich geschlossen bzw. hatte das Webinterface die Verbindung verloren o.Ä.? Das Protokoll wird in dem Browser-Tab aufgesammelt, in dem du Start klickst.

To use the HAT Brick with a Raspberry Pi 5, you'll have to update the HAT's firmware to 2.0.4 and install Brick Daemon 2.4.5 on the Pi. Updating the HAT Firmware with only a Pi 5 is possible but difficult. Can you temporarily plug the HAT on an older Pi, install Brick Daemon there and update the HAT Firmware with Brick Viewer?

Problem 1 sollte hiermit gelöst sein (kommt in der nächsten Firmware): Dafür habe ich ein Issue aufgemacht. https://github.com/Tinkerforge/esp32-firmware/issues/311

Mit der Firmware im Anhang kannst du die CP-Trennungszeit einstellen. Zumindest für die CP-Trennung, die der WEM durchführt um die Phasen zu wechseln. Es gibt eine neue API energy_manager/cp_reconnect_delay, mit der du die Zeit, die CP getrennt ist, erhöhen kannst. Standardmäßig steht das auf 0, also ist CP nur getrennt solange wie es dauert die Phasen zu wechseln. Du kannst aber bis zu 255 (Sekunden) Verzögerung setzen, z.B. so für 30 Sekunden: curl http://wem-abcd/energy_manager/cp_reconnect_delay -d 30 Wenn du die Zeit setzt, musst du nicht neustarten, aber benutze die API lieber nicht während gerade ein Phasenwechsel läuft. Abgesehen von der Änderung sollte die Firmware identisch zu WEM 1.0.8 sein. energy_manager_firmware_1_0_8_65a153e2_720dd21df1e5f58__merged.bin

Da ist Modbus leider etwas verwirrend: Es gibt Registernummern, die bei 1 beginnen und Registeradressen, die bei 0 beginnen. Also z.B. das Register mit der Adresse 200 hat die Registernummer 201. Viele Hersteller bringen das auch in den Anleitungen durcheinander. Außerdem gibt es die Präfixe, die im Endeffekt den Typ des Registers angeben (Weshalb die oft weggelassen werden): 0 für Coils (les- und schreibbare 1-Bit-Werte) 1 für Discrete Inputs (nur lesbare 1-Bit-Werte) 3 für Input Registers (nur lesbare 16-Bit-Werte) 4 für Holding Registers (les- und schreibbare 16-Bit-Werte) Iin deinem Fall kann es also sein, dass du nicht bei 300200 anfangen musst zu lesen, sondern bei 300199 oder 300201. Um zu testen, ob die Kommunikation prinzipiell funktioniert, kannst du auch mit "Read Holding Registers" das Register 401100 (oder 401099 oder 401101) lesen. Da solltest du eine 1 zurückbekommen, weil dort die Slave-Adresse steht.

Nochmal für mein Verständnis: Normalerweise funktioniert es mit Energy Manager nicht, und du siehst, dass er der Wallbox immer erst 8 A zuteilt, statt den erwarteten 16 A. Das ist erstmal unerwartet, dazu haben wir sber kein Energy Manager Log mit aktivem Stromverteilungsprotokoll (Im Log unten die Einträge ab "Redistributing current") In deinen Logs vom 13.12. hattest du aber den Fall, dass sofort 16 A zugewiesen wurden, das Auto lädt aber trotzdem nicht. Da bleibt die Frage, ob das ein einmaliger Effekt war, oder ob völlig egal ist, ob der WEM 8 oder 16 A zuteilt. Im Log sieht das dann so aus: 2023-12-13 16:38:25,601 Redistributing current 2023-12-13 16:38:25,602 1 charger requests current. 16000 mA available. 2023-12-13 16:38:25,602 stage 0: Calculated target for warp2-Garage (warp2-Garage.local) of 8000 mA. 8000 mA left. 2023-12-13 16:38:25,612 stage 0: 8000 mA still available. Recalculating targets. 2023-12-13 16:38:25,623 stage 0: Recalculated target for warp2-Garage (warp2-Garage.local) of 16000 mA. 0 mA left. 2023-12-13 16:38:25,634 stage 2: Unthrottled warp2-Garage (warp2-Garage.local) to 16000 mA. Man sieht, dass erst 8 A zugeteilt werden, dann aber sofort auf 16 A erhöht wird. Die 8 A werden auch nicht zur Wallbox geschickt, sondern erst das, was in stage 1 oder 2 berechnet wird. Kannst du nochmal versuchen mit aktivem Stromverteilungsprotokoll (das sollte dauerhaft aktiv sein wenn du es nicht per curl wieder deaktiviert hast) zu erzeugen, dass der WEM nur 8 A zuteilt?

Moin, Als vorzeitiges Weihnachtsgeschenk findet Ihr im Anhang jeweils eine Beta-Version der WARP(2) Charger Firmware 2.2.0 und eine Beta-Version der WARP Energy Manager Firmware 2.0.0 mit folgenden Änderungen: (genauere Dokumentation folgt mit den nicht-Beta-Firmwares im neuen Jahr) API des Energy Managers geändert An der API des Energy Managers mussten wir einige Änderungen vornehmen, da bisher Regeln ähnlich zur Automatisierung (siehe nächster Punkt) in energy_manager/config gespeichert wurden. Automatisierung Im Menüpunkt Wallbox -> Automatisierung, bzw. Energy Manager -> Automatisierung können bis zu 14 Regeln konfiguriert werden, die festlegen, wie Wallbox oder Energy Manager auf bestimmte Ereignisse reagieren. Es kann beispielsweise auf einen der Schalteingänge, eine MQTT-Nachricht, ein NFC-Tag usw. reagiert werden und, falls eins der Ereignisse eintritt, können verschiedene Aktionen ausgelöst werden. Hier ein paar Beispiele: Verbessere Stromzählerbehandlung Wie schon in der SunSpec-Beta beschreiben, haben wir in den vergangenen Monaten die Behandlung von Stromzählern umgestellt Der Energy Manager kann jetzt Werte von bis zu 7 Stromzählern auslesen, die Wallboxen bis zu 2 Stromzähler. Beide Geräte können Stromzähler per SunSpec auslesen, außerdem haben wir einen anpassbaren API-Zähler hinzugefügt. Die alte API, die nur mit einem Stromzähler arbeiten kann, unterstützen wir weiterhin, damit bestehende Software weiter funktioniert. Die alte API liest immer den ersten konfigurierten Stromzähler. Das schreiben von Stromzählerwerten über die alte API ist weiterhin möglich, bei Wallboxen muss aber zunächst ein API-Zähler auf der ersten Position angelegt werden, der beispielsweise die SDM630-Vorlage verwenden kann. Weitere Änderungen - Unterstützung für WPA Enterprise EAP-TLS, EAP-PEAP und EAP-TTLS hinzugefügt - (nur WARP2/WEM) Unterstützung für Eltako DSZ15DZMOD und YTL DEM4A hinzugefügt - Unterstützung für zurücksetzbare Import/Export-Energie-Werte hinzugefügt - Auf Import-Energie für Ladetracker, usw gewechselt. Der Wechsel wird durchgeführt, wenn alle getrackten Ladevorgänge gelöscht werden - (nur WARP2/WEM) Unterstützung für bis zu 32 gesteuerte Wallboxen hinzugefügt - (nur WARP2) Unterstützung für bis zu 32 NFC-Tags und Benutzer hinzugefügt - API zum Neustarten der Zeit-/Energielimits hinzugefügt - Warnung im Ereignislog hinzugefügt, wenn Stromzähler hängt - Warnung im Ereignislog hinzugefügt, wenn LAN- und WLAN-Verbindung parallel benutzt werden - (nur WARP2) OCPP-Transaktions-ID zu gesendeten Stromzählerwerten hinzugefügt - Übersetzungen verbessert - Behandung von Lastmanagement-Paket-Bursts verbessert - Performance beim Senden großer MQTT-Datenmengen verbessert - OCPP-UI verbesser - Robustheit und Geschwindigkeit des WLAN-Access-Point, während eine WLAN-Verbindung aufgebaut wird, verbessert - Fehlerrückmeldung im Webinterface verbessert - (nur WARP2) DC-Fehlerstromschutz-Statusanzeige verbessert. Unterstützung für X804 hinzugefügt. (EVSE Bricklet firmware 2.2.0) - (nur WARP2) Diodenerkennung verbessert (EVSE Bricklet firmware 2.2.0) - (nur WARP2) Anzeige von Schütz- und PE-Fehlern aufgeteilt - Hinweis auf aktives Capslock bei Passworteingabefeldern hinzugefügt - Unterstützung von TLS-Versionen älter als 1.2 entfernt - Hinzugefügt, dass WLAN-Access-Point als Fallback 5 Minuten aktiv bleibt, wenn innerhalb der ersten 30 Sekunden nach Start keine Netzwerkverbindung aufgebaut wurde - Sichergestellt, dass sich zum WLAN-AP mit dem besten Empfangswert verbunden wird - Sichergestellt, dass nur funktionierende Subnetzmasken für WLAN-Access-Point konfiguriert werden können - Sichergestellt, dass Lastmanager erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind - RFID-Tag-Registers im Keba-Emulationsmodus repariert, wenn kein Stromzähler verfügbar ist - Sichergestellt, dass Webinterface nicht nicht existierende IDs referenziert - Änderung von TLS-Zertifikaten repariert - Hinzugefügt, dass Zuordnung von NFC-Tags zu Nutzern beim Neustart repariert wird - Sichergestellt, dass der Zurück-Button des Browsers immer funktioniert - Tastatureingabe in Datumseingabefeldern repariert - Wertebereich des Ladestroms in der MQTT-Auto-Discovery repariert energy_manager_firmware_1_0_95_65847481_merged.bin warp2_firmware_2_1_90_6584744a_merged.bin warp_firmware_2_1_90_658473e6_merged.bin

Prinzipiell: So neu, wie die ganze Spezifikation ist, kannst du davon ausgehen, dass Stand heute kaum ein Netzbetreiber schon die Infrastruktur für die Drosselung hat. Laut https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/BSI_TR-03109-5_231112.html ist das hier die Spec: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR-03109-5_Kommunikationsadapter.pdf Das Setup scheint zu sein, dass ein Smart Meter (Gateway) mit "CLS" per TLS redet und als TLS-Proxy dem Netzbetreiber darauf direkt Zugriff gibt. Das CLS ist aber soweit ich das verstehe ein separates Stück Hardware. (Ich habe noch noch raus was das sein soll, auf der BSI-Seite wird das zu Certified Lotus Specialist expandiert. Die Abkürzung ist anscheinend doppelt belegt :D ) Das kommt darauf an, wie du das siehst: Laut der Spec übersetzt ein CLS von der standardisierten Schnittstelle über TLS (für die Netzbetreiber) auf etwas spezifisches für die Geräte die gesteuert werden sollen. Da du die WARP2 per OCPP, Modbus TCP, MQTT, HTTP, dem Abschalteingang usw. steuern kannst, würde ich erwarten, dass sich eine CLS findet, die die Wallbox steuern kann. Falls sich da ein Standard etabliert, der eins der Standardprotokolle spricht, werden die Wallboxen damit funktionieren, notfalls über ein Firmware-Update, falls wir da konkret irgendetwas fixen müssen.

Hier der versprochene detaillierte Post. (Überspring einfach was du schon weißt). Kommunikation zwischen Wallbox und Auto Die ganze Kommunikation zwischen Wallbox und Auto funktioniert wie folgt: Es gibt den Kontakt CP (Control Pilot), an den die Wallbox 12V anlegt. Wenn du ein Auto ansteckst, verbindet das Auto CP und Ground mit einem 2,7kΩ Widerstand, woraufhin die Spannung auf 9V fällt. Auto und Wallbox können diese Spannung messen und sehen deshalb beide (du könntest ja eine Wallbox mit Dose haben), dass das Kabel verbunden ist. Die Wallbox kann auf CP ein 1kHZ-PWM anlegen und anhand des Duty-Cycle (also des Verhältnisses zwischen der Zeit, die 12V und der Zeit die 0V anliegen) kommunizieren, wie viel Strom das Auto maximal ziehen darf. Wenn kein Strom verfügbar ist (weil z.B. EVCC gerade blockiert in deinem Setup), dann liegt die ganze Zeit 12V an. Wenn Strom verfügbar ist, also das CP-PWM läuft, dann darf das Auto einen weiteren Widerstand zwischen CP und Ground parallel schalten, sodass insgesamt 880Ω anliegen, die Spannung fällt dann auf 6V. Sobald die Wallbox das sieht, schaltet sie das Schütz und das Auto bekommt Strom. Mehr dazu hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung tl;dr: Die Wallbox signalisiert also dem Auto, wie viel Strom maximal zur Verfügung steht, das Auto kann dann auf "Ich möchte laden" wechseln und wenn es das tut, schaltet die Wallbox das Schütz. Jetzt der Interessante Teil: Wenn das Auto nicht 30 Sekunden, nachdem die Wallbox Strom anbietet, den Widerstand anlegt und damit signalisiert, dass es laden möchte, geht die Wallbox davon aus, dass die Ladeelektronik des Autos im Stand-By ist. Wenn jetzt der "Fahrzeugweckruf" aktiviert ist, trennt die Wallbox CP für 4 Sekunden und verbindet CP danach wieder. Aus Sicht des Autos sieht das so aus, als ob das Ladekabel auf Wallboxseite rausgezogen wurde und nach 4 Sekunden wieder eingesteckt. Wenn CP wieder verbunden wurde, läuft sofort das PWM, also ist aus Sicht des Autos sofort Strom verfügbar. Laut IEC-Spezifikation ist das das Vorgehen, um ein Auto aufzuwecken. Das ist aber in der Spezifikation relativ neu, nur informativ und bezieht sich auf "difficulties encountered with some legacy EVs". Kommunikation zwischen Energy Manager und Wallbox Der Energy Manager benutzt das Lastmanagementprotokoll um Wallboxen zu steuern. Das ist eigentlich relativ trivial: Der Energy Manager gibt einer Wallbox sekündlich vor, wie viel Strom sie maximal einem Auto anbieten darf, und außerdem ob CP getrennt oder verbunden sein soll. Der Energy Manager muss CP trennen können, da es ein paar Autos (z.B. alte Zoes) gibt, deren Ladeelektronik kaputt geht, wenn die Wallbox von ein- auf dreiphasig wechselt, während das Auto angeschlossen ist. Das Vorgehen, wenn der Energy Manager einen Phasenwechsel macht ist also: Alle Wallboxen auf 0 Ampere runterregeln Warten bis alle Schütze abgeschaltet sind CP an allen Wallboxen trennen Zwischen ein- und dreiphasig wechseln CP an allen Wallboxen verbinden und Strom wieder verteilen Aus Sicht des Autos ist das dann so, als ob du das Kabel an einer einphasigen Wallbox abgezogen hast und in eine dreiphasige eingesteckt, ohne dabei das andere Ende des Kabels aus dem Auto zu ziehen. EVCC, Energy Manager und Wallbox EVCC kann WARP-Wallboxen steuern und über den Energy Manager auf die Phasenumschaltung steuern. Aus Sicht von EVCC wird nur die Wallbox gesteuert (indem der maximale Ladestrom vorgegeben wird) und zusätzlich kann EVCC beim Energy Manager einen Phasenwechsel anfordern. Das ist aber auch alles, was EVCC in dem Aufbau tut. Insbesondere steuert EVCC nicht direkt die CP-Trennung. Problem bei deinem Aufbau Das hier ist ein Plot aus dem Debug-Log von oben, mit Energy Manager und aktivem Fahrzeugweckruf. Der charger_state ist 1, wenn ein Auto angeschlossen ist, die Wallbox ihm aber keinen Strom zur Verfügung stellt. Er ist 2, wenn die Wallbox Strom zur Verfügung stellt, das Auto aber nicht laden möchte. Im Plot siehst du, dass CP einmal bei ~ 230 getrennt wird, das ist die Phasenumschaltung des Energy Managers. CP wird dann wieder verbunden und ab dem Moment stehen dem Auto 8 Ampere zur Verfügung. (Auffällig ist hier, dass das Lastmanagement des Energy Managers nur 8 Ampere zur Verfügung stellt, EVCC aber 16 Ampere) Das Auto reagiert dann nicht auf den verfügbaren Strom, weshalb nach 30 Sekunden (bei Eintrag 890) die Wallbox von sich aus nochmal CP trennt und wieder verbindet. Wenn das ganze funktionieren würde, sähe es so aus: Das ist gerade mit einem der Corsas aufgenommen, Aufbau ist der selbe: EVCC steuert WARP2 und Energy Manager. Hier legt das Auto nach der CP-Trennung (für den Phasenwechsel) den zweiten Widerstand an, fordert also Strom an und das Schütz wird geschaltet (Das ist charger_state 3) In den Reports, bei denen dein Auto anfängt zu laden, sehen die Daten ähnlich aus. Was jetzt? Du könntest noch folgendes versuchen: Eventuell ist das Problem wirklich, dass dein Auto manchmal eine längere CP-Trennung braucht und du diesen Fall (warum auch immer) nur erzeugen kannst, wenn die Phasenumschaltung per Energy Manager im Spiel ist. Du kannst aber die CP-Trennung nicht von Hand steuern, wenn der Energy Manager sie steuert. Folgender Trick sollte aber funktionieren: Stelle nochmal den Zustand her, dass dein Auto nicht lädt, obwohl es sollte Ziehe dann am Energy Manager das LAN-Kabel raus. Das führt dazu, dass er nicht mehr Pakete an die Wallbox schicken kann, die CP verbinden oder trennen Stelle dann auf der Wallbox das Lastmanagement von "fremdgesteuert" auf "deaktiviert", speichere das und starte nicht neu! Das Webinterface behauptet zwar, dass das erst nach einem Neustart wirkt, diese spezifische Einstellung greift aber sofort. Du solltest jetzt wieder über die evse/control_pilot_disconnect-API CP trennen und verbinden können. Damit kannst du testen, ob eine längere CP-Trennung (z.B. 3 Minuten) in dieser spezifischen Situation hilft. Wenn das der Fall ist, müssen wir die Länge der CP-Trennung konfigurierbar machen, bzw. einen Peugeot-Modus einbauen. Noch ein anderer Gedanke: Hast du das Problem nur mit dem Peugeot an einer Wallbox oder an beiden?

Würde ich nicht erwarten. Ich habe sicherheitshalber evcc einmal aufgesetzt, testen kann ich das aber erst morgen mit dem Fahrzeug vom Kollegen. Ich melde mich dann nochmal detaillierter.

Sorry, ich schaffe es heute nicht mehr, dir einen detaillierteren Post zu schreiben. Teste bitte nochmal folgendes: Lastmanagement auf der Wallbox deaktivieren EVCC bzw. externe Steuerung auf der Wallbox deaktivieren Manuelle Ladefreigabe aktivieren Auto anstecken (es sollte nicht anfangen zu laden) Warten bis das Auto eingeschlafen ist Ladeprotokoll starten folgendes ausführen: curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'true' && sleep 5 && curl 'http://warp2-Garage/evse/start_charging' -d 'null' && curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'false' (Damit wird CP getrennt, 5 Sekunden gewartet, der Ladestrom freigegeben und CP verbunden. Du kannst unter Wallbox ->Ladestatus -> Low Level Zustand auch dabei zusehen, wie CP getrennt und dann wieder verbunden wird) Das sollte äquivalent zu dem sein, was der Energy Manager tut. Wenn das Auto bei diesem Test auch nicht anfängt zu laden, liegt es am Timing aus CP verbinden und dem PWM mit dem wir den Strom vorgeben.

Hm das Timing bei dem Protokoll mit WEM ist sehr interessant. Ich versuche das morgen mal auf meinem Tisch zu erzeugen, und melde mich dann nochmal.

Damit mein Verständnis richtig ist: Du musst, damit das Auto aufwacht nicht von Hand die API benutzen, sondern auf der Wallbox unter Lastmanagement von "Fremdgesteuert" auf "Deaktiviert" umzustellen reicht? Erstelle bitte von beiden Varianten (also mit Lastmanagement über den WEM und ohne) jeweils ein Ladeprotokoll: Dafür unter Wallbox->Ladestatus bei Ladeprotokoll auf Start klicken, den Tab auflassen (das Protokoll wird im Browser gesammelt) und dann den Ladevorgang starten, bzw. Strom freigeben. Dann sollte das Auto in der einen Variante ja nach ~ 30 Sekunden aufwachen und in der anderen nicht. D.h. wenn du lange genug gewartet hast, dass das Auto aufgewacht ist, bzw. hätte aufwachen sollen, kannst du auf Stop+Download klicken. In den Ladeprotokollen sollen wir dann sehen, was genau auf CP passiert.

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.