poohnet

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