WARP-on-Steroids: kleinere Probleme mit aktuellem Firmwarestand

poohnet · April 12, 2025 at 12:41

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

MatzeTF · April 12, 2025 at 16:37

Quote

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.

Hm, interessant. Der SHM 2.0, den wir haben, lässt sich problemlos auslesen. Sehen wir uns an.

Meinst du mit deinem „ursprünglichen Modul“ eigentlich deine Variante vor dem Merge in unseren Code oder die die direkt nach dem Merge von uns umgeschriebene Variante?

Quote

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.

Die Wallbox braucht mindestens alle zwei Sekunden neue Daten. Ab 2,5 Sekunden wird der Graph unterbrochen gezeichnet. Wenn ich mir das Log ansehe, dauert es ca. 4 Sekunden, um alle 72 Werte auszulesen. Auf Seiten der Wallbox ist keine Verzögerung drin, also kann ich mir nur vorstellen, dass die Modbus-Bridge die Daten zu langsam liefert. Teilweise werden nur sieben Werte innerhalb einer Sekunde ausgelesen. Kann es sein, dass noch ein anderer Prozess über die Bridge Daten aus dem Zähler liest und die Daten nicht gecacht werden?

Quote

Last but not least: Gibt es einen Grund dafür, dass man beim Solar Forecast mit einer unsignierten Firmware nur eure Demodaten bekommt?

Ja, gibt es. Wir benutzen die kostenlose Variante vom Vorhersageserver, die nur 12 Abfragen pro Stunde erlaubt. Das Firmennetz hängt auf einer öffentlichen IP, sodass wenn wir alle gegen den richtigen Server testen würden, in kürzester Zeit das Limit überschritten wäre. Da wir zum Testen immer unsignierte Firmwares bauen, haben wir die Testdaten damit gekoppelt.

Um deine implizite Frage zu beantworten: Du kannst das gerne auskommentieren und richtige Daten verwenden. Wenn du zu häufig, bzw. zu schnell, neustartest, wirst du aber das Limit treffen.

Alternativ erstellst du dir ein eigenes Zertifikat und baust auch signierte Firmwares.

poohnet · April 12, 2025 at 17:23

On 4/12/2025 at 6:37 PM, MatzeTF said:

Meinst du mit deinem „ursprünglichen Modul“ eigentlich deine Variante vor dem Merge in unseren Code oder die die direkt nach dem Merge von uns umgeschriebene Variante?

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.

On 4/12/2025 at 6:37 PM, MatzeTF said:

Kann es sein, dass noch ein anderer Prozess über die Bridge Daten aus dem Zähler liest und die Daten nicht gecacht werden?

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.

On 4/12/2025 at 6:37 PM, MatzeTF said:

Um deine implizite Frage zu beantworten: Du kannst das gerne auskommentieren und richtige Daten verwenden.

Schon passiert 😂

On 4/12/2025 at 6:37 PM, MatzeTF said:

Alternativ erstellst du dir ein eigenes Zertifikat und baust auch signierte Firmwares.

Das steht noch auf meiner TODO-Liste.

poohnet · April 12, 2025 at 18:17

On 4/12/2025 at 7:23 PM, poohnet said:

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.

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...

bearbeitet April 12, 2025 at 18:19 von poohnet

MatzeTF · April 12, 2025 at 18:48

Quote

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.

Ich glaube, die Werte werden einzeln gelesen. Bei float32 also immer zwei Register auf einmal.

Quote

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...

Wäre super, wenn du das herausfinden könntest. Hast du zufällig einen ESP32, den du mit einer unserer Release-Firmwares flashes könntest? Da sowohl Release als auch Master mit dem SHM 2.0 bei uns funktionieren, würde mich interessieren, ob das Problem eher bei deinem Fork oder einer Inkompatibilität mit deinem SHM 2.0 zu suchen ist. Meinst du mit „upstream/master“ eigentlich, dass du unseren Master-Stand ohne eigene Änderungen gebaut hast?

poohnet · April 12, 2025 at 18:51

On 4/12/2025 at 8:48 PM, MatzeTF said:

Hast du zufällig einen ESP32, den du mit einer unserer Release-Firmwares flashes könntest? Da sowohl Release als auch Master mit dem SHM 2.0 bei uns funktionieren, würde mich interessieren, ob das Problem eher bei deinem Fork oder einer Inkompatibilität mit deinem SHM 2.0 zu suchen ist.

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

poohnet · April 12, 2025 at 19:27

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?

MatzeTF · April 12, 2025 at 22:08

Das ist … unerwartet.

Wenn ich das richtig sehe, wurden da nur Dinge verschoben und die TX-Power von 21 dBm angefragt, was allerdings keinen Unterschied machen sollte, da sie in der DE-Zone eh auf 19,5 dBm begrenzt wird.

Bist du zufällig motiviert, rauszufinden, welcher Teil von dem Commit das Problem verursacht?

Edit: Wo ich so drüber nachdenke, haben wir ja die Reihenfolge, in der bei WiFi AP und Station gestartet werden, geändert. Ich frage mich, ob das nun dazu führt, dass die IGMP-Join-Nachricht für die Multicast-Nachrichten vom SHM 2.0 auf dem AP-Interface rausgeht, bevor das Station-Interface existiert. 🤔

poohnet · April 13, 2025 at 09:16

On 4/13/2025 at 12:08 AM, MatzeTF said:

Bist du zufällig motiviert, rauszufinden, welcher Teil von dem Commit das Problem verursacht?

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

MatzeTF · April 13, 2025 at 12:31

Die Umstellung von HT40 auf HT20 für die WiFi Station haben wir doch schon seit über einem Jahr drin, nur war sie vorher an anderer Stelle. Warum führt das jetzt dazu, dass Multicast-Packete abgeschnitten werden, obwohl alles andere noch funktioniert? Insbesondere, wenn die Verbindung in beiden Fällen angeblich mit HT20 hergestellt wird, selbst wenn HT40 nicht deaktiviert wurde.

Meine Abneigung gegenüber WLAN bestätigt sich mal wieder. 🤢

Vielen Dank für deine umfangreiche Fehlersuche. Ich werde kommende Woche mal versuchen, das bei uns mit WLAN zu reproduzieren. Bisher haben wir unseren SHM 2.0 nämlich immer per LAN ausgelesen.

Wenn du noch weiter motiviert bist, kannst du mal versuchen, den Code reinzunehmen, und im Aufruf von esp_wifi_set_bandwidth das WIFI_BW_HT20 durch WIFI_BW_HT40 zu ersetzen. Mich interessiert, ob der Funktionsaufruf an der Stelle das Problem ist, oder die gewünschte Einstellung.

poohnet · April 13, 2025 at 14:04

On 4/13/2025 at 2:31 PM, MatzeTF said:

Wenn du noch weiter motiviert bist, kannst du mal versuchen, den Code reinzunehmen, und im Aufruf von esp_wifi_set_bandwidth das WIFI_BW_HT20 durch WIFI_BW_HT40 zu ersetzen. Mich interessiert, ob der Funktionsaufruf an der Stelle das Problem ist, oder die gewünschte Einstellung.

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".

poohnet · April 13, 2025 at 15:09

On 4/12/2025 at 6:37 PM, MatzeTF said:

Alternativ erstellst du dir ein eigenes Zertifikat und baust auch signierte Firmwares.

@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)

MatzeTF · April 13, 2025 at 15:27

On 4/13/2025 at 4:04 PM, poohnet said:

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".

Wird ja immer seltsamer…

Wenn du den Aufruf mit HT40 drin hast, was steht dann im Ereignis-Log, wenn das WLAN verbunden ist? HT40 oder immer noch HT20? Weißt du zufällig, was von beidem dein AP aktiviert hat?

poohnet · April 13, 2025 at 16:07

On 4/13/2025 at 5:27 PM, MatzeTF said:

Wenn du den Aufruf mit HT40 drin hast, was steht dann im Ereignis-Log, wenn das WLAN verbunden ist? HT40 oder immer noch HT20? Weißt du zufällig, was von beidem dein AP aktiviert hat?

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“…

bearbeitet April 13, 2025 at 17:05 von poohnet

MatzeTF · April 13, 2025 at 18:26

On 4/13/2025 at 6:07 PM, poohnet said:

Im Log steht immer noch HT20, mein UniFi AP hat im 2.4 GHz Band aber auch nur 20 MHz Kanäle aktiv.

Erstens: Gute Wahl.

Zweitens: Warum funktioniert es dann nicht richtig, wenn man HT20 auf dem ESP auswählt?

Quote

EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…

Ich weiß, dass ich mich wiederhole, wenn ich erwähne, dass ich eine Abneigung gegen WLAN habe…

poohnet · April 13, 2025 at 18:59

On 4/13/2025 at 8:26 PM, MatzeTF said:

Zweitens: Warum funktioniert es dann nicht richtig, wenn man HT20 auf dem ESP auswählt?

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?

On 4/13/2025 at 8:26 PM, MatzeTF said:

Ich weiß, dass ich mich wiederhole, wenn ich erwähne, dass ich eine Abneigung gegen WLAN habe…

Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

MatzeTF · April 13, 2025 at 19:46

On 4/13/2025 at 8:59 PM, poohnet said:

Nur aus Neugier: Welches ursprüngliche Problem löst(e) das explizite Setzen auf HT20?

HT20 hat einen besseren Störabstand als HT40. Heißt, bei gleicher Entfernung zum AP ist die Signalqualität besser. HT40 hat außerdem den Nachteil, dass es doppelt so viel Überlappung mit anderen WLANs in der Umgebung hat und somit die Wahrscheinlichkeit für eine Kollision höher ist. Bei viel Traffic in der Umgebung müssen also deutlich häufig Pakete neu gesendet werden. Dem gegenüber steht als einziger Vorteil, dass die Übertragungsrate theoretisch fast doppelt so hoch ist. Da der ESP nicht mal HT20 voll auslasten kann, ist das in diesem Fall aber kein Vorteil. Somit hat HT40 bei der Wallbox nur Nachteile. Dementsprechend habe ich auf HT20 umgestellt, um die bessere Signalqualität nutzen zu können. Letzteres hilft all denen, deren Wallbox schlechten Empfang hat.

Quote

Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

Für mobile Geräte ist WLAN ok, aber Wallboxen sind üblicherweise nicht so mobil.

poohnet · April 13, 2025 at 20:14

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…

MatzeTF · April 14, 2025 at 20:27

Okay, über WLAN kann ich das Problem bei uns auch reproduzieren.

Dass das Zählermodul der Multicastgruppe beitritt, bevor die WLAN-Verbindung steht, ist prinzipiell kein Problem. Im funktionierenden Fall werden die entsprechenden IGMP-Pakete sofort nach Aufbau der Verbindung rausgesendet, auch wenn der entsprechende Aufruf im Zählermodul schon ein paar Sekunden her ist, da sich irgendwas unten drunter anscheinend merkt, welchen Multicastgruppen man beitreten möchte.

Das seltsame ist, dass wenn esp_wifi_set_bandwidth nach dem Multicast-Join ausgeführt wird, anscheinend alle Multicast-Mitgliedschaften vergessen werden und nach anschließendem WLAN-Verbindungsaufbau keine IGMP-Pakete rausgeschickt werden. Der aktuelle Master-Stand lässt sich reparieren, indem entweder der Aufruf von esp_wifi_set_bandwidth wieder in die setup-Funktion verschoben wird, wodurch er vor dem Multicast-Join ausgeführt wird, oder der Aufruf bleibt wo er ist und der Multicast-Join wird per Task Scheduler so lange verzögert, dass er wieder hinter dem esp_wifi_set_bandwidth-Aufruf ausgeführt wird.

Da ich keine Lust habe, in dem Closed Source WiFi-Blob rumzustochern, werde ich den esp_wifi_set_bandwidth-Aufruf wieder in die setup-Funktion schieben und mit einem entsprechenden Kommentar versehen, damit ihn nicht nochmal jemand verschiebt.

Die 58 Byte langen Pakete, die immer durchkommen, sind übrigens Broadcasts vom SHM. Als Broadcasts kommen sie auch ohne Multicast-Join an und aus irgendeinem Grund empfängt der Multicast-Port auch die Broadcasts. Das war schon immer so, ist nur niemandem aufgefallen.

poohnet · April 15, 2025 at 04:29

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

MatzeTF · April 15, 2025 at 12:52

On 4/13/2025 at 6:07 PM, poohnet said:

EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…

Das kann ich bei uns weder mit WARP1, noch WARP2 oder WARP3 reproduzieren. Ich baue jetzt aber noch zusätzlich ein, dass zwischen AP aktivieren und HT20 setzen auf das Interface gewartet wird. Vielleicht hilft das.

On 4/15/2025 at 6:29 AM, poohnet said:

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

Vielen Dank vor allem an dich für deinen Einsatz zum Testen, Bug melden und dann auch noch aufwändig das Problem einkreisen. Du machst das hier ja schließlich alles freiwillig! 👍

poohnet · April 15, 2025 at 16:28

On 4/15/2025 at 2:52 PM, MatzeTF said:

Vielen Dank vor allem an dich für deinen Einsatz zum Testen, Bug melden und dann auch noch aufwändig das Problem einkreisen. Du machst das hier ja schließlich alles freiwillig! 👍

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 🙃

Anmelden

WARP-on-Steroids: kleinere Probleme mit aktuellem Firmwarestand

Recommended Posts

poohnet

MatzeTF

poohnet

poohnet

MatzeTF

poohnet

poohnet

MatzeTF

poohnet

MatzeTF

poohnet

poohnet

MatzeTF

poohnet

MatzeTF

poohnet

MatzeTF

poohnet

MatzeTF

poohnet

MatzeTF

poohnet

Join the conversation

Umsehen

Aktivitäten