ESP IDF prerušovanie Wi-Fi pripojenia

[fortran1986]

Ahojte, neviem či mi tu bude vedieť niekto poradiť s mojim problémom, keďže je to dosť špecifickú vec... ale skúsim aj tu. Vyvýjal som aplikáciu pre ESP32, aplikácia obsahuje tento HTTP server https://github.com/fhessel/esp32_https_server (ktorý bol omnoho stabilneší ako bežne používaný AsyncWebServer) pôvodne som ju vyvýjal pod najrozšírenejším veľmi starým toolchainom obsahujúcom GCC 5.2 s chabou podporou C++ 17 a https://github.com/espressif/arduino-esp32 frameworkom (ale staršou verziou). Prekopal som to celé pod ESP IDF a s toolchainom obsahujúcim GCC 8.4 (s čiastočnou podporou C++ 20). arduino-esp32 je v novej verzii 4.x a pridal som ho do projektu ako IDF komponentu. Teraz je to viac customizovateľné a veľa vecí si viem nakonfigurovať cez idf.py menu konečne mám k dispozícii aj RTTI, ktoré som veľmi postrádal. Problém je, že čím viac možností konfigurácie mám, tým môže nastať viac problémov pri nesprávnej / neúplnej konfigurácii. Spustil som appku a funguje, ale pri refreshi stránky sa vždy preruší pripojenie (predtým pod starým toolchainom sa bežne neprerušovalo). Kým stránku nerefreshnem všetko ide ako má, websockety aj http requesty / resposny pracujú ako majú a spojenie je úplne stabilné. No pri refreshi to v konzole to vyzerá takto:

Kód: [Vybrat]

[HTTPS:E] An receive error occured, FID=57
[HTTPS:I] Connection closed. Socket FID=57
[HTTPS:I] Client closed connection, FID=60
[HTTPS:E] An receive error occured, FID=60
[HTTPS:I] Connection closed. Socket FID=60
[ 17058][I][WebsocketHandler.cpp:27] dumpFrame(): Fin: 1, OpCode: 8 (CLOSE), Mask: 1, Len: 2
[HTTPS:I] WS payload: length=2
[HTTPS:I] WS lost client, calling onClose, FID=-1
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40127b41  PS      : 0x00060b30  A0      : 0x80123f70  A1      : 0x3ffd7ff0
Vďaka prerušenému spojeniu sa žiaľ resetne celé zariadenie čo je neprípustné. Vygooglil som si túto diskusiu: https://github.com/fhessel/esp32_https_server/issues/85 vraj je problém v zlom Wifi pripojení.

1. Teraz neviem, či je to tým, že sa WiFi signál skutočne zhoršil (trošku som medzitým prestavoval pracovňu (kôli akvárku) a WiFi router som musel premiestniť na takú kovovú skrinku - a neviem či to nepohlcuje rádiové vlny)...

2. Alebo je problém v tom, že som ešte niečo cez to idf.py menu nenakonfiguroval úplne dobre. Sú tam stovky rôznych volieb... Každopádne viem, ktorý riadok v kóde to spôsobuje, otázka je či na to má vplyv konfigurácia WiFi pripojenia niekde v idf menu, alebo musím použiť to krkolomné riešenie, ktoré som si vygooglil https://github.com/fhessel/esp32_https_server/issues/85#issuecomment-724652455 ?

Aké voľby treba použiť v konfigurácii idf menu, možno sú niekde nejaké timeouty alebo čo ja viem čo? Aké voľby používate vy pri konfigurácii esp idf? Vďaka.

[Reklama]

[mhi]

A kdyz vezmete nejaky bezny example z esp-idf, bezi to jak ma?

Popravde receno nechapu duvod proc se odchylovat od toho co Espressif vypotil, ale asi k tomu mate nejaky duvod.

Ne ze bych mel pocit, ze veci okolo ESP jsou naprogramovany dobre, ale ten bezny zaklad mi nikdy vylozene nepadal, casto se akorat stava, ze zarizeni najednou neni dostupne a v logu neni nic smysluplneho.

[Jiri Dobry]

A zkusil jsi jiny kus HW?
Podle zkusenosti jsem uz videl spoustu ESP chipu, ktere meli problem se stabilitou pripojeni pripadne se nepripojily vubec. Nevim, jesli je to nekvalitou ESP chipu obecne, nebo nam cinan posila to, co v tovarne "spadne pod stul", ale je to bohuzel tak.

[MalyTomi]

A skusal si si pozriet, ako je pripojeny modul na wifi? bud na routri, alebo v zariadeni? aky ma signal a kvalitu? ja sice pouzivam esp8266 spolu s arduino, wifi mam mikrotik a zistil som, ze dost zalezi, ako je modul otoceny. U mna je trocha problem aj v tom, ze mam 2 wifi ap s jednym ssid a nastaveny mesh, ale stava sa mi, ze modul sa pripoji na ten druhy AP, kde ma podstatne slabsi signal a potom mi tcp spojenie nahodne vypadava a tiez sa mi stava, ze http spojenie pada.

[fortran1986]

A kdyz vezmete nejaky bezny example z esp-idf, bezi to jak ma?

Popravde receno nechapu duvod proc se odchylovat od toho co Espressif vypotil, ale asi k tomu mate nejaky duvod.

Ne ze bych mel pocit, ze veci okolo ESP jsou naprogramovany dobre, ale ten bezny zaklad mi nikdy vylozene nepadal, casto se akorat stava, ze zarizeni najednou neni dostupne a v logu neni nic smysluplneho.

Neviem teraz celkom, na čo narážate. Používam hlavne veci od espressiffu, ale tam kde mi niečo chýba, použijem komponenty tretej strany.

A zkusil jsi jiny kus HW?
Podle zkusenosti jsem uz videl spoustu ESP chipu, ktere meli problem se stabilitou pripojeni pripadne se nepripojily vubec. Nevim, jesli je to nekvalitou ESP chipu obecne, nebo nam cinan posila to, co v tovarne "spadne pod stul", ale je to bohuzel tak.

Zkúsil a výsledok bol rovnaký. Nakoniec som to fixol podľa toho postu https://github.com/fhessel/esp32_https_server/issues/85 akurát som to opatchoval o niečo čistejšie... Asi tú knižnicu esp32_https_server forknem a hodím na github, lebo vyzerá to tak, že autor knižnice ju už ďalej nevyvýja (posledný commit urobil pred 13timi mesiacmi). Ja som tam okrem tohoto bugfixu pridal dosť veľa nového kódu, napr. podporu servovania statického obsahu a Cčkové function pointery, som nahradil std::function.

A skusal si si pozriet, ako je pripojeny modul na wifi? bud na routri, alebo v zariadeni? aky ma signal a kvalitu? ja sice pouzivam esp8266 spolu s arduino, wifi mam mikrotik a zistil som, ze dost zalezi, ako je modul otoceny. U mna je trocha problem aj v tom, ze mam 2 wifi ap s jednym ssid a nastaveny mesh, ale stava sa mi, ze modul sa pripoji na ten druhy AP, kde ma podstatne slabsi signal a potom mi tcp spojenie nahodne vypadava a tiez sa mi stava, ze http spojenie pada.

Nakoniec som sa vydal cestou najmenšieho odporu a opatchoval som to, lebo zariadenie by predsa len malo korektne fungovať aj pri horšom wifi signále.

[Reklama]

[mikee2185]

Nepodceňoval bych ani HW - ono většinou nejsou špatné samotné ESP čipy, ale to okolo. Obzvlášť čínské DevKity mívají velmi špatné napájení (lineární regulátor na 3.3V), a to dělá právě s WiFi (a také při bootu) dost velkou neplechu. A pozor, to, že je to z CZ eshopu nic neznamená, je to pořád stejný šmejd, jen s přirážkou.