poohnet

Alles gut, das hatte ich so auch nicht verstanden... 🙃 ... und das ist doch schon mal eine wichtige Erkenntnis. Bitte steckt da von eurer Seite nicht noch mehr Arbeit rein. Der Rollback funktioniert grundsätzlich, d. h. ich werde jetzt erstmal die Logs analysieren und berichten.

Nicht nur angeblich. Der Pi in der UV fungiert seit mehr als zwei Jahren u. a. als AP und bislang hatte ich damit noch keinerlei Probleme. Irgendwas scheint beim Rollback anders zu laufen als bei einem normalen Firmwareupdate. Ich schaue heute Abend aber mal in die Logs - und schalte den BSSID Lock aus…

Hi @MatzeTF , jetzt wird's richtig spooky und wahrscheinlich wirst du mich jetzt für verrückt erklären - vermutlich würde ich es selbst nicht glauben, wenn ich nicht ein Console Log hätte... TL;DR: Der Rollback der Firmware auf die vorherige Version funktioniert korrekt, allerdings kann sich der Brick danach nicht mehr per WLAN verbinden. Auch ein (zugegebenermaßen recht kurzes) stromlos schalten hat ändert daran erstmal nichts. Erst in dem Moment, als ich das Notebook per USB angeschlossen habe, wurde die Verbindung hergestellt. Hier die zugehörigen Logs: Installation der problematischen Firmware 2026-01-27 19:03:18,501 | firmware_update | Installing firmware from file upload 2026-01-27 19:03:18,752 | firmware_update | Changed app1 partition OTA state from undefined to invalid 2026-01-27 19:03:33,571 | evse | external slot default -1 2026-01-27 19:03:46,637 | evse | external slot default -1 2026-01-27 19:03:58,739 | firmware_update | Firmware successfully installed 2026-01-27 19:03:58,811 | tools | Reboot requested by firmware update. 2026-01-27 19:03:59,847 | modbus_tcp_srvr | Client 192.168.110.144:41254 disconnected: ServerStopped (error -1) 2026-01-27 19:03:59,850 | modbus_tcp_srvr | Client 192.168.100.8:50438 disconnected: ServerStopped (error -1) 2026-01-27 19:03:59,861 | meters_mbtcp | Meter 0: Disconnected from 192.168.110.145:502 2026-01-27 19:03:59,874 | meters_mbtcp | Meter 0: Modbus error repeated 1 time while reading 16 registers starting at address 366: Aborted (257) / Connection got closed 2026-01-27 19:03:59,885 | meters_sun_spec | Meter 2: Disconnected from 192.168.110.144:502 2026-01-27 19:04:01,532 | wifi | Disconnected from WiFi: Unknown reason (WIFI_REASON_ASSOC_LEAVE) (8). Was connected for 643 seconds.1. Reboot nach Installation Firmware inkl. "Core 1 Panic" ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:4980 load:0x40078000,len:16600 load:0x40080400,len:3500 entry 0x400805b4 0,018 | | **** TINKERFORGE WARP2 CHARGER V2.8.17+6978B2D5 **** 0,018 | | Last reset reason was: Software reset via esp_restart (3) Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 0,489 | fs | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used 0,672 | api | WARP2 Charger config version: 2.8.4 (warp) 0,681 | esp32_eth_brick | ESP32 Ethernet Brick UID: XSS Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 1,058 | device_module | Phase Switcher Bricklet found. Enabling Phase Switcher support. 1,096 | ntp | Set timezone to Europe/Berlin 1,287 | wifi | Connecting to WiFi, BSSID lock enabled E (1356) mqtt_client: Client has not connected 1,431 | firmware_update | Firmware is not signed 1,454 | firmware_update | Partitions: app0 (valid, 2.8.17+6978b0a9), app1 (pending-verify, running, 2.8.17+6978b2d5) 1,553 | meters | Meter 0: Meter declared 76 (73) values 1,589 | meters | Meter 1: Meter declared 66 (60) values 1,759 | charge_tracker | Found 6 records: first is 1, last is 6 1,792 | charge_tracker | Last charge record size is 2464 (77, 0) 2,134 | device_module | No NFC Bricklet found. Disabling NFC support. 2,618 | web_server | Starting multi-port server with 2 ports 2,658 | network | mDNS responder started 2,985 | power_manager | External phase switching API enabled, starting with 1p 3,195 | eebus | EEBUS Module disabled 3,316 | event | State evse/phases_connected not found 3,317 | main | Initialization done 3,335 | device_name | This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 3,898 | wifi | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -53dBm, BSSID E4:5F:01:XX:XX:XX 4,411 | wifi | Got IP address: 192.168.110.213/24, GW 192.168.110.1 4,565 | modbus_tcp_srvr | Client 192.168.100.8:47218 connected 5,138 | ethernet | Started after 4033ms 5,371 | network | Network connected (WiFi) 5,377 | meters_speedwire | Meter 1: Joined multicast group 239.12.255.254:9522 5,394 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 2026-01-27 19:04:08,655 | ntp | NTP synchronized at 5,396 2026-01-27 19:04:08,660 | meters_mbtcp | Meter 0: Connected to 192.168.110.145:502 2026-01-27 19:04:08,674 | meters_sun_spec | Meter 2: Connected to 192.168.110.144:502 2026-01-27 19:04:08,825 | meters_sun_spec | Meter 2: Looking for device Mn='SMA' Md='SBSE5.0-50' SN='3023075914' 2026-01-27 19:04:08,835 | meters_sun_spec | Meter 2: Device Mn='SMA' Md='SBSE5.0-50' Opt='' Vr='03.14.24.R' SN='3023075914' is matching 2026-01-27 19:04:08,848 | meters_sun_spec | Meter 2: Enabling quirks mode 0x12 for SMA device 2026-01-27 19:04:09,226 | modbus_tcp_srvr | Client 192.168.110.144:34922 connected 2026-01-27 19:04:09,233 | meters_sun_spec | Meter 2: Configured SunSpec model 701/0 found at 192.168.110.144:502:126:40096 2026-01-27 19:04:09,270 | meters | Meter 2: Meter declared 49 values 2026-01-27 19:04:09,272 | meters_sun_spec | Meter 2: Checking phase voltages for float-is-le32 quirk 2026-01-27 19:04:09,283 | meters_sun_spec | Meter 2: Check for float-is-le32 quirk completed due to normal L3-N voltage value: 226.1 V 2026-01-27 19:04:09,707 | solar_forecast | Using test data Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x40139f72 PS : 0x00060d30 A0 : 0x801f2975 A1 : 0x3ffe6c00 A2 : 0x3ffe13a0 A3 : 0x00000000 A4 : 0x0000002d A5 : 0x3ffe6c18 A6 : 0x3ffb74e0 A7 : 0x3ffc5068 A8 : 0x00000000 A9 : 0x3ffe6be0 A10 : 0x3ffb74a8 A11 : 0x473c1ab7 A12 : 0x3ffe6bdc A13 : 0x00000000 A14 : 0x3ffc50d4 A15 : 0x00000000 SAR : 0x00000001 EXCCAUSE: 0x0000001c EXCVADDR: 0x0000013c LBEG : 0x40083151 LEND : 0x40083159 LCOUNT : 0x00000027 Backtrace: 0x40139f6f:0x3ffe6c00 0x401f2972:0x3ffe6c20 0x4020c620:0x3ffe6c40 0x40117761:0x3ffe6c80 0x4022261e:0x3ffe6ca0 0x40341a52:0x3ffe6cc0 ELF file SHA256: fd51f4e36 Rebooting...2. Reboot nach "Core 1 Panic" inkl. korrektem Rollback - aber ohne WLAN ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:4980 load:0x40078000,len:16600 load:0x40080400,len:3500 entry 0x400805b4 0,017 | | **** TINKERFORGE WARP2 CHARGER V2.8.17+6978B0A9 **** 0,018 | | Last reset reason was: Software reset due to exception/panic (4) Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 0,344 | coredump | Task 'loopTask' caused exception 28: LoadProhibited Backtrace: 0x40139f6f 0x401f2972 0x4020c620 0x40117761 0x4022261e 0x40341a52 0,505 | fs | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used 0,674 | api | WARP2 Charger config version: 2.8.4 (warp) 0,682 | esp32_eth_brick | ESP32 Ethernet Brick UID: XSS Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 1,058 | device_module | Phase Switcher Bricklet found. Enabling Phase Switcher support. 1,092 | ntp | Set timezone to Europe/Berlin 1,274 | wifi | Connecting to WiFi, BSSID lock enabled E (1344) mqtt_client: Client has not connected 1,414 | firmware_update | Firmware is not signed 1,437 | firmware_update | Partitions: app0 (valid, running, 2.8.17+6978b0a9), app1 (aborted, 2.8.17+6978b2d5) 1,448 | firmware_update | Firmware 2.8.17+6978b2d5 rolled back to 2.8.17+6978b0a9 1,512 | meters | Meter 0: Meter declared 76 (73) values 1,548 | meters | Meter 1: Meter declared 66 (60) values 1,711 | charge_tracker | Found 6 records: first is 1, last is 6 1,744 | charge_tracker | Last charge record size is 2464 (77, 0) 2,056 | device_module | No NFC Bricklet found. Disabling NFC support. 2,393 | web_server | Starting single-port server on port 80 2,427 | network | mDNS responder started 2,697 | power_manager | External phase switching API enabled, starting with 1p 2,874 | main | Initialization done 2,882 | device_name | This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 5,132 | ethernet | Started after 4032ms 7,876 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 11,278 | wifi | Connecting to WiFi, BSSID lock enabled 17,702 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 21,283 | wifi | Connecting to WiFi, BSSID lock enabled 27,705 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 31,261 | wifi | Starting scan to select unoccupied channel for soft AP 31,287 | wifi | Scan failed 31,288 | wifi | Connecting to WiFi, BSSID lock enabled 31,764 | wifi | Selecting channel 1 for soft AP 31,944 | wifi | Soft AP started 38,279 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 61,302 | wifi | Connecting to WiFi, BSSID lock enabled 68,151 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 90,782 | require_meter | Charger energy meter stuck or unreachable! Blocking charging. 91,306 | wifi | Connecting to WiFi, BSSID lock enabled 98,156 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 121,310 | wifi | Connecting to WiFi, BSSID lock enabled 128,156 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 151,316 | wifi | Connecting to WiFi, BSSID lock enabled 158,165 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 181,319 | wifi | Connecting to WiFi, BSSID lock enabled 188,167 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 211,323 | wifi | Connecting to WiFi, BSSID lock enabled 218,174 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 241,327 | wifi | Connecting to WiFi, BSSID lock enabled 248,176 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)3. Reboot durch stromlos schalten - WLAN-Verbindung wird erst mit Verbindung des Notebooks aufgebaut Processing empty (board: esp32_brick; platform: https://github.com/Tinkerforge/platform-espressif32.git#tf-54.03.21-2; framework: arduino) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- Terminal on /dev/cu.usbserial-10 | 115200 8-N-1 --- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time --- More details at https://bit.ly/pio-monitor-filters --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H 61,276 | wifi | Connecting to WiFi, BSSID lock enabled 64,140 | wifi | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -53dBm, BSSID E4:5F:01:XX:XX:XX 64,660 | wifi | Got IP address: 192.168.110.213/24, GW 192.168.110.1 66,044 | network | Network connected (WiFi) 66,050 | meters_speedwire | Meter 1: Joined multicast group 239.12.255.254:9522 66,067 | meters_mbtcp | Meter 0: Connected to 192.168.110.145:502 66,073 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 66,084 | meters_sun_spec | Meter 2: Connected to 192.168.110.144:502 66,351 | meters_sun_spec | Meter 2: Looking for device Mn='SMA' Md='SBSE5.0-50' SN='3023075914' 66,353 | meters_sun_spec | Meter 2: Device Mn='SMA' Md='SBSE5.0-50' Opt='' Vr='03.14.24.R' SN='3023075914' is matching 66,365 | meters_sun_spec | Meter 2: Enabling quirks mode 0x12 for SMA device 66,519 | meters_sun_spec | Meter 2: Configured SunSpec model 701/0 found at 192.168.110.144:502:126:40096 66,694 | meters | Meter 2: Meter declared 49 values 66,694 | meters_sun_spec | Meter 2: Checking phase voltages for float-is-le32 quirk 66,705 | meters_sun_spec | Meter 2: Check for float-is-le32 quirk completed due to normal L3-N voltage value: 225.9 V 2026-01-27 19:12:19,385 | ntp | NTP synchronized at 67,066 2026-01-27 19:12:20,128 | solar_forecast | Using test data 2026-01-27 19:12:22,725 | require_meter | Charger energy meter working again. Allowing charging. 2026-01-27 19:12:28,684 | modbus_tcp_srvr | Client 192.168.100.8:50628 connected 2026-01-27 19:13:01,128 | modbus_tcp_srvr | Client 192.168.110.144:51552 connected WTF ?!?!? Wie tief wollen wir noch in dieses "rabbit hole" hinabsteigen?! 😂

Ja klar, kann ich machen. Im Moment regnet es hier aber in Strömen, da schraube ich die Wallbox lieber nicht unter Strom auf ☠️ 😂 Kann man denn den ESP32-Ethernet-Brick gefahrlos per USB anschließen, während er vom Netzteil mit Strom versorgt wird? Oder soll ich nicht besser den Strom abschalten und alles über die USB-Verbindung machen?

Ja, richtig. Ich habe ungefähr zehn Minuten gewartet währenddessen keine "pings" mehr durchgingen, dann die Nachricht geschrieben, die Sicherung ausgeschaltet und den Rechner mit dem Brick verbunden um die Konsolenausgaben zu prüfen. Zu meiner Überraschung habe ich keine Boot-Loop gesehen und das Webinterface war wieder erreichbar. Wie lange sollte es denn dauern, bis der Rollback erkannt/durchgeführt wird und die WARP wieder erreichbar ist?

Nicht ganz: 0x40139f72 in update_evse_limit () at src/modules/eebus/eebus.cpp:84 84 auto limit_mA = eebus.usecases->limitation_of_power_consumption.get_current_limit_w() * 1000 / 230 / evse_common.backend->get_phases();Wird wahrscheinlich aber auf's gleiche hinauslaufen...

Hmm, das war jetzt ein klassicher Fall von "Murphys Law" - kaum hatte ich den Strom abgeschaltet und stattdessen den Rechner verbunden, schon startet der Brick wieder richtig und die Webseite begrüßt mich mit Möchtet ihr trotzdem in den Debug-Report reinschauen oder ist der Crash im "EEBus"-Modul bekannt?

Leider nein, aber der "NIGHTLY"-Hinweis war perfekt, denn mit dem "EEBus"-Modul kann ich den Crash und den nicht stattfindenden Rollback reproduzieren 🙂 "normales" "NIGHTLY"-Image flashen => Reboot ok abwarten bis nach ca. sieben Minuten die Partition als gültig markiert wird "NIGHTLY-EEBus"-Image flashen => Reboot, keine Rückmeldung mehr Ich flashe dann mal schnell wieder das lauffähige Image und ziehe den Debug-Report ab...

Puh, das sind aber viele Fragen 😂 Den Debug-Report habe ich angehängt und bei den platform_packages habe ich (zumindest bewusst) nichts geändert. Sonst ist mir nichts ungewöhnliches aufgefallen und den Crash habe ich mir leider auch nicht in der Console angeschaut. Weiterhin fürchte ich, dass ich die problematischen bin/elf Files schon gelöscht habe. Wie gesagt, macht euch bitte keinen Stress wegen dieses (vielleicht einmaligen) Falls. Ich kann gerne erst versuchen, das Problem zu reproduzieren… EDIT: Ich hatte die Files doch noch nicht gelöscht :) EDIT 2: Zumindest ist das die Firmware, die im Log als "invalid" gekennzeichnet ist. Ich bin mir leider aber nicht sicher, dass das auch tatsächlich der Stand ist, bei dem der Crash aufgetreten ist... warp2-XSS-Debug-Report-2026-01-26T21-01-48-398.txt firmware.zip

‘n Abend @MatzeTF , den Stand habe ich erst nach GitHub gepushed als alles wieder lief, daher investiert bitte keine unnötige Arbeit in die Analyse eines (wahrscheinlich) Einzelfalls, d. h. wenn ihr es mit eurem Setup nicht reproduzieren könnt, dann ist das mein Problem 🙃 Hilft der Debug-Report denn noch weiter, wenn ich die Firmware per USB neu geflashed habe? Ansonsten kann ich morgen gerne mal versuchen, das Verhalten zu reproduzieren…

Ja, die Option ist gesetzt. Aber wenn das Rollback bei euch problemlos funktioniert, dann versuche ich erstmal, das Problem selbst weiter einzukreisen...

Nein, das ist kein Murks, ein Topic "charge_tracker/electricity_price_update" habe ich in meinem Firmware-Clone schon seit einiger Zeit drin 🙃

Moin zusammen, nach fast einem halben Jahr habe ich heute mal wieder meinen Fork auf den aktuellen Stand eures Repositories gebracht und mir (nach Auflösung von gefühlt zwei Dutzend Mergekonflikten) auch direkt einen Crash bzw. eine Boot-Loop eingehandelt 🙈 Eigentlich hatte ich gedacht, dass in einem solchen Fall irgendwann wieder die zuletzt funktionierende Boot-Partition verwendet wird, aber leider hat das nicht funktioniert - weder durch Abwarten (ca. 30 Minuten) noch durch mehrfaches stromlos schalten konnte ich remote auf meine WARP zugreifen. Somit blieb dann nur der Griff zum Schraubendreher... Gibt es da irgendeinen Trick? Im Code habe ich die Commands "firmware_update/reboot_app0", "firmware_update/reboot_app1" und "firmware_update/reboot_other" gefunden, aber dafür muss der Webserver ja erstmal stabil laufen. Besten Dank und Gruß Thomas

Ich habe auch einen ID.4 (MJ 2023) und hatte am meiner "WARP1-on-Steroids" mit selbstgebauter Phasenumschaltung und evcc bislang noch keine Probleme mit der Ladung. Wenn ich den Wagen verbinde und die Ladung nicht innerhalb von ein, zwei Minuten starte, dann leuchtet die Ladekontrollleuchte am Auto ebenfalls rot und ich erhalte eine "Ladung abgebrochen" Push-Benachrichtigung von der VW-App. Nichtsdestotrotz kann ich die Ladung auch Stunden später noch problemlos starten. Unter Ladeort "zu Hause" habe ich allerdings festgelegt, dass der Stecker nach Abschluss der Ladung automatisch entriegelt wird. Damit könnte jemand theoretisch zwar den Stecker im Vorbeigehen ziehen, praktisch ist das aber noch nicht vorgekommen...

Das passt auch ganz gut für meinen ID.4 (Modelljahr 2023) - hier habe ich i. d. R. einen Boost von 360 oder 480 mA, mit dem ich dann auf knapp 11 kW komme. Letztendlich ist das Ganze aber sowieso nur zur Befriedigung des inneren Monk, da 90% der Zeit eh nur einphasig mit 6-8 A beigeladen wird 😂

Besten Dank für die „Inspirationen“, das werde ich mir definitiv mal genauer anschauen 🙂 Letztendlich brauche ich eigentlich auch gar keine transparente Modbus-Bridge, die beliebige Register auslesen kann. Vermutlich würde es auch reichen, wenn ich die benötigten Werte auslese und - so wie die WARP das auch schon macht - in einem eigenen Registersatz zur Verfügung stelle, auf den der SMA Data Manager dann zugreift…

@MatzeTF Welcome back, ich hoffe, du hattest einen schönen Urlaub 😊 Das MQTT-Mirror-Modul wäre tatsächlich eine Möglichkeit, die WARP mit den Zählerdaten zu füttern, allerdings bräuchte ich den Raspberry Pi dann weiterhin, um den zweiten Zähler auszulesen - und eigentlich wollte ich den ja loswerden. Wie nativ kann man das RS485-Interface des WEM denn ansprechen? Ich habe mir mal ein paar Arduino/ESP32-Implementierungen einer Modbus-TCP-Bridge angesehen und soooo kompliziert sieht das eigentlich nicht aus…

Unsere Zoe zeigt auch dieses Verhalten, d. h. sie lädt immer mit etwa 1A weniger als vorgegeben. Deshalb hatte ich vor einiger Zeit eine kleine Anpassung der Firmware vorgenommen und einen dynamischen Boost implementiert. Solange der tatsächlich vom Auto gezogene Strom (Maximum aller Phasen) kleiner als 95% des Sollwerts ist, erhöhe ich diesen um 120 mA. Mit einem PWM, das 17,2A entspricht, lädt die Zoe dann ziemlich zuverlässig mit 16A, was in einer Ladeleistung von 10,8-11kW.resultiert…

Moin, die WARP Smart hat keinen Stromzähler verbaut, daher kannst du leider weder die aktuelle Leistungsaufnahme noch den Stromverbrauch auslesen. Du kannst aber problemlos einen kompatiblen Stromzähler nachrüsten (und sie damit auf eine WARP Pro aufrüsten), das ist hier im Forum gut dokumentiert… Gruß Thomas

Ich hatte mir letztes Jahr auch einen WICAN-Dongle bestellt und etwas damit „rumgespielt“. Allerdings hatte ich das Problem, dass ein Zugriff auf den CAN-Bus bei abgeschlossenen Wagen reproduzierbar die Alarmanlage meines ID.4 ausgelöst hat - und offen wollte ich ihn nicht rumstehen lassen 🙈 Das funktioniert bei einer „normalen“ AC-Wallbox (also auch WARP 1-3) leider nicht, da es keinerlei Kommunikation mit dem Fahrzeug gibt. Lediglich der maximal erlaubte Ladestrom, den das Fahrzeug ziehen darf, wird per PWM vorgegeben. Aber schau mal hier, die nächste Generation der WARP wird zumindest mit Autos, die (auch) über einen CCS-Anschluss verfügen, „sprechen“ können:

Das habe ich tatsächlich schon mal probiert, leider wurde die Modbus-TCP-Bridge damit überlastet. s. hier: Wenn möglich würde ich den Raspberry Pi in der UV durch den WEM 2.0 ersetzen, um beide Modbus-Zähler auszulesen, die Daten im Netzwerk zur Verfügung zu stellen und meine WARP1-on-Steroids fit für §14 zu machen. Seit ein paar Wochen habe ich jetzt nämlich ein SMGW („leider“ noch ohne Steuerbox, keine Ahnung, wann das eingebaut wird), sodass ich theoretisch in Modul 3 wechseln könnte…

Moin zusammen, aktuell lese ich den SDM630 in der UV per Modbus/TCP-Bridge und Node-RED auf einem Raspberry Pi aus und stelle die Daten dann meinem WARP-Charger per API-Zähler zur Verfügung. Darüber hinaus gibt es noch einen zweiten Zähler, der ebenfalls mit am Bus hängt und vom SMA Data Manager per TCP/IP ausgelesen wird. Besteht prinzipiell die Möglichkeit, die RS485-Schnittstelle im WARP Energy Manager 2.0 als Modbus/TCP-Bridge zu verwenden - oder alternativ zumindest den WARP API-Zähler zu füttern? Besten Dank und Gruß Thomas

Genau, einfach mal machen und zum Bohrer greifen - oder freundlich bei Tinkerforge anfragen, ob sie das Loch vor dem Versand ggf. bohren können…

Das Verhalten habe ich auch schon festgestellt, allerdings habe ich mich damit abgefunden, beim Fahrzeugwechsel einfach etwas zu warten. Ich würde aber sagen, dass das Problem eher bei evcc zu suchen ist, da die CP-Trennung definitiv eine direkte MQTT-Nachricht verursacht (s. o.). Fun Fact: Auch die Fahrzeugerkennung, die bei evcc i. d. R. ja über die Cloud des Fahrzeugherstellers geht, lässt sich "aus dem Tritt" bringen. Wenn ich beispielsweise im Büro lade und meine Frau ihr Auto zu Hause verbindet, dann wird der Ladevorgang meistens mir zugeordnet... 🙃

Ich denke, evcc könnte den gewünschten Anwendungsfall abdecken: https://docs.evcc.io/docs/features/battery evcc muss zwar parallel installiert werden (und benötigt auch eine gewisse Einarbeitung), harmoniert aber perfekt mit WARP 1/2/3, wenngleich mittlerweile auch viele Funktionen direkt in WARP verfügbar sind… Gruß Thomas