Jump to content

Webinterface kaputt durch "meter/all_values_update"?


poohnet
 Share

Recommended Posts

Moin Erik,

nachdem ich die neue Firmware ja nun seit ein paar Tagen "richtig" auf meiner WARP1 nutze und die Zählerdaten alle 10 Sekunden per NodeRED bereitstelle, ist mir ein seltsamer Bug aufgefallen. "meter/values_update" und "meter/phases_update" funktionieren problemlos, sobald ich aber auch "meter/all_values_update" sende, dann geht das Webinterface (leider erst nach ein paar Stunden) kaputt und es erscheint der gelbe "Verbindung zur Wallbox verloren!"-Balken:

image.thumb.png.af87fb551441e38869f9fbd9052cecc9.png

Das Fahrzeug lädt weiter, die aktuellen Daten werden sauber per MQTT bereitgestellt und die Box reagiert auch weiterhin auf die externe Steuerung durch EVCC. Nur das Webinterface ist komplett kaputt und lässt sich nur durch einen Reboot des ESP32-Bricks wiederbeleben.

Hast du vielleicht eine Idee, woran das liegen könnte bzw. wie wir den Bug eingrenzen können?

Besten Dank & Gruß Thomas

Link to comment
Share on other sites

Moin Thomas,

31 minutes ago, poohnet said:

Hast du vielleicht eine Idee, woran das liegen könnte bzw. wie wir den Bug eingrenzen können?

Geh mal mindestens auf diesen Commit https://github.com/Tinkerforge/esp32-firmware/commit/8839c4f65a1b78e17ccfe419c5eca638ea074df5.

Ich habe in den letzten Wochen recht viel an den WebSockets gearbeitet, du bist da auf einem Zwischenstand, bei dem es noch einen Bug in der Verbindungsbehandlung gab. Wie üblich: Falls es dann immer noch kaputt ist, bitte nochmal Bescheid sagen ;)

Grüße,
Erik

Link to comment
Share on other sites

Hi Erik,

vielen Dank für die schnelle Antwort. Ich dachte eigentlich, ich hätte gegen den letzten Stand von Freitagnachmittag gebaut, aber der Commit fehlte mir tatsächlich noch. Ich teste weiter... 🙃

Gruß Thomas

Link to comment
Share on other sites

Hi Erik,

leider ist das Problem nach etwas mehr als 24 Stunden nun wieder aufgetreten 🙁

So sah das Webinterface bis heute Vormittag noch aus:

image.thumb.png.3373456f7e2b236ac575f674739342b0.png

Jetzt ist wieder alles weg und auch wenn man die einzelnen Module direkt in der URL angibt (z. B. /#meter, /#evse etc.), dann sieht man nur das leere Framework:

image.thumb.png.393a2773b5c118a04e8cf18cdec776ad.png

Im Eventlog ist war bislang eigentlich (fast) nichts auffälliges erkennbar - außer vielleicht die "httpd_ws_recv_frame failed" Fehler:

                  0,035      **** TINKERFORGE WARP CHARGER V2.0.1-626f869d ****
                  0,036           320K RAM SYSTEM   271776 HEAP BYTES FREE
                  0,046  READY.
                  0,098  Mounted data partition. 53248 of 3538944 bytes (1.5 %) used
                  0,187  WARP Charger config version: 2.0.0
                  0,188  ESP32 Brick UID: SMH
                  0,539  Set timezone to Europe/Berlin
                  0,805  No NFC Bricklet found. Disabling NFC support.
                  0,826  Found 1 records. First is 1, last is 1
                  0,849  Last charge record size is 112 (112, 0)
                  1,047  mDNS responder started
                  1,083  MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?
                  1,106  Had to configure soft AP IP address 1 times.
                  1,106  Wifi soft AP started
                  1,107      SSID: warp-SMH
                  1,434      MAC address: 40:F5:20:5B:38:15
                  1,435      IP address: 10.0.0.1
                  1,448  Wifi connecting to HMW-IoT
                  1,462  This is warp-SMH (warp-SMH), a WARP Charger Smart 11kW 
                  4,259  Wifi connected to HMW-IoT
                  4,333  Wifi MAC address: 40:F5:20:5B:38:14
                  4,335  Wifi got IP address: 192.168.110.150. Connected to BSSID E4:5F:01:04:D4:08
                  4,346  Network connected. Stopping soft AP
                  4,392  MQTT: Connected to broker.
                  4,626  MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?
2022-05-02 10:34:47,004  NTP synchronized at 18,000!
2022-05-02 10:35:30,467  This is warp-SMH (warp-SMH), a WARP Charger Pro 11kW 
2022-05-02 10:48:51,773  httpd_ws_recv_frame failed with -1
2022-05-02 10:52:07,789  httpd_ws_recv_frame failed to get frame len with 259
2022-05-02 11:25:26,664  httpd_ws_recv_frame failed to get frame len with 259
2022-05-02 14:47:26,432  httpd_ws_recv_frame failed with -1
2022-05-02 14:59:53,592  httpd_ws_recv_frame failed to get frame len with 259
2022-05-02 15:31:38,721  Charger state changed from 0 to 1
2022-05-02 15:31:42,722  Charger state changed from 1 to 2
2022-05-02 15:31:42,764  Tracked start of charge.
2022-05-02 15:31:43,768  Charger state changed from 2 to 3
2022-05-02 16:01:13,910  Charger state changed from 3 to 2
2022-05-02 16:01:15,924  Charger state changed from 2 to 0
2022-05-02 16:01:15,966  Tracked end of charge.
2022-05-02 16:35:27,065  Charger state changed from 0 to 1
2022-05-02 16:36:12,109  Charger state changed from 1 to 2
2022-05-02 16:36:12,156  Tracked start of charge.
2022-05-02 16:36:13,160  Charger state changed from 2 to 3
2022-05-02 17:04:46,414  Charger state changed from 3 to 2
2022-05-02 17:04:48,434  Charger state changed from 2 to 0
2022-05-02 17:04:48,488  Tracked end of charge.
2022-05-03 08:26:53,531  httpd_ws_recv_frame failed to get frame len with 259

 

Kann das etwas damit zu tun haben, dass ich in meinem Build ein paar Änderungen in den Modulen vorgenommen habe?

  • Das Modul "Modbus Reader" habe ich rausgenommen, da eh nicht verbaut.
  • MQTT habe ich unter "Netzwerk" einsortiert.
  • Anstelle des "Hidden Proxy" verwende ich den "Proxy", sodass ich die Bricklets sehe.

Sofern das hilft kann ich gerne auch erstmal mit dem "Originalcode" aus eurem Repository weitertesten...

Besten Dank & Gruß Thomas

Link to comment
Share on other sites

Ah ich glaube ich sehe das Problem: Du kompilierst noch gegen arduino-esp mit dem Stand von WARP 2.0.0: https://github.com/poohnet/esp32-firmware/blob/9c79722309dc1e29b3142aacdb87cfb2159bbce6/software/poohnet_warp.ini#L4 Wenn du da auf file://packages/arduino-esp32-warp-2.0.2 wechselst und die update_packages.py aus unserem Repo nachziehst, sollte es wieder funktionieren.

Das Problem ist, dass in arduino-esp32 eine vorkompilierte Variante des esp-idf eingebettet ist. Ich habe für die Wallbox-Firmware einen Fork angelegt, damit ich eigene Versionen vom esp-idf einbetten kann, da wir ein paar Patches fahren müssen (die liegen hier: https://github.com/Tinkerforge/esp32-firmware/tree/master/software/patches)

Nach dem 2.0.0 Release ist ein Patch dazugekommen, der sicherstellt, dass der Web-Server vom ESP-IDF meinen Code benachrichtigt wenn ein WebSocket-Close-Frame empfangen wird. Wenn der Patch fehlt, dann funktioniert die Keep-Alive-Logik nicht sauber und die Verbindungen funktionieren irgendwann nicht mehr.

 

Ich setze hier trotzdem mal einen Langzeittest auf, nicht dass es unabhängig davon noch einen Bug mit dem MQTT-Stromzähler gibt.

  • Thanks 1
Link to comment
Share on other sites

Danke Erik, wieder was gelernt 😇

Ich habe jetzt alle Anpassungen aus eurem Repository nachgezogen und werde die neue Firmware heute Abend bauen und installieren...

Gruß Thomas

Link to comment
Share on other sites

Moin Erik,

tja, das hat leider auch nicht geholfen, das Webinterface ist eben schon wieder kaputt gegangen 🙁

Hat das Problem evtl. etwas mit der Fehlermeldung "httpd_ws_recv_frame failed to get frame len with -1" zu tun? Ich bin mir nicht ganz sicher, aber es scheint, dass die auftritt, wenn ich das Webinterface per iPhone oder iPad öffne.

Kann ich noch irgendwas testen, bevor ich ein "reboot" per MQTT sende?

Vielen Dank & Gruß Thomas

Link to comment
Share on other sites

Falls du Commit a6ca582a hast: Ruf mal http://123.123.123.123/info/ws auf und ziehe dann über http://123.123.123.123/event_log das Log runter (IP ersetzen nicht vergessen ;) )

Ich würde erwarten, dass du am Ende Ausgabe mit worker_active yes und queue_len > 0 bekommst. Falls ja, dann hast du die Race Condition getroffen, die ich auch gerade gefunden habe. Fix ist hier https://github.com/Tinkerforge/esp32-firmware/commit/7b28f480 Firmware 2.0.4 kommt gleich.

Link to comment
Share on other sites

Bingo! Das sind die letzten Einträge im Log:

2022-05-04 11:32:43,032  keep_alive_fds   55 -1 -1 -1 -1
2022-05-04 11:32:43,033  keep_alive_pongs 72310851 0 0 0 0
2022-05-04 11:32:43,033  queue_len 20
2022-05-04 11:32:43,044  worker_active yes

 

Link to comment
Share on other sites

Moin Erik,

man soll den Tag zwar nicht vor dem Abend loben, aber das Webinterface läuft nun schon seit fast zwei Tagen stabil 🙂

Vielen Dank für die (wie immer) tolle Unterstützung hier, viele Grüße und ein schönes Wochenende
Thomas

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...