poohnet

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 🙃

Kurzer Zwischenstand: Das Problem scheint nichts mit den letzten Commits im Modul "meters_sma_speedwire" zu tun zu haben, denn mit bdb94657f bekomme ich noch Werte, mit upstream/master nicht mehr. Sehr mysteriös...

Nach der Übernahme in euren master und dem ersten Refactoring hat das Modul auf jeden Fall noch korrekt funktioniert, ich kann jetzt aber leider nicht mit Gewissheit sagen, ab wann es kaputt gegangen ist. Wenn ihr das Problem aber nicht nachvollziehen könnt, dann kann ich gerne mal ein „bisect“ probieren und den Commit identifizieren. Ja, definitiv. Es gibt noch einen zweiten Zähler, der weiterhin per Node-RED ausgelesen wird - und dann ist da noch der SMA Data Manager, der ebenfalls beide Zähler per Modbus-TCP abfragt (wobei der WARP-Zähler ggf. ja auch nicht direkt sondern über WARP ausgelesen werden könnte). Blöde Frage, liest das Template alle Werte einzeln oder blockweise? In Node-RED habe ich nämlich immer 20 Register auf einmal gelesen, in einen Puffer geschrieben und die Leistungswerte sekündlich, den Rest alle zehn Sekunden an den API-Zähler geschickt. Schon passiert 😂 Das steht noch auf meiner TODO-Liste.

Hallo zusammen, nach knapp fünf Monaten habe ich meinem "WARP-on-Steroids" nun nochmal einen aktuelle Firmwarestand verpasst und die gute Nachricht ist, dass beide Autos weiterhin richtig laden und auch meine Anpassungen noch funktionieren. 🙂 Ein paar kleinere Probleme sind mir allerdings aufgefallen: Mein SMA Sunny Home Manager 2.0 liefert nun keine Werte mehr, im Debug-Trace stehen unter "__begin_meters_swire__" aber zumindest die Abfragen drin; hier habe ich die Vermutung, dass dies mit den jüngsten Anpassungen im Modul "meters_sma_speedwire" zu tun hat, denn mit meinem ursprünglichen Modul auf einem zweiten ESP32-Brick erhalte ich alle Werte. Weiterhin gibt es ja jetzt ein Template für den SDM630 TCP und erfreut habe ich festgestellt, dass dies mit meinem (von einer auf einem Raspberry Pi laufenden Modbus-TCP/IP-Bridge angebundenen) SM630v2 funktioniert. Allerdings scheint das Abfrageintervall etwas zu groß zu sein, denn der Leistungsgraph wird gestrichelt gezeichnet. Bislang habe ich die Daten per Node-RED ausgelesen, gepuffert und sekündlich über die API bereitgestellt, da wurde der Graph durchgängig gezeichnet. Last but not least: Gibt es einen Grund dafür, dass man beim Solar Forecast mit einer unsignierten Firmware nur eure Demodaten bekommt? #if !BUILD_IS_SIGNED() #define SOLAR_FORECAST_USE_TEST_DATA #endif Wie immer besten Dank und viele Grüße Thomas warp2-XSS-Debug-Report-2025-04-12T14-07-43-914.txt

n‘ Abend @MatzeTF, funktioniert das auch für eine selbstgebaute Firmware und - falls ja - welche Version wird wiederhergestellt? Die alte, ebenfalls selbstgebaute? In der Vergangenheit musste ich mich nämlich das ein oder andere Mal mit dem Laptop zur Wallbox begeben… 😂

n‘ Abend @MatzeTF, falls es euch hilft, könnt ihr euch gerne nochmal an meinem Fork bedienen - den Strompreis per MQTT zu setzen und jede Ladung mit dem zu Beginn gültigen Preis zu speichern, habe ich vor einiger Zeit mal implementiert 🙃 Gruß Thomas

Ja, das tue ich. Auch wenn ich mich in den letzten Monaten hier im Forum etwas rar gemacht habe, halte ich meinen Fork eigentlich immer relativ aktuell - und meine WARP1 on Steroids funktioniert immer noch 1a 🙂 Also gerne einfach melden, falls Bedarf an einer angepassten Firmware besteht… Gruß Thomas

Schau dir mal das WiCAN-Modul an, das könntest du in deine Automatisierung einbauen. Ich habe mal etwas damit rumgespielt (und wollte eigentlich auch ein Modul für die WARP implementieren), der Nachteil ist aber, dass bei meinem ID.4 die Alarmanlage losgeht, wenn der Wagen ein paar Minuten abgeschlossen ist und auf den CAN-Bus zugegriffen wird. 🚨 SOC-Abfrage an sich (und noch vieles mehr) ist damit aber problemlos möglich… https://www.meatpi.com/products/wican Gruß Thomas

Ausschließen kann ich das sicherlich nicht, aber meine Anpassungen sind eigentlich seit dem Frühjahr unverändert und das Problem tritt erst seit ein paar Wochen auf, d. h. nachdem ich meine Forks rebased habe. Ich werde die Anpassung in der EVSE-Firmware testweise mal reverten und schauen, ob das Problem dann evtl. weg ist. Andere Frage: Ist es richtig, dass beim EVSE 2.0-Bricklet keine fahrzeugspezifische Kalibrierung mehr erforderlich ist? Falls ja, wo sind diesbezüglich die Unterschiede zum ursprünglichen EVSE-Bricklet? Gruß Thomas

Moin @MatzeTF, sorry, ich hatte irgendwie übersehen, dass du schon längst geantwortet hast 🙈 Anbei die beiden Ladeprotokolle von letztem Sonntag... Protokoll 1 1415 Uhr: Auto verbunden 1425 Uhr: Ladung über EVCC gestartet (und Umschaltung auf 3-phasiges Laden) 1432 Uhr: Ladung über das Auto beendet und Stecker gezogen --> Status wechselt von 3 auf 2 und bleibt im Webinterface "Verbunden" 1433 Uhr: Auto wieder verbunden --> Ladung wird direkt wieder gestartet, Status wechselt von 2 auf 3 Protokoll 2 1500 Uhr: Ladung über EVCC beendet --> Status wechselt von 3 auf 1 1500 Uhr: Stecker gezogen --> Status wechselt von 1 auf 0 Gruß Thomas warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T14-33-24-005.txt warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T15-01-02-184.txt