Besoin de conseils pour faire fonctionner mon routeur

[F1ATB]

Attention, vous faites une erreur dans le raisonnement autour du Multi-Sinus.

En début de programme, autour de la ligne  700, vous verrez que l'on calcule 2 tableaux de 101 valeurs d'ouverture du SSR ou Triac échelonnées par pas de 1% entre 0 et 100%.

Un tableau donne la durée de la Période du signal carré en sortie GPIO par pas de 10ms.
Le deuxième tableau donne la durée ON par pas de 10ms.
Le rapport ON/Période*100 correspond au temps d'ouverture souhaité par pas de 1% à 0.4% près.

Voici le tableau:

i=0  On=0  Total=20
i=1  On=1  Total=73
i=2  On=1  Total=43
i=3  On=1  Total=31
i=4  On=1  Total=23
i=5  On=1  Total=21
i=6  On=2  Total=32
i=7  On=2  Total=28
i=8  On=2  Total=24
i=9  On=2  Total=22
i=10  On=2  Total=20
i=11  On=3  Total=27
i=12  On=3  Total=25
i=13  On=3  Total=23
i=14  On=3  Total=21
i=15  On=4  Total=26
i=16  On=4  Total=25
i=17  On=4  Total=23
i=18  On=4  Total=22
i=19  On=4  Total=21
i=20  On=4  Total=20
i=21  On=6  Total=29
i=22  On=5  Total=23
i=23  On=6  Total=26
i=24  On=5  Total=21
i=25  On=6  Total=24
i=26  On=6  Total=23
i=27  On=6  Total=22
i=28  On=7  Total=25
i=29  On=9  Total=31
i=30  On=6  Total=20
i=31  On=8  Total=26
i=32  On=8  Total=25
i=33  On=7  Total=21
i=34  On=12  Total=35
i=35  On=8  Total=23
i=36  On=8  Total=22
i=37  On=10  Total=27
i=38  On=8  Total=21
i=39  On=9  Total=23
i=40  On=8  Total=20
i=41  On=11  Total=27
i=42  On=10  Total=24
i=43  On=9  Total=21
i=44  On=11  Total=25
i=45  On=13  Total=29
i=46  On=12  Total=26
i=47  On=14  Total=30
i=48  On=10  Total=21
i=49  On=18  Total=37
i=50  On=10  Total=20
i=51  On=19  Total=37
i=52  On=11  Total=21
i=53  On=16  Total=30
i=54  On=14  Total=26
i=55  On=16  Total=29
i=56  On=14  Total=25
i=57  On=12  Total=21
i=58  On=14  Total=24
i=59  On=16  Total=27
i=60  On=12  Total=20
i=61  On=14  Total=23
i=62  On=13  Total=21
i=63  On=17  Total=27
i=64  On=14  Total=22
i=65  On=15  Total=23
i=66  On=23  Total=35
i=67  On=14  Total=21
i=68  On=17  Total=25
i=69  On=18  Total=26
i=70  On=14  Total=20
i=71  On=22  Total=31
i=72  On=18  Total=25
i=73  On=16  Total=22
i=74  On=17  Total=23
i=75  On=18  Total=24
i=76  On=16  Total=21
i=77  On=20  Total=26
i=78  On=18  Total=23
i=79  On=23  Total=29
i=80  On=16  Total=20
i=81  On=17  Total=21
i=82  On=18  Total=22
i=83  On=19  Total=23
i=84  On=21  Total=25
i=85  On=22  Total=26
i=86  On=18  Total=21
i=87  On=20  Total=23
i=88  On=22  Total=25
i=89  On=24  Total=27
i=90  On=18  Total=20
i=91  On=20  Total=22
i=92  On=22  Total=24
i=93  On=26  Total=28
i=94  On=30  Total=32
i=95  On=20  Total=21
i=96  On=22  Total=23
i=97  On=30  Total=31
i=98  On=42  Total=43
i=99  On=72  Total=73
i=100  On=20  Total=20

La durée de la période du signal carré n'est pas la même suivant le pourcentage d'ouverture souhaité. Vous pouvez constater que la majorité des solutions à ce problème donne des périodes max entre 200 et 300ms. Ce qui permet à un multi-sinus de bien s'adapter à un Shelly qui fait la mesure de puissance sur 3 ou 400ms ( à mieux definir sur un banc de mesure). Dans le cas du Linky (qui nous facture) avec un temps de mesure de la puissance de 1s ou plus, on moyenne encore mieux.

Cordialement
André

[Jacques13]

Si je tente d'en tirer une conclusion, la période est variable en fonction du % de routage à effectuer.
i = taux
On = temps on
Total = temps du cycle

Avec i=99%, le cycle devient alors de 730ms et i=100% le cycle n'est plus que de 200ms

D'où le fait que j'avais du mal à synchroniser mon scope lors de mes mesures !!!

[F1ATB]

En effet pour le scope il faut figer le pourcentage pour mesurer la durée de la période.

[FastFrench]

D'accord merci pour ces précisions. 

Dans mes calculs, j'ai volontairement posé des hypothèses simplificatrices pour tenter de rendre l'analyse compréhensible. 

L'idée était d'illustrer que même quand les données à mesurer sont parfaitement stables (hypothèse très favorable à la régulation), le fait d'avoir une alternance de périodes à pleine puissance suivie de périodes à 0 introduit mathématiquement une erreur dans les mesures, d'autant plus que la durée de la mesure s'écarte d'un nombre entier de cycles complets.

Le fait que la période soit de durée variable complique l'analyse. De même, si on fait une hypothèse différente sur les temps de mesure du Shelly (à mon avis c'est très proche de la seconde, mais ce n'est qu'une hypothèse), les résultats numériques vont être différents (dans un sens ou dans l'autre). Mais sur le fond, le constat restera sensiblement le même. 

Et je pense qu'il faut essayer d'avoir un temps de réaction de plus court possible, pour que le système s'adapte aussi rapidement que possible aux changements d'ensoleillement ou de consommation de la maison. Et pour cela, avoir d'une part une lecture rapides des données du Shelly (ou autre) et d'autre part une synchronisation des lectures avec les changements de valeurs au niveau des mesures de puissance, tout ça va dans le sens de permettre d'espérer un système plus réactif (et donc réduire l'énergie injectée et l'énergie consommée).

[FastFrench]

Par rapport au sujet initial, j'ai bien avancé, mais quelle galère !
Je dois encore affiner les réglages, mais le routeur marche enfin. 


C'est un relevé en fin de journée, donc avec la production solaire qui décroit assez rapidement. Je suis bien avec une injection moyenne autour de 40W (seuil à -40W), et même si c'est encore assez irrégulier, on reste avec des écarts contenus (et une injection dans le ballon nettement supérieure à l'injection dans le réseau d'une part et à la consommation d'autre part)

En fait l'électronique et le câblage n'étaient pas vraiment en cause. Le problème, c'était les GPIO utilisés. 
En effet, j'utilisait le GPIO 5 pour commander le SSR, sachant que j'utilise un ESP32-CYD (sur lequel j'ai retiré la carte mémoire). 

Et c'est une très mauvaise idée en fait. Je déconseille fortement d'utiliser les GPIO de la carte mémoire pour commander le SSR (ou toute sortie importante). Pour les LED, à la rigueur. 
Je ne sais pas si c'est explicitement le code du routeur, un librairie, ou plus simplement le matériel, mais il y a une activité intrinsèque sur ces GPIO. 
Ca m'aura pris pas mal de temps à identifier ce problème, mais c'est en fait très simple à constater avec un oscillo (quand on sait quoi chercher). 
Je l'ai constaté très clairement pour les GPIO 5 et 23. 

La manip la plus simple pour le constater: sur un ESP32 CYD exposant les GPIO utilisés par le lecteur de cartes mémoires, paramétrez une action ON/OFF à ON sur le GPIO 22. Regardez le signal correspondant: +3.3V constant au niveau du GPIO. Normal. 
Maintenant faîtes la même manip sur le GPIO 5. 
Et là vous allez voir que le signal est forcé à 0 deux fois par seconde. 



Par contre, si on force la sortie à 0 (constant), là le signal correspond bien: 


Et en utilisation multi-sinus et train de sinus, on a encore ces retour forcés à 0 plusieurs fois par seconde, ce qui perturbe fortement la régulation (d'où les problèmes récurrents que j'avais). 

De façon similaire, le GPIO 23 est aussi perturbé pas des signaux non voulus. 
D'ailleurs, il semble même y avoir une communication entre le GPIO 22 et le GPIO 23. 


Ca donne ça (en haut le GPIO 22, correct avec 10% de fermeture. Et en bas, le GPIO 23, qui sans l'action déclenchée sur le GPIO 22 serait au repos). 

Impressionnant, non ?! 

Et donc, la solution ? 

Gardez le lecteur de CM en place, et n'utilisez l'ESP 32 - CYD que si vous pouvez vous contenter des GPIO qu'il expose. 
Ca vous fera gagner du temps, et vous évitera la furieuse envie de tout balancer par la fenêtre> !

@F1ATB : je pense qu'il faudrait supprimer les GPIO 5 et 23 de la liste des choix possibles associés aux actions dans le cas d'une carte ESP32 CYD.  Je n'ai pas essayé avec les GPIO 18 et 19 (je les utilise pour les LEDs, qui me semblent un peu erratiques à vrai dire). 

Remarques:
  - si quelqu'un dispose d'un ESP32 CYD avec le lecteur de cartes mémoires retiré et idéalement d'un oscilloscope, peut-il faire le test de son côté pour confirmer le problème ? 
  - si on pouvait trouver qu'est-ce qui change ainsi l'état de ces GPIO, ce serait pas mal de supprimer le problème. J'imagine qu'on peut commencer par une application toute simple qui met juste les GPIO 5 et 23 à 1. Puis intégrer les bibliothèques du routeur une à une. Pour voir à quel moment le problème apparait. 


Accessoirement, avec deux GPIO en moins, je me trouve un peu coincé. J'avais prévu d'asservir ma P.A.C. avec le routeur, et prévu un GPIO que je n'ai plus pour ça.