Voila c'est compilé/téléverser


Ton test se déroule je le poste dés qu'il est terminé 

Je voulais te mettre le test complet mais toutes tes requêtes ont fonctionné à 100% sauf à 50ms je pense que c'est normal

Je te met un extrait tout de même

(19-08-2025, 05:15 PM)cupriste a écrit : Voila c'est compilé/téléverser


Ton test se déroule je le poste dés qu'il est terminé 

Je voulais te mettre le test complet mais toutes tes requêtes ont fonctionné à 100% sauf à 50ms je pense que c'est normal

Je te met un extrait tout de même

quelques erreurs dans mon code  mais pas grave, de mon coté  j'ai rajouté une requete un plus complete aucune erreur de connexion meme à 10ms !!! avec en // deux autres ESP qui font les lectures à 100ms !!!

d'autre part je constate que le shelly mets à jour ses mesures entre 220 ms min et 400ms max
je constate qu en bombardant à 10ms coté RMS sa bronche pas 

en clair le programme du shelly est ultra robuste et stable
première conclusion les timeouts sont le fait de l ESP RMS .....reste à trouver où .....

Comme tu sais compiler je te suggère de telecharger le source de la v15.03 d André et de ralentir les requetes en modifiant les lignes du module Solar_routeur_v15_03 suivantes

      if (Source == "ShellyEm") {
        LectureShellyEm();
        LastRMS_Millis = millis();
        PeriodeProgMillis = 200; //200 + ralenti;  //On s'adapte à la vitesse réponse ShellyEm
      }
      if (Source == "ShellyPro") {
        LectureShellyProEm();
        LastRMS_Millis = millis();
        PeriodeProgMillis = 200 + ralenti;  //On s'adapte à la vitesse réponse ShellyProEm

En remplacant le 200+ralenti par 500 + ralenti voir si cela fait chuter ton de failed, en attendant je continue de scruter le code d'André...

(19-08-2025, 06:53 PM)Lolo69 a écrit :

(19-08-2025, 05:15 PM)cupriste a écrit : Voila c'est compilé/téléverser


Ton test se déroule je le poste dés qu'il est terminé 

Je voulais te mettre le test complet mais toutes tes requêtes ont fonctionné à 100% sauf à 50ms je pense que c'est normal

Je te met un extrait tout de même

quelques erreurs dans mon code  mais pas grave, de mon coté  j'ai rajouté une requete un plus complete aucune erreur de connexion meme à 10ms !!! avec en // deux autres ESP qui font les lectures à 100ms !!!

d'autre part je constate que le shelly mets à jour ses mesures entre 220 ms min et 400ms max
je constate qu en bombardant à 10ms coté RMS sa bronche pas 

en clair le programme du shelly est ultra robuste et stable
première conclusion les timeouts sont le fait de l ESP RMS .....reste à trouver où .....

Comme tu sais compiler je te suggère de telecharger le source de la v15.03 d André et de ralentir les requetes en modifiant les lignes du module Solar_routeur_v15_03 suivantes

      if (Source == "ShellyEm") {
        LectureShellyEm();
        LastRMS_Millis = millis();
        PeriodeProgMillis = 200; //200 + ralenti;  //On s'adapte à la vitesse réponse ShellyEm
      }
      if (Source == "ShellyPro") {
        LectureShellyProEm();
        LastRMS_Millis = millis();
        PeriodeProgMillis = 200 + ralenti;  //On s'adapte à la vitesse réponse ShellyProEm

En remplacant le 200+ralenti par 500 + ralenti voir si cela fait chuter ton de failed, en attendant je continue de scruter le code d'André...

Merci pour ton retour je fais ce test

Dans la version 15.03 c'était bien les lignes 1034 et 1039?

Lorsque je laisse tourner l'esp hors routeur si ma mémoire est bonne je n'ai pas le souci 

ça ne serait pas le gradateur ou autre qui pourrait faire des interférences par exemple?

Confirmes nous que si esp hors routeur tu n as pas d'erreurs , c'est pas ce que j'avais compris dans ce cas ca "revaliderai" un probleme materiel ou de parasites...

En effet de mon coté en bombardant les mesures de puissances à 5ms , j'ai quelques timeout sur l esp du routeur pres du SSR et aucune coté ESP sans SSR ni triac
en tout cas on a 3 exemples de forumeur pour qui le passage en 15.03 à resolu les soucis, donc de ton coté c est autre chose...

Bon on avance doucement mais surement
de mon coté je vais placer mon esp de test dans des perturbations electromagnetiques importantes pour voir l immunité
esp placé sur la plaque à bornes d'un moteur 1KW avec plusieurs demarrages / arrets la connexion Shellly n'a pas bronchées....donc je dirais plutot bien immunisé contre le bruit ....apres le courant haché c est plus violent mais bon ...

A titre purement experimental j'ai repris entièrement le code des sources Shelly et Shelly Pro juste pour Cupriste pour l'instant qui n'a pas les memes soucis que les autres ;-) Cupriste il s'agit d'une version de test si tu veux bien l'essayer....

J'ai testé cette nouvelle façon de faire sur un shelly EM mais comme je n'ai pas de Shelly Pro , si tu veux bien charger le code suivant de façon TEMPORAIRE sur ton routeur  et me faire un retour, si c est positif j'enverrai les explications detaillées à André pour qu'il regarde de plus pres les modifs qui ont pour but une grosse optimisation de code et passage en connexion HTTP au lleu de TCP , en théorie c est un peu plus lent ( mais très largement suffisant) mais surtout beaucoup plus stable car agissant dans une couche plus haute


version experimentale V15_03_LBE1

Hello Lolo69,

Petit retour de là où j'en suis dans mes expérimentations .

J'ai modifié comme tu me l'as demandé la version 15.03 d'André.

Premier test : l'esp est en fonctionnement hors routeur . Aucune alarme shelly durant 18h juste quelques réception heure je sais pas si cela est normal , je te met un imprim écran

Deuxiéme test : Mise en place de l'esp dans le routeur mais sans aucune connexion (hormis l'alimentation 5V). Essai durant 1h30 pas d'alarme

Troisiéme essai : Remise en place de l'esp en service . J'ai fait une bétise en sautant une rangée de pin... Je corrige ma connerie tout fonctionne sauf les sondes de températures...
Ne sachant pas s'il y a une coquille dans le programme que j'ai modifié j'ai réinjecté la version 15.03 d'André. Mon probléme de sondes persiste mais je pense que c'est matériel en revanche pas d'alarme durant l'heure d'essai.( avec la version d'André du coup) 

Je pense que je vais attendre les alarmes pour tester ton nouveau programme lolo69 qu'en penses tu?

Non c est bon ca veut dire que la 15.03 est ok et rien à voir avec les sondes c est autre chose donc pas de raison de mettre mon programme ( sauf évidemment les alarmés reviennent en grand nombre)
C est nickel ca veut dire qu’une fois de plus André a bien assuré avec sa v15.03 ce que je n explique pas c est qu il le semble que tu avais deja testé la 15.03 et qu il y avait des erreurs. Si le fait de brancher debrancher l esp a corriger le probleme c etait potentiellement un probleme matériel.
Pour le coup je considere ce topic comme etant réglé non ?
Les receptions heures oui c est normal
Erreur zc ca doit vouloir dire que tu n as pas reconnecté le 220vac
Ca nous valide que la 15.03 est efficace pour shelly et shelly pro c est cool

Effectivement je pense que vous avez trouvé André et toi la cause ! Chapeau vous êtes des balézes!

Je suis à 10h de fonctionnement de l'esp , pas de message shelly.Par contre oui désormais il fait une réception de l'heure internet toutes les 3 heures.

Je n'avais pas testé la 15.03 publié par André mardi matin , j'avais testé la 15.02 mais pas celle ci . Je suis passé de la 15.02 à la 15.03 avec la modification des 500ms.

Tu peux bien sur considéré ce topic comme réglé .

Effectivement l'esp n'étant pas remis su mon pcb, j'avais l'erreur du zéro crossing car pas alimenté .

Il me reste mon absence de température à résoudre , j'ai pas pensé à regarder si je n'ai pas cramé la 4,7k ohm à vérifier

Attention, les DS18B20 doivent être alimentés en 3.3V, et non en 5V, pour attaquer directement un GPIO de l'ESP 32. En effet, ce dernier fonctionne en logique 3.3V, les signaux logiques 5V du DS18B20 pourraient l'endommager (ça peut marcher quelques temps, mais c'est nettement hors specs du composant). En fait la tension qui compte vraiment, c'est celle à laquelle est reliée la résistance de pull-up des DS18B20: ça doit être 3.3V.

(Hier, 02:38 PM)FastFrench a écrit : Attention, les DS18B20 doivent être alimentés en 3.3V, et non en 5V, pour attaquer directement un GPIO de l'ESP 32. En effet, ce dernier fonctionne en logique 3.3V, les signaux logiques 5V du DS18B20 pourraient l'endommager (ça peut marcher quelques temps, mais c'est nettement hors specs du composant). En fait la tension qui compte vraiment, c'est celle à laquelle est reliée la résistance de pull-up des DS18B20: ça doit être 3.3V.

Tu es sur de cette info ?

Cela m'interesse beaucoup car je l'alimente en 5V avec une résistance de 4700ohm entre le 5v et le data.

Je trouve sur le datasheet ci joint qu'on peut l'alimenter entre 3V et 5,5V , peux tu m'expliquer?

@Lolo69 et André si vous me lisez , zéro message de shelly failed ou timeout 2 en 24h de fonctionnement avec la 15.03, un grand merci !

(Il y a 8 heures)cupriste a écrit :

(Hier, 02:38 PM)FastFrench a écrit : Attention, les DS18B20 doivent être alimentés en 3.3V, et non en 5V, pour attaquer directement un GPIO de l'ESP 32. En effet, ce dernier fonctionne en logique 3.3V, les signaux logiques 5V du DS18B20 pourraient l'endommager (ça peut marcher quelques temps, mais c'est nettement hors specs du composant). En fait la tension qui compte vraiment, c'est celle à laquelle est reliée la résistance de pull-up des DS18B20: ça doit être 3.3V.

Tu es sur de cette info ?

Cela m'intéresse beaucoup car je l'alimente en 5V avec une résistance de 4700ohm entre le 5v et le data.

Je trouve sur le datasheet ci joint qu'on peut l'alimenter entre 3V et 5,5V , peux tu m'expliquer?

@Lolo69 et André si vous me lisez , zéro message de shelly failed ou timeout 2 en 24h de fonctionnement avec la 15.03, un grand merci !

Le DS18B20 fonctionne effectivement entre 3.0 et 5.5V (aussi bien pour la tension d'alimentation que pour la référence utilisée avec la résistance Pull-up). 
Mais si VDD = 5V et la résistance Pull-up est également connectée au +5V, alors le signal sur la broche Data du DS18B20 peut atteindre 5V en théorie (quand transistor de sortie collecteur ouvert du DS18B20 est non passant). 
De l'autre côté, l'ESP32 utilise une tension de 3.3V en interne. Les signaux logiques sur ses entrées ne doivent pas dépasser VDD = 3.3V (en transitoire de courte durée, il peut supporter jusqu'à VDD + 0.3V = 3,6V selon les specs). Il risque donc d'être endommagé par des tensions allant jusqu'à 5V provenant du DS18B20, si aucune précaution n'est prise (conversion des tensions). 
Donc oui, je suis relativement sûr de moi dans cette affirmation. Après je ne pourrais pas te dire combien de temps un ESP32 peut résister dans ces conditions. C'est probablement très variable (quelques secondes, plusieurs minutes, des heures, peut-être même des mois pour les plus résistants).