poohnet Geschrieben May 2, 2022 at 06:21 Geschrieben May 2, 2022 at 06:21 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: 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 Zitieren
rtrbt Geschrieben May 2, 2022 at 06:55 Geschrieben May 2, 2022 at 06:55 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 Zitieren
poohnet Geschrieben May 2, 2022 at 07:53 Autor Geschrieben May 2, 2022 at 07:53 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 Zitieren
rtrbt Geschrieben May 2, 2022 at 08:19 Geschrieben May 2, 2022 at 08:19 Bevor du gleich über die halb-fertigen Forms im Webinterface stolperst: Es kommen gleich noch ein paar Commits ;) Zitieren
poohnet Geschrieben May 3, 2022 at 11:05 Autor Geschrieben May 3, 2022 at 11:05 Hi Erik, leider ist das Problem nach etwas mehr als 24 Stunden nun wieder aufgetreten 🙁 So sah das Webinterface bis heute Vormittag noch aus: 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: 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 Zitieren
rtrbt Geschrieben May 3, 2022 at 11:45 Geschrieben May 3, 2022 at 11:45 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. 1 Zitieren
poohnet Geschrieben May 3, 2022 at 12:21 Autor Geschrieben May 3, 2022 at 12:21 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 Zitieren
poohnet Geschrieben May 4, 2022 at 08:48 Autor Geschrieben May 4, 2022 at 08:48 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 Zitieren
poohnet Geschrieben May 4, 2022 at 09:21 Autor Geschrieben May 4, 2022 at 09:21 Hier noch ein (vielleicht hilfreicher) Hinweis: Auch wenn das Webinterface an sich nicht mehr (richtig) reagiert, die Zählergrafik funktioniert weiterhin: Zitieren
rtrbt Geschrieben May 4, 2022 at 09:31 Geschrieben May 4, 2022 at 09:31 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. Zitieren
poohnet Geschrieben May 4, 2022 at 09:35 Autor Geschrieben May 4, 2022 at 09:35 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 Zitieren
poohnet Geschrieben May 4, 2022 at 09:48 Autor Geschrieben May 4, 2022 at 09:48 So, die Commits sind nachgezogen und die neue Firmware ist drauf. Mal schau'n, was nun passiert 🙃 Zitieren
poohnet Geschrieben May 6, 2022 at 05:21 Autor Geschrieben May 6, 2022 at 05:21 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 Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.