poohnet

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

Beides wird in der Konfigurationsdatei (evcc.yaml) eingestellt. Die 15s auf oberster Ebene # open evcc at http://evcc.local:7070 network: schema: http host: evcc.local # .local suffix announces the hostname on MDNS port: 7070 log: info levels: cache: error interval: 15s # control cycle interval und der minimale/maximale Ladestrom beim Fahrzeug vehicles: - name: ev1 title: VW ID.4 type: template template: vw user: xxx password: xxx capacity: 77 phases: 3 mode: off mincurrent: 6 maxcurrent: 16 - name: ev2 title: Renault Zoe type: template template: renault user: xxx password: xxx capacity: 50 phases: 3 mode: pv mincurrent: 8 maxCurrent: 16 Gruß Thomas

Das kann ich bestätigen: Ich hatte bereits einen passenden Zähler in der UV und versorge meine WARP1 seit „Anbeginn der Zeitrechnung“ per MQTT mit den Daten. Das funktioniert 1a…

WARP1/2 hat ein 4-poliges Schütz, WARP3 zwei 2-polige inkl. der Hilfskontakte zur (potentialfreien?) Schützüberwachung. @seppl2025 Warum hast du deine WARP3 komplett auseinander genommen? Wolltest du nicht nur den Stromzähler nachrüsten?

Sehr gerne - es freut mich, wenn man hin und wieder auch mal etwas zurückgeben kann. Schließlich werde ich als „Firmware-Hacker“ von euch allen ja schon seit Jahren jederzeit erstklassig unterstützt! … und wenn ich mir die diversen Entwicklungsbranches anschaue, dann freue ich mich schon darauf, bald noch mehr testen zu können 🙃

Vielen Dank für die detaillierte Analyse und Rückmeldung, @MatzeTF. Wieder ein kleines „Krabbeltierchen“ eliminiert… 😂

Ok, das sind definitiv alles valide Argumente, die vermutlich auf fast jedes IoT-Device zutreffen. UniFi hat übrigens einen extra „IoT-Modus“, in dem u. a. das entsprechende WLAN nur im 2.4 GHz-Band ausgestrahlt wird, vielleicht teste ich die diversen Settings auch mal…

Tja, wenn ich das wüsste… Ich bin auf jeden Fall gespannt, was eure Tests ergeben. Sollte sich das Problem nicht reproduzieren lassen, dann hätte ich auch kein Problem damit, den jetzigen Fix nur in meinem Fork vorzunehmen. Nur aus Neugier: Welches ursprüngliche Problem löst(e) das explizite Setzen auf HT20? Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

Im Log steht immer noch HT20, mein UniFi AP hat im 2.4 GHz Band aber auch nur 20 MHz Kanäle aktiv. EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…

@photron hatte mir letztes Jahr zwar ein paar Infos dazu zukommen lassen, ganz trivial war das dann aber doch nicht. Letztendlich hat's jetzt aber funktioniert 🙂 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FBD1BA **** 0,012 | | 332K RAM SYSTEM 296588 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,432 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,585 | api | WARP Charger config version: 2.6.6 (warp) 0,590 | esp32_brick | ESP32 Brick UID: SMH 0,931 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,979 | ntp | Set timezone to Europe/Berlin 1,101 | wifi | Starting scan to select unoccupied channel for soft AP 1,193 | firmware_update | Firmware is signed by: poohnet 1,196 | firmware_update | Partitions: app0 (valid, 2.7.7+67fbc33b), app1 (pending-verify, running, 2.7.7+67fbd1ba)

Klar, kein Problem. "WIFI_BW_HT40" funktioniert, d. h. der Funktionsaufruf an sich ist nicht das Problem. Schiebt man den Funktionsaufruf wieder in "Wifi::setup()", dann funktioniert's auch "WIFI_BW_HT20".

Aber gerne doch 🙃 Ich habe mal ein paar Debug-Prints in "meters_sma_speedwire" eingebaut und anscheinend wird das Problem durch diesen Codeblock in der Methode "Wifi::apply_sta_config_and_connect()" verursacht: // We don't need the additional speed of HT40 and it only causes more errors. esp_err_t err = esp_wifi_set_bandwidth(WIFI_IF_STA, WIFI_BW_HT20); if (err != ESP_OK) { logger.printfln("Setting HT20 for station failed: %s (%i)", esp_err_to_name(err), err); } Mit diesem Code sieht das Eventlog so aus: 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FB7ED6 **** 0,012 | | 333K RAM SYSTEM 297136 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,398 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,516 | api | WARP Charger config version: 2.6.6 (warp) 0,520 | esp32_brick | ESP32 Brick UID: SMH 0,859 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,891 | ntp | Set timezone to Europe/Berlin 0,984 | wifi | Starting scan to select unoccupied channel for soft AP 1,044 | firmware_update | Firmware is not signed 1,048 | firmware_update | Partitions: app0 (pending-verify, running, 2.7.7+67fb7ed6), app1 (new, 2.7.7+67fb7de5) 1,104 | meters_sma_swire | Meter 1: Joined multicast group 239.12.255.254:9522 1,106 | meters | Meter 1: Meter declared 66 (60) values 1,202 | charge_tracker | Found 1 record: first is 1, last is 1 1,223 | charge_tracker | Last charge record size is 0 (0, 0) 1,481 | network | mDNS responder started 1,528 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 1,664 | wifi | Connecting to 'HMW-IoT' 1,668 | device_name | This is warp-SMH (warp-SMH), a WARP Charger Smart w/o EVSE 1,678 | wifi | Selecting channel 1 for soft AP 1,856 | wifi | Soft AP started 1,857 | | SSID: warp-SMH 1,857 | | MAC address: 40:F5:20:5B:38:15 1,868 | | IP address: 10.0.0.1 4,159 | require_meter | Energy meter stuck or unreachable! Blocking charging. 5,498 | wifi | Connected to 'HMW-IoT', ch.6 11bgn HT20 [DE ] -68dBm, BSSID BA:FB:E4:4A:29:E6 6,514 | wifi | Got IP address: 192.168.110.151/24. Own MAC address: 40:F5:20:5B:38:14 6,694 | network | Network connected (WiFi) 7,721 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 7,722 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 2025-04-13 11:08:47,187 | ntp | NTP synchronized at 19,055 2025-04-13 11:09:31,395 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:09:31,396 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:10:11,494 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:10:11,495 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:10:51,093 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:10:51,094 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:11:31,207 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:11:31,208 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:12:11,305 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:12:11,306 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:12:51,418 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:12:51,419 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:13:11,726 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:13:11,727 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 ohne so: 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FB7CB6 **** 0,012 | | 333K RAM SYSTEM 297136 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,397 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,518 | api | WARP Charger config version: 2.6.6 (warp) 0,522 | esp32_brick | ESP32 Brick UID: SMH 0,862 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,894 | ntp | Set timezone to Europe/Berlin 0,989 | wifi | Starting scan to select unoccupied channel for soft AP 1,050 | firmware_update | Firmware is not signed 1,054 | firmware_update | Partitions: app0 (pending-verify, running, 2.7.7+67fb7cb6), app1 (new, 2.7.7+67fb7c14) 1,111 | meters_sma_swire | Meter 1: Joined multicast group 239.12.255.254:9522 1,113 | meters | Meter 1: Meter declared 66 (60) values 1,209 | charge_tracker | Found 1 record: first is 1, last is 1 1,230 | charge_tracker | Last charge record size is 0 (0, 0) 1,481 | network | mDNS responder started 1,528 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 1,661 | wifi | Connecting to 'HMW-IoT' 1,664 | device_name | This is warp-SMH (warp-SMH), a WARP Charger Smart w/o EVSE 1,675 | wifi | Selecting channel 1 for soft AP 1,853 | wifi | Soft AP started 1,854 | | SSID: warp-SMH 1,854 | | MAC address: 40:F5:20:5B:38:15 1,865 | | IP address: 10.0.0.1 4,165 | require_meter | Energy meter stuck or unreachable! Blocking charging. 5,502 | wifi | Connected to 'HMW-IoT', ch.6 11bgn HT20 [DE ] -65dBm, BSSID BA:FB:E4:4A:29:E6 6,517 | wifi | Got IP address: 192.168.110.151/24. Own MAC address: 40:F5:20:5B:38:14 6,700 | network | Network connected (WiFi) 7,719 | meters_sma_swire | Meter 1: Received Speedwire packet 7,720 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 7,731 | meters_sma_swire | Meter 1: Read 608 bytes 7,732 | meters_sma_swire | Meter 1: Power import: 30.200001, Power export: 0.000000 7,745 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 7,746 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 8,744 | meters_sma_swire | Meter 1: Received Speedwire packet 8,744 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 8,755 | meters_sma_swire | Meter 1: Read 608 bytes 8,755 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 11.700000 9,957 | meters_sma_swire | Meter 1: Received Speedwire packet 9,958 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 9,968 | meters_sma_swire | Meter 1: Read 608 bytes 9,969 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 0.400000 10,980 | meters_sma_swire | Meter 1: Received Speedwire packet 10,981 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 10,991 | meters_sma_swire | Meter 1: Read 608 bytes 10,992 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 2.300000 12,003 | meters_sma_swire | Meter 1: Received Speedwire packet 12,004 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 12,014 | meters_sma_swire | Meter 1: Read 608 bytes 12,015 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 4.400000

Das ist der "Übeltäter": > git bisect good 92bf9493e129fb10731fa8e36ef6ee0f694c45a8 is the first bad commit commit 92bf9493e129fb10731fa8e36ef6ee0f694c45a8 Author: Mattias Schäffersmann <…> Date: Mon Mar 31 20:35:55 2025 +0200 wifi: Fix AP bandwidth and missing BSSID in state - Now that the AP isn't started during the setup when fallback mode is enabled, the bandwidth must be set right before opening the AP. - The AP's BSSID cannot be retrieved during setup for the same reason. - Set the bandwidth for STA right before connecting as well. Issues introduced in 6b8a6ca. software/src/modules/wifi/wifi.cpp | 45 ++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 19 deletions(-) Mache ich ein revert auf diesen Commit, dann bekomme ich wieder Werte - sowohl in der WARP1-Konfiguration als auch mit meinem Fork: Vielleicht wichtig: Meine WARP ist per WLAN verbunden (im gleichen VLAN wie die SMA-Komponenten). Testet ihr evtl. nur noch per LAN?

Genau da bin ich gerade dran - die originale WARP1-Konfiguration ohne meine Anpassungen 🙃