+- F1ATB forum (https://f1atb.fr/forum_f1atb)
+-- Forum : Forum de F1ATB (https://f1atb.fr/forum_f1atb/forum-3.html)
+--- Forum : Routeur Photovoltaïque (https://f1atb.fr/forum_f1atb/forum-4.html)
+--- Sujet : Idée autour des plantage ESP32 à partir de V9.02 sur connections WIFI mutliples. (/thread-201.html)
Idée autour des plantage ESP32 à partir de V9.02 sur connections WIFI mutliples. - PhDV61 - 07-07-2024
Je me pose toujours des questions sur l'utilisation du WIFI en général, et la manière dont les connexions sont implémentées
A chaque requête callESP32_Externe(), on établit une connexion WIFI par une nouvelle requête "Connect", sans pour autant n'avoir jamais réalisé de "DisConnect()" ou stop(), sauf pour ce dernier cas en cas de timeout de réception.
On ne sait donc pas ce que devient le bloc alloué avec la création de la connexion WIFI lorsqu'on sort de cette fonction. Probablement que ce qui est en pile est récupéré, mais on n'est pas à l'abri que des scories restent quelque part ailleurs en fonction de l'implémentation des bibliothèques.
Ne serait-il pas opportun de suivre ce que dit la doc, à savoir créer la connexion une fois seulement dans le setup (puisqu'elle est sensée être appelée de manière répétitive par la suite ), et, en cas de perte du lien, de suivre la procédure recommandée, à savoir
This API attempts to connect to an Access Point (AP) only once. To enable reconnection in case of a connection failure, please use the 'failure_retry_cnt' feature in the 'wifi_sta_config_t'. Users are suggested to implement reconnection logic in their application for scenarios where the specified AP does not exist, or reconnection is desired after the device has received a disconnect event.
De même, pour les pages HTML, et les connections multiples et rapides, il a été montré par des utilisateurs sur github qu'une fuite mémoire apparente pouvant conduire au plantage de l'ESP32 se produisait à partir de la bibliothèque 3.0. Cette fuite est momentanée, car en cas d'arrêt des requêtes html via wifi et AVANT le plantage, la mémoire se libérait (garbage collector) en 2 minutes ( ce qui est très long ). Il faut donc pour le moment éviter les pages multiples ET attendre 2' avant une nouvelle interrogation. J'espère que ce point sera réglé lors d'une prochaine release de la bibliothèque.
RE: Idée autour des plantage ESP32 à partir de V9.02 sur connections WIFI mutliples. - F1ATB - 08-07-2024
Le non-maintien de la connexion , quand l'ESP32 est client, rend l'exécution du code plus facile, et on n'a pas la preuve que cela augmente l'occupation mémoire. Les volumes échangés dans les connexions répétitives sont faibles. Sauf plantage, les connexions sont fermées proprement '"...GET ") + url + " HTTP/1.1\r\n" + "Host: " + host + "\r\n" + "Connection: close\r\n\r\n")...
Par contre, la mise en place d'une page HTML, cas ou l'ESP32 est serveur, est très volumineuse. Dans ce cas c'est le navigateur web qui ne maintien en général pas la connexion. Pour la page Action il y a plus de 30k octets pour le Javascript. Quand on la rappelle sans arrêt, on voit la mémoire fondre. Cela se passe mieux depuis qu'elle a été découpée en 3 fichiers Javascript appelés l'un derrière l'autre. Il y a peut-être à creuser dans la manipulation des Strings qui contiennent le code avant envoi. Pour ces gros fichiers, de page, le navigateur web n'a pas de raison à maintenir la connexion.
Comme PhDV61 le dit, il serait bon également d'avoir une évolution du garbage collector dans une prochaine version du code 3.x.x de l'ESP32.
Cdlt
André