Reset quotidien intempestif

[Bendu13]

Bon, même si avec la nouvelle alimentation les reset intempestifs sont moins nombreux (j'arrive à tenir 2 jours d'historique) j'ai toujours le même phénomène.
Je n'arrive pas à comprendre d'où ça peut venir...
Autre problème, c'est qu'après un reset, les sorties qui étaient à 1 ne remontent pas et restent à 0 (au moins plusieurs minutes, j'ai dû les forcer/déforcer pour avoir le bon état par rapport à mes actions programmées).
Avez-vous déjà constaté ce phénomène ?

[Sgb31]

Bonjour,
Etes vous sûr que la wifi ne se plante pas ou ne s'arrête pas dans le cycle, pendant le nuit ou autre entrainer en cascade un manque de comm du shelly , engendrant un reset
Il faudrait scruter autour de l'heure de ou des reset ou vérifier le comportement de chaque élément (wifi box, shelly voir les logs ...).
vous parlez de broker MQTT , avez vous une liaison avec HA ?
Après comme vous le dites, depuis le chgt d'alim, ya moins de reset ... y aurait il plusieurs causes au pb en fait ?
A suivre donc ...

[glu3]

Bonjour,
J'ai parcouru ce sujet, et j'ai un peu le même problème que vous sur mon esp32 qui mesure la production de mes panneaux.
Sur ce jsy j'ai mis la pince mobile sur l'entrée de production ( soutiré : 20W, injecté : de 0 à 3200W l'autre jour)  et la sonde fixe sur la consommation des chauffages.
Comme il pleut de remps en temps dans le 22 la prod est plus prête de 0 et j'ai des reset de mon esp.
Est-ce que cela peut venir du passage à zéro des infos pendant un certain temps ?

[Bendu13]

Non, des données à 0 ne provoquent pas de reset de l'ESP32 mais par contre, l'absence de donnée ou plus exactement une valeur inconnue, comme la mesure de puissance ou la liaison internet peuvent provoquer un reset (si j'ai bien tout compris). Une valeur à 0 n'est pas une situation anormale.
Sur ce point j'ai mis 12h d'absence de wifi avant de faire un reset et j'ai un niveau de réception à -35db donc j'élimine la cause wifi.
J'ai essayé deux sources de mesure de puissance : Linky et MQTT donc c'est pas ça.
J'ai remplacé l'alimentation et même si le phénomène est moins fréquent, je l'ai encore.
Est-ce que l'alimentation pourrait être perturbée par les découpages de sinusoïdes ? (harmoniques).
J'utilise trois SSR pilotés par un quatrième (un GPIO pilote un SSR DC/DC 3V qui alimente trois SSR DC/AC en 5V en parallèle).

[Sgb31]

Il faudrait effectivement lister et tracer toutes les causes possibles de reset coté routeur afin d'avancer sur les causes mais le chgt d'alim qui semble améliorer les choses m'interpelle quand même ...

[Bendu13]

Je suis d'accord, j'ai commandé une alim 5V avec transfo et redresseur (pas à découpage) et je la remplacerai pour voir.
Je ne sais pas si c'est une déformation professionnelle mais je me demande si mon alim usb (de mauvaise qualité vu le prix) n'est pas perturbée par des harmoniques ou au contraire si elle ne génère pas des harmoniques qui perturberaient l'ESP32.
Je ferai un retour d'expérience après son remplacement.

[Sgb31]

Ok, Ben, tiens nous au courant de la suite !

[Lolo69]

Un petit condensateur sur l alimentation permet de lisser les perturb

[F1ATB]

Je suis d'accord, j'ai commandé une alim 5V avec transfo et redresseur (pas à découpage) et je la remplacerai pour voir.
Je ne sais pas si c'est une déformation professionnelle mais je me demande si mon alim usb (de mauvaise qualité vu le prix) n'est pas perturbée par des harmoniques ou au contraire si elle ne génère pas des harmoniques qui perturberaient l'ESP32.
Je ferai un retour d'expérience après son remplacement.

Ce sont les appels du Wifi, les transmissions Wifi qui font des appels de courants importants et plonger les alimentations .
André

[Bendu13]

Je ne suis pas le seul qui ai ce problème (voir autre post ci dessous).
Il semblerait que ce problème survienne lorsque la mesure est remontée via MQTT et éventuellement Shelly EM aussi pour ma part.
Je suis repassé en mesure Linky et je suis en marche depuis plus de 21 heures.
Quel serait le point commun entre MQTT et Shelly EM et différent avec Linky ?
Merci d'avance pour votre aide car j'aimerai vraiment avoir une installation utilisant MQTT fiable car c'est la méthode que j'utilise pour prioriser le chauffe-eau versus la batterie de stockage.

Bonsoir , 

J'ai connu le routeur en V7 puis j'ai evolué jusqu'à la version V13.03 avant de décider de passer à la V16.10 en vue d'utiliser MQTT. D'ailleurs encore une fois merci André et la communauté pour ces évolutions très utiles.

je possède un esp 32 vroom principal en v16.10 sur lequel entre le linky via cablage et pilotant mon contacteur J/N. Mon deuxième esp 32 CE lui récupérait la valeur de l' esp principal pour chauffer ou non mon chauffe (V16.10 aussi). Tout fonctionnait bien.

J'ai ajouté des batterie avec pilotage Victron cerbo GX (qui à un compteur en entrée de chez moi pour la puissance, comme le linky). 

Afin de ne pas vider ma batterie pour chauffer mon lorsque l'esp 32 CE fonctionne, j'ai décidé d'utiliser la fonction broker MQTT du cerbo GX via node red. Sur le fonctionnement c'est très bien sauf que l'esp 32 qui recoit la puissance via MQTT se reboote régulièrement et ce n'est pas lié au wifi (j'ai mis tempo à 30 min et ai vu rebooter alors que l'affichage de la puissance évoluait 2 minutes avant) .
L'esp 32 CE reboote environ une à deux fois par jour ce qui pose problème pour gérer les temps de chauffe correctement et perte d'historique. Bien sur l'esp Principal lui ne reboote pas (pour rappel l'esp Principal n'est pas relié à MQTT).

J'ai fait un test avec un esp en V17.06 qui est en plus et qui lui ne pilote rien , il sert juste à voir s'il reboote en com MQTT : résultat  lui aussi reboote.

J'ai fait un envoie de message MQTT toutes les secondes puis toute les 2 secondes mais rien n'y fait.

Pas très à l'aise avec MQTT, quelqu'un d'autre a t'il eu ce problème ou avez vous une solution?

Merci