07-07-2024, 11:31 PM
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.
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.
V12.0 modifiée récurrence d'interrogation serveurs, RTE, et code UxIx3. 1 serveur RMS UxIx3, 1 client Triac CE + 1 client SSR CE. 1 client SSR sur CE tri sur 1 serveur Linky réf. CACSI. Variateurs de fréquence sur Piscine et Spa.
6 panneaux (2 SO 2 S, 2 SE ) 425Wc produisent 13kWh de jour actuellement.
6 panneaux (2 SO 2 S, 2 SE ) 425Wc produisent 13kWh de jour actuellement.