les anciennes versions de font pas de mise à jour en ligne, pour ma part, la seule que j’ai testée en deux étapes a foiré 
Bonjour,
Y a t il une suite a ce sujet, car sur mon jeedom 4.2.14, ca ne veux pas fonctionner ?
Merci
bonjour,
ça veut dire quoi « ca ne fonctionne pas »?
chez moi ca tourne nickel depuis le debut du script . Juste un petit problème d’Iframe sur les acces externe à partir de la 4.3. Mais j’ai donné un workaround dans un autre post
Bonjour à tous,
alors tout d’abord bravo pour ce script. On voit enfin comment se comportent les ESP.
Pour ceux qui seraint moins exigeants, il y a la possibilité de coller ca dans les Rules
on System#Boot do
Let,1,0 // set user variable to initial state of 0
endon
on Wifi#Disconnected do // if no wifi, wait 3 minutes
if [VAR#1]=0
timerSet,1,180
Let,1,1 // set user variable 1 to 1 to prevent re-set of var1 on each event.
endif
endon
on Wifi#Connected do // if wifi returns, cancel reboot
timerSet,1,0 // cancel timer
Let,1,0 // set user variable 1 to 0
endon
On Rules#Timer=1 do // if still no Wifi, reboot
reboot
endon
grosso modo ca reboot l’ESP si il perd le wifi ou si la liaison devient instable.
depuis que j’utilise cela plus de pb.
et pour surveiller les ESP, j’ai dans chaque ESP un « Device » de type generic info qui remonte la charge système et le RSSi toutes les 2 minutes
Et coté Jeedom j’ai juste paramétré des alertes de timeout dans la surveillance d’équipements
Tout cela est bien moins précis et efficace que le script.
c’est plus une solution de faignant qui apporte le mini pour sécuriser le Wifi et faire une surveillance
D’ailleurs dès que j’aurais le temps je pense passer au scipt.
Hello, cela peut sembler être un de-terrage mais je voudrais apporter ma pierre a l’edifice
En effet j’ai certains esp, notement des recents qui " freeze " , il semble encore en fonction pourtant plus aucunes communications.
Du coup j’ai installé ce script pour les surveiller.
Par contre j’ai l’impression que la relation RSSI bas et freeze n’est pas averée.
j’ai 2 esp dans la chaudiere et le local buanderie par exemple qui sont a -81db et -94db et qui ont 194 jours d’uptime.
au contraire, 1 autre a -50db me fait chier un jour sur deux, de façon aléatoire.
Je pencherais plutôt sur la qualité de fabrication et l’alimentation
En effet celui qui me saoule est un ESP-12F , qui a une alimentation et un relais integré
voir ICI
Je vais tester sur un esp récalcitrant, la technique de modélisme contre les " brown out " = mettre un gros condo sur l’alim pour qu’elle lisse et joue le rôle d’un mini onduleur.
Je vais continuer mes investigations car j’en ai posé un grand nombre chez des potes, histoire de voir réellement ceux qui tiennent ou non.
Je vais ajouter aussi mon cailloux …
J’ai une 20aines d’ESP qui tournent, surtout des Wemos D1 mini chinois (8266 12F pour la plupart).
J’en ai 2 qui bug régulièrement, avec la particularité que ce sont les 2 ESP qui sont relié à mon point d’accès wifi au niveau du portail (un TP LINK TL WR703N). Leur RSSI est de -53dB et -63dB. Et niveau alim, c’est une grosse alim de 5V/20A.
Mes versions d’ESPeasy sur ces 2 ESP datent du 12/2021 (mais j’en ai d’autre avec cette version qui fonctionnent très bien).
J’avais comme symptôme la perte de communication définitve avec l’esp (obligé de couper l’alim pour récupérer l’esp) malgré la rule de reboot:
on Rules#Timer=8 do // no pong, reboot
reboot
endon
Je me suis dit qu’à cause de cette règle, quand l’esp reboot, mon TPLink ne lui redonne pas proprement (et rapidement) d’adresse IP, et donc l’ESP refait un reboot et ainsi de suite => ça part en reboot permanent.
Initialement, le script avait été fait pour palier au problème de stabilité du wifi avec espeasy en 2020. Sauf que depuis il y a eu énormément de bugfix autour de ça.
Dans un premier temps, j’ai supprimé le reboot de la règle. L’ESP se crash tout seul (généralement à cause d’une exception d’espeasy), mais au redémarrage, il « attend » et fini par récupéré une configuration réseau correct. Suite à ce 1er changement, toujours des reboot suite à des exceptions mais pas de perte définitive:
Dans un 2nd temps, sur l’un des 2 ESP problématique, le 11/09 j’ai mis une version ESPeasy du 22/08/2023 => Plus aucun reset depuis cette date:
Idem avec un autre ESP dans la maison qui se tapait des resets de temps à autres (1fois pas semaine en moyenne). Je lui ai mis un firmware du 22/08/2023 et plus de reset depuis ce jour.
Je précise que j’ai tout laissé par défaut dans ESPeasy pour la partie Tools->Advanced->Special and Experimental Settings
Pas mal cette conclusion sur la version d’esp easy.
Est ce que tu as fait une mise a jour OTA ou en local ?
Je l’ai fait en local en effaçant tout avec un blank au préalable car en OTA , il y a toujours des résidus de code qui traine soit dans l’eeprom soit dans la flash et qui pourrait générer des exceptions au niveau de l’esp.
Mais je vais pas tardé à basculer mon ESPportailRF433 (celui de mon 1er screenshot) vers une version du 22/08/2023, et je ferais ça en OTA pour voir si ça marche correctement.
Ok je viens de faire la migration des 3 esp8266 en 2023-08-22 _normal-1M que j’ai sous la main
ceux du garage et du jardin attendront un peu.
Premier constat :
Le flash OTA est aleatoire, 2 sur 3 sont passé impec, le troisième a foiré.
Ils etait tous sur le build 2021 xxx xxx ( j’étais tellement sur que l’ota ne fonctionnerait pas que j’ai pas noté comme un C… ) il y a une possibilité que celui qui a foiré etait flashé en 4M et non en 1M
Par contre grosse amelioration du reseau, ou en tout cas de la sélection de la borne la plus proche. J’ai 5 bornes wifi chez moi , et lorsque j’ai commencé les mise a jours, certain esp etait a -94db et -92db.
Apres OTA, on est à -75 et -73 ils ont surement dû accrocher sur une borne plus proche, et tant mieux !
Je continue à monitorer et je vous tiens au courant.
Je suis en 2023-08-22 _normal-4M
En tout cas, si ça améliore aussi chez toi, ça fait une bonne piste de résolution de la root cause du problème de reboot des esp.
Ca m’étonne qu’à moitié. A chaque fois ça foirait chez moi donc ça fait longtemps que je fais plus. Mais y a peut etre eu de l’amélioration aussi de ce coté là.
J’ai passé une bonne grosse partie des esp8266, (7 module en tout ) sur 2 sites, en version
mega_20230822_normal_ESP8266_4M1M
et les nouveau ESP32 que je viens d’installer en version
mega_20230822_normal_ESP32_4M316k
Tout ca chapeauté par le script de Ping-Pong.
Maintenant Wait & see
t’as bien noté que j’avais enlevé le reboot de la rules dans espeasy puisque les esp ne semblent plus se bloquer.
Yes j’ai vu, mais est ce que tu es sur que c’est bloquant ( comme tu décris la boucle de auth session du Wifi ) parce que jusque la ça aidait pas mal
Non après reflexion c’était juste dans mon cas car après un reboot forcé par la rule, l’esp ne retrouvait pas le réseau. Mais peut etre qu’avec c’est version du 08/2023, ça se passerait bien
J’ai vu que sur la mega-20230822 il existe un parametre « Extra Wait WiFi Connect: » ca pourrait peut être aider.
En tout cas pour l’instant pas de ESP zombie depuis les mises a jour
Bonjour,
Une simple question: où je peux me procurer le mega-20230822 ?
Merci pour vos réponses
Bonjour,
Je me réponds j’ai trouvé mais je suis un peu perdu car j’ai l’habitude avec des firms anciens (mega-20190215) et l’utilisation de Flashesp32 comme logiciel alors qu’ici, je ne vois rien de tel !!!
il suffit de copier l’outil depuis une ancienne version du firmware
@Djelau
Merci pour cette réponse rapide et précise je ne pensais pas que cela soit ainsi en fait: c’est très simple
Cordialement
Hello,
J’ai eu ici aussi quelques soucis de reboot inutiles. J’ai modifié les timers et fini par trouver une valeur qui fonctionne correctement: le ping à 120 et le pong à 1800. J’en suis à une moyenne de 28 esp en ligne et sur lesquels je ne dois plus intervenir, certains sont difficile d’accès. Le plus gros problème chez moi c’est après une coupure de courant, quand les esp sont en ligne avant les bornes wifi que cela foirait le plus. Avec le script dans les 10 minutes qui suivent, tout revient en ligne tout seul.
Alors oui, les dernières versions sont bien plus stable niveau connexion, et heureusement que cela a été amélioré. Autre point, la qualité de fabrication. J’ai quelques sonoff dans le tiroir qui fonctionnent mais qui ont toujours déconné. Vu le prix, je cherche plus, je remplace. Certains encore en service reboot régulièrement et pourtant proche d’une borne et dans la même build que d’autres qui sont en ligne depuis plus de 100 jours.
Cela reste du lowcost.
@++
