Besoin de conseils pour faire fonctionner mon routeur

[FastFrench]

En fait non, pour une résistance de chauffe sa résistance diminue avec la chaleur (certainement à cause du carbone qu'elle contient).
C'est en fait le constat de mes mesures car pour la plupart des autres matériaux leur résistance augmente avec la température.
Comme tu démontres l'inverse on peut penser que c'est l'élévation de la température des fils d'alimentation qui font que globalement la résistance augmente.

Tu es sûr ? Par exemple pour le filament d'une ampoule (tungstène), la résistance augmente bien avec la température, ce qui constitue d'ailleurs une sorte de régulation "naturelle" permettant d'améliorer la durée de vie et résistance aux surtensions (pas trop rapides). 
Et il n’y a généralement pas de carbone dans les résistances des chauffe-eau domestiques. Les résistances utilisées dans les ballons d’eau chaude sont principalement des fils métalliques — le plus souvent en alliage de nickel-chrome (nichrome), inox ou cuivre. Ce sont ces matériaux qui offrent à la fois une bonne conductivité, une bonne tenue à la chaleur et une résistance à la corrosion.

Enfin bref, peu importe, on s'égare

---

Revenons sur le fond: 
En fait le premier essai visait à tester la mesure des puissances par le Shelly, et accessoirement la puissance consommée par le ballon. On voit que le résultat était propre sans bavure. 

Le second essai consistait à demander au routeur d'alimenter le ballon à 50% sans aucune régulation, de façon à voir si d'éventuels parasites pouvaient perturber ce fonctionnement assez simple et en principe bien maîtrisé. Et on constate clairement que c'est le cas: ça ne donne pas du tout le résultat escompté, et cela permet déjà d'expliquer mes déboires depuis le début. 
Donc à ce stade, il faut que je comprenne pourquoi j'ai ce fonctionnement chaotique dans un cas pourtant simple. 

J'ai une petite idée en fait. Je crois que je vais devoir sortir l'oscillo et aller tripatouiller dans le routeur ^^ (ah, ça me rappelle ma jeunesse...)

[FastFrench]

Nouveau jeu d'essais: 
Force forcée, mais cette fois en forçant la fermeture du SSR

=> pas hyper stable, mais disons que c'est à peu près OK (je ne suis pas seul à la maison ^^). 

Et maintenant je refais le test avec 50% de charge en passant par le routeur, après avoir retiré une source possible de parasites dans le routeur. 

Zut, ce n'est pas encore ça

Visualisation signal à l'entrée du SSR, quand aucune action n'est en court (SSR reste ouvert):

Oops... c'est très parasité tout ça. Et avec une amplitude qui atteins les +3V...


Visualisation du signal à l'entrée du SSR, avec fermeture permanente du SSR à 50%

Euh... ce n'est pas du tout ce que j'attendais. En multi-sinus, je m'attendais à un signal rectangulaire, avec des états hauts et bas sur plusieurs périodes de 20ms. 

Essayons en train de sinus: 
Ce n'est pas mieux au niveau des signaux, ni bien entendu de la puissance...


Bon, c'est un déprimant tout ça. Va falloir que je modifie le montage pour ajouter des pin de test. Parce que là ce n'est vraiment pas accessible (et avec les connecteurs cheap AliExpress, ça tient comme ça veut). Il faudrait au moins que je remonte au GPIO pour voir à quoi ressemble le signal à ce niveau. 
Dans tous les cas le signal de commande du SSR me parait très suspect.

[Jacques13]

Je te confirme qu'en multi sinus le signal est parfaitement propre avec des fronts francs, seule la durée haute change en fonction de l'ouverture requise. A 50% d'ouverture on a un signal carré de 0 à 3V avec un cycle d'environ 270ms.
Outre l'ESP, il est possible que ton triac ait un problème. Mets donc une résistance à la place du triac pour voir à quoi ca ressemble

[FastFrench]

OK merci pour la confirmation et ces précieuses indications. Au moins maintenant je sais ce que je devrais avoir
En fait j'ai un montage un peu particulier. J'ai trois sources avec un OU logique entre les trois: routeur, marche forcée HC et marche forcée permanente. Ce signal est ensuite mis à niveau  avec un uln 2003 pour alimenter une led + le SSR. J'imagine que le fait que l'uln 2003 vienne de mon stock de composants du temps où je bricolais l'électronique. - donc ça fait bien 40 ans - ne plaide peut-être pas en sa faveur. En principe ça ne périme pas vraiment ces bêtes là, mais va falloir que je vérifie tout ça soigneusement, à chaque étape.
Bref ce que j'ai obtenu avec l'oscillo est si foireux que je vais me monter un second routeur de test (sans charge) et regarder ça tranquillement. Et les connecteurs soudés sur le CI ne m'inspirent pas du tout confiance non plus à vrai dire (1er prix Ali Express).

[Lolo69]

C'est le problème du multi sinus ou train de sinus
à 0 % pas de soucis tout est à zero ton shelly donnera 0
à 100 aps de soucis non plus on a une belle sinusoide 50hz classique donc le Shelly sait bien mesurer

par contre au milieu le signal haché n'est plus du tout un signal periodique 50hz mais un signal aps tout à fait sinusoidale dont la periode est 1hz et là le Shelly ne sait plus mesurer la puissance efficace vraie
en fonction du moment ou il prend sa puissance tu peux très bien etre sur une sinusoide complete et donc il va trouver 100 % de la puissance , en bloquant l echantillon à sa valeur sur une seconde, meme si les 8 autres sinusoides sont à zero parce que pas declenchées.... je ne suis pas sur d'arriver à me faire comprendre , il faut vraiement que je prenne le temps de faire un dessin

Le multi ou train de sinusoide sont basés sur une moyenne en 1 seconde , il faut donc moyenner ces mesures brutes pour avoir une bonne approximation de la mesure, avec plus de rigueur il faudrait faire un calcul de valeur efficace vraie, mais mes souvenirs mathematiques sont loins.

Alors oui ce n 'est pas aussi reactif que si on reagissant toutes les 10ms comme en decoupe sinus avec triac, mais ca donne quand meme une excellente performance.

[FastFrench]

C'est le problème du multi sinus ou train de sinus
à 0 % pas de soucis tout est à zero ton shelly donnera 0
à 100 aps de soucis non plus on a une belle sinusoide 50hz classique donc le Shelly sait bien mesurer

par contre au milieu le signal haché n'est plus du tout un signal periodique 50hz mais un signal aps tout à fait sinusoidale dont la periode est 1hz et là le Shelly ne sait plus mesurer la puissance efficace vraie
en fonction du moment ou il prend sa puissance tu peux très bien etre sur une sinusoide complete et donc il va trouver 100 % de la puissance , en bloquant l echantillon à sa valeur sur une seconde, meme si les 8 autres sinusoides sont à zero parce que pas declenchées.... je ne suis pas sur d'arriver à me faire comprendre , il faut vraiement que je prenne le temps de faire un dessin

Le multi ou train de sinusoide sont basés sur une moyenne en 1 seconde , il faut donc moyenner ces mesures brutes pour avoir une bonne approximation de la mesure, avec plus de rigueur il faudrait faire un calcul de valeur efficace vraie, mais mes souvenirs mathematiques sont loins.

Alors oui ce n 'est pas aussi reactif que si on reagissant toutes les 10ms comme en decoupe sinus avec triac, mais ca donne quand meme une excellente performance.

Pour l'instant, je dirais que ce n'est pas mon principal problème. Mais sur Linky (période de mesure 2s) et les Shelly (période de mesure 1s), en admettant que la mesure effectue bien une moyenne de la puissance sur la durée de la mesure (ce que je crois), alors le fait qu'en multi-sinus et en train de sinus on ait un ou plusieurs cycles complets (ou presque) pendant la durée de la mesure fait que ça se passe plutôt bien. Et peu importe qu'on échantillonne proprement ces mesures ou pas avec le routeur: les mesures sont propres de ce point de vue. 


Sur un nouveau routeur de test, j'ai pu constater qu'en sortie de la pin GPIO, avec une charge à 50% sans régulation, j'ai: 
 - train de sinus => j'ai un signal carré périodique de période 200ms (je ne retrouve pas les 270ms de Jacques de mon côté), rapport cyclique 1/2, amplitude 3.3V (ça fluctue un peu, à +/-0.1V). 
 - multi-sinus => signal carré de période 990ms, idem pour le reste.

... en tous cas sur le GPIO 22...


Parmi les rares autres GPIO dispo sur l'ESP32 CYD, ça semble être le seul utilisable pour commander un relais (sans bidouiller la carte ESP32 ou le soft du routeur). 

Sur mon 'vrai routeur', j'ai retiré la carte mémoire, et j'utilise les GPIO 27 et 35 en entrée, et les GPIO 05, 18 et 19 en sorties (aucun n'est dispo si on garde la carte ESP32 CYD intacte). 

Le cas du GPIO27 est intéressant: je n'ai pas réussi à l'utiliser pour commander le SSR. Pourtant il est bien utilisable en sortie en principe. Mais comme il est aussi utilisé par l'écran tactile, il y a probablement une incompatibilité. Par contre sur mon "vrai" routeur, j'utilise le GPIO27 en entrée sans soucis (pour communiquer avec les DS18B20).

[Jacques13]

Selon André la période en multi sinus est de 200 à 300ms, il n'y a donc pas à s'alarmer avec ce détail

[FastFrench]

Selon André la période en multi sinus est de 200 à 300ms, il n'y a donc pas à s'alarmer avec ce détail

Disons que si c'est 200, 250 ou 333ms, ça va. Mais 270ms c'est moins bien. Vu que du coup pour une puissance consommée théoriquement constante, les sondes qui mesurent sur 1 ou 2 secondes vont donner des mesures moins stables (comme le suggérait Lolo69 plus haut). 
Supposons qu'on ait un signal carré (rapport cyclique 50%) de 270ms, donc 135ms haut, puis 135ms bas. Déjà on n'est pas sur un nombre entier de sinusoïdes à 50Hz. 135ms, c'est une fois sur deux 13 demi-sinusoïdes, et une fois sur deux 14.
J'ai lancé une petite simulation du phénomène. Si on considère une mesure par seconde, bien synchronisées avec les sinusoïdes du secteur, et qui moyennent bien la puissance sur la seconde, alors on aurait les mesures suivantes:


Autrement dit, alors que la puissance consommée moyenne par périodes de 270ms est à priori rigoureusement constante, et en supposant que les sondes aient une précision absolue, les mesures toutes les secondes varient dans une plage +/-8%. Soit 16% d'écart entre les valeurs extrêmes mesurées. 
Si on moyenne ces mesures sur 10 secondes (une vraie moyenne, pas un filtre RC sinon c'est pire), alors l'écart sur ces moyennes tombe à +/- 0.6%.  C'est déjà mieux. 

Mais vous voyez qu'on est obligé d'augmenter fortement le temps des mesures, et donc réduire la réactivité de la régulation, pour maintenir une précision correcte. 

On n'aurait pas ce problème si on pouvait garantir que la durée d'une mesure couvre un nombre entier de trains de sinus. Ce qui me semble-t-il est presque le cas pour le mode "trains de sinus": j'ai mesuré 990ms assez constant, pour un temps de mesure de 1s (Shelly) ou 2s (Linky). Mais visiblement pas pour le mode "multi-sinus". 

Ce qui est paradoxale: j'imagine que l'avantage recherché dans le "multi-sinus" était d'avoir une meilleure réactivité que pour le "train de sinus", alors qu'en fait c'est le contraire qu'on obtient, si on veut une bonne précision. 

En fait, si on pouvait garantir qu'on réalise la lecture des mesures de façon synchronisée avec la production de ces mesures, et que cette lecture se fait avec une retard minime par rapport à la durée des mesures, alors le fonctionnement optimal serait obtenu en ne prenant en compte que la nouvelle mesure et les paramètres de la période qui précède. Autrement dit, le système aurait un temps de réaction de la seconde (Shelly) ou 2s (Linky).  Bien entendu, la réalité est un peu différente, vu que les systèmes ne sont pas parfaits, mais j'ai l'intuition qu'on améliorerait grandement la réactivité de la régulation en allant dans ce sens. Ce sera en tous cas mon objectif d'essayer... quand j'aurai réussi à faire marcher mon routeur   . A noter aussi que ce mode "idéal" nécessiterait probablement de connaître la puissance de la charge gérée. En tous cas ce serait plus simple (on peut probablement bricoler pour l'éviter).