Mode de régulation plus réactif ?

[jannikd]

J'ai des radiateurs électriques avec une régulation électronique, ce qui fait que ma consommation peut être très "haché" (plusieurs pics par minute, avec des différences entre les hauts et les bas de parfois plus que 1500W). Le routeur a du mal à suivre ces variations fortes et rapides : Si je mets une régulation lente, la variation est trop lente pour suivre jusqu'au bout et en plus en décalage avec les oscillations de la consommation. Si je mets une régulation rapide ça devient instable et j'ai des grosses oscillations bizarres.

Pour avoir une régulation plus rapide mais quand même stable, pourquoi pas ajouter un autre mode de régulation qui calcule l'ouverture en fonction de la puissance branché ?
Je m'explique: la resistance de mon ballon fait 1800W. S'il y a 900W disponible, je dois ouvrir à 50%. A chaque nouvelle mesure, je calcule la en fonction de l'ouverture actuelle. Par exemple, j'ai encore 180W disponible, l'ouverture actuelle est 50%, donc en total il y a 1800W*50%+180W = 1080W, donc prochaine ouverture à 1080/1800 = 60%, etc.

Ce calcul nécessite uniquement de connaitre la puissance branché (que l'utilisateur pourrait renseigner), pas besoin d'une boucle de régulation. Il devrait donc être très reactif, mais quand même stable (tant que la puissance utilisé dans le calcul correspond à la puissance branché).

En utilisant une mesure de la consommation effective du ballon (par exemple un tore de mesure branché derrière le triac/ssr) on pourrait même ne pas avoir besoin de renseigner la puissance branché, le calcul ci-dessus pourrait se faire uniquement avec les valeurs mesurées.

[jannikd]

Non ce n'est pas en boucle ouverte car à chaque instant je recalcule la puissance disponible en fonction de l'injection ET de l'ouverture actuelle du triac. Si la production augmente ou la consommation baisse, l'injection augmente et l'ouverture est mise à jour (comme dans mon exemple ou on passait de 50% à 60% pour une injection de 180W). De meme, si la production baisse ou la consommation augmente, l'injection va devenir negative, et l'ouverture du triac va baisser d'autant.

[Jacques13]

En réalité c'est le curseur de routage qui renseigne le routeur sur la puissance de charge. Il fait exactement le travail d'un tore de mesure qui serait plus complexe à installer et sans véritable intérêt vu que la charge est fixe.
Ce curseur aurait pu être gradué en W eu lieux de % mais selon les installations cette valeur devant s'adapter au contexte, le meilleur réglage pourrait alors diverger de la véritable puissance de la charge et provoquer une certaine confusion pour l'utilisateur.

[glu3]

J'ai des radiateurs électriques avec une régulation électronique, ce qui fait que ma consommation peut être très "haché" (plusieurs pics par minute, avec des différences entre les hauts et les bas de parfois plus que 1500W). Le routeur a du mal à suivre ces variations fortes et rapides : Si je mets une régulation lente, la variation est trop lente pour suivre jusqu'au bout et en plus en décalage avec les oscillations de la consommation. Si je mets une régulation rapide ça devient instable et j'ai des grosses oscillations bizarres.

Pour avoir une régulation plus rapide mais quand même stable, pourquoi pas ajouter un autre mode de régulation qui calcule l'ouverture en fonction de la puissance branché ?
Je m'explique: la resistance de mon ballon fait 1800W. S'il y a 900W disponible, je dois ouvrir à 50%. A chaque nouvelle mesure, je calcule la en fonction de l'ouverture actuelle. Par exemple, j'ai encore 180W disponible, l'ouverture actuelle est 50%, donc en total il y a 1800W*50%+180W = 1080W, donc prochaine ouverture à 1080/1800 = 60%, etc.

Ce calcul nécessite uniquement de connaitre la puissance branché (que l'utilisateur pourrait renseigner), pas besoin d'une boucle de régulation. Il devrait donc être très reactif, mais quand même stable (tant que la puissance utilisé dans le calcul correspond à la puissance branché).

En utilisant une mesure de la consommation effective du ballon (par exemple un tore de mesure branché derrière le triac/ssr) on pourrait même ne pas avoir besoin de renseigner la puissance branché, le calcul ci-dessus pourrait se faire uniquement avec les valeurs mesurées.

@jannikd
Bonjour,
Vos radiateurs son peut-être équipés de fils pilote.
Si tel est le cas, pourquoi ne pas les piloter chacun leur tour de "délestage à on" (esp32 avec relais) sur une période à définir, (5 radias/1 heure, 12mn chacun) cela permettrai éventuellement de stabiliser l'ampérage et donc les oscillations du router.
Ceci n'est qu'une idée, par contre je ne saurais la programmer mais cela m'intéresse j'ai une dizaine de radiateurs.
Bonne journée 
@ + Michel 

[59jag]

j ai eu la même idée et je l'ai intégrer dans le code pour le multisinus,  j ai modifier  GestionOverproduction()  
pour l' activer j ai juste gpio4 a mettre a on .
j ai pas vraiment appronfondi car je suis sur ma version a distance avec firebase.
demain je ferai des screens pour voir la différence entre les deux régulations .  

Code :

  switch (Actif[i]) {                                                 //valeur en RAM du Mode de regulation
        case 1:                                                           //Decoupe Sinus pour Triac ou On/Off pour relais
          if (i > 0) LesActions[i].RelaisOn();
          StockMessage("relai On" + LesActions[i].Titre);
          break;
        case 2:  // Multi Sinus
         //#ifdef Active_Regul
           static int pdirectprec = 0;                                     //59jag changement en cours avec gpio4
           if (digitalRead(4) == 1){                                       //59jag   actif si gpio 4 = 1 
            int pdirect=pdirectprec+(( Puissance - SeuilPw)/16);           //16 pour 1600w/100   1%=16w(chauffeeau de 1600)
            if(pdirect>100)pdirect=100;                                    //59jag
            if(pdirect<0)pdirect=0;                                        //59jag       
            if (Type_En_Cours == 2)pdirect=100;                            //si sur ON alors 100
            PulseOn[i]=tabPulseSinusOn[pdirect];                           //59jag
            PulseTotal[i]=tabPulseSinusTotal[pdirect];                     //59jag
            pdirectprec = pdirect;
          }else{
         //#endif
            PulseOn[i] = tabPulseSinusOn[100 - Retard[i]];
            PulseTotal[i] = tabPulseSinusTotal[100 - Retard[i]];
          }
          break;
        case 3:  // Train de Sinus
          PulseOn[i] = 100 - Retard[i];
          PulseTotal[i] = 99;  //Nombre impair pour éviter courant continu
          break;
      }

[59jag]

Coucou S9Jag as tu pu comparer les modes de regulation ?

je test ce week-end quand je suis chez moi  car la dernière fois j ai vue aucune différence , a ce demander si ca changer de mode.

[Christof19]

J'ai des radiateurs électriques avec une régulation électronique, ce qui fait que ma consommation peut être très "haché" (plusieurs pics par minute, avec des différences entre les hauts et les bas de parfois plus que 1500W). Le routeur a du mal à suivre ces variations fortes et rapides : Si je mets une régulation lente, la variation est trop lente pour suivre jusqu'au bout et en plus en décalage avec les oscillations de la consommation. Si je mets une régulation rapide ça devient instable et j'ai des grosses oscillations bizarres.

Pour avoir une régulation plus rapide mais quand même stable, pourquoi pas ajouter un autre mode de régulation qui calcule l'ouverture en fonction de la puissance branché ?
Je m'explique: la resistance de mon ballon fait 1800W. S'il y a 900W disponible, je dois ouvrir à 50%. A chaque nouvelle mesure, je calcule la en fonction de l'ouverture actuelle. Par exemple, j'ai encore 180W disponible, l'ouverture actuelle est 50%, donc en total il y a 1800W*50%+180W = 1080W, donc prochaine ouverture à 1080/1800 = 60%, etc.

Ce calcul nécessite uniquement de connaitre la puissance branché (que l'utilisateur pourrait renseigner), pas besoin d'une boucle de régulation. Il devrait donc être très reactif, mais quand même stable (tant que la puissance utilisé dans le calcul correspond à la puissance branché).

En utilisant une mesure de la consommation effective du ballon (par exemple un tore de mesure branché derrière le triac/ssr) on pourrait même ne pas avoir besoin de renseigner la puissance branché, le calcul ci-dessus pourrait se faire uniquement avec les valeurs mesurées.

Bonsoir,
Je pense avoir les mêmes radiateurs (2) dans 2 chambres et effectivement, de beaux pics de conso périodiques à 1200 w au dessus du reste. Ton raisonnement pourrait fonctionner à la condition d'echantillonner de manière asynchrone avec les pics de conso. Peut-être, c'est paradoxal, mais faire un moyennage glissant sur 30 ou 40s (paramétrable) serait à tester. Vu l'inertie thermique de la chauffe d'un fluide, inutile d'être hyper réactif. Je serais curieux de voir, sur une semaine à conditions météo équivalente, les écarts de gain entre un routage basé sur la TIC linky et un asservissement plus dynamique.
Cela est sûrement à adapter en fonction des consommateurs de chacun.
Bonne fin de journée.
Christophe

[Ludovic35]

J'avais essayé ce genre de stratégie pour accélérer la régulation; ça ne fonctionne pas. Le système oscille avec une lecture depuis la TIC à 2s.
Il est important de ne modifier que lentement le % d'ouverture du SSR car les systèmes de mesure sont très variables dans la précision. Par exemple, les Shelly échantillonnent à 200ms alors que le multisinus fait varier sur une base de 400ms. La mesure de la consommation est donc très bruitée et il faut lisser fortement pour en extraire la tendance.
C'est exactement ce qui est fait dans le code actuel.

Il y a peut-être une chance que cela fonctionne avec une sonde UxI en local et un mode de découpe de sinus en local; dans tous les autres cas, cela va osciller fortement.

[jannikd]

Merci pour vos retours !

Il est clair que ce mode n'a du sens qu'avec une mesure de la consommation précise et fréquente. 2s me parait trop long, perso je suis sur enphase qui est plutôt précis et qu'on pourrait échantillonner très fréquemment, car a chaque requête on a la valeur courante. A priori actuellement le routeur échantillonne tous les 400ms environ avec enphase. D'ailleurs il y a peut-être un soucis en cas de régulation multi-sinus ou train de sinus comme disait Ludovic35 : si on mesure pendant ou en dehors des trains de sinus, on n'aura pas le même résultat, et il faudra pas faire le même calcul...bref, je pense qu'il va falloir creuser dans le code pour comprendre.

En ce qui concerne la stabilité, je ne vois rien sur le lien qui dirait que ça doit osciller (en supposant que les mesures sont correctes, voir remarque juste avant). J'ai fait un petit fichier excel pour simuler l'approche. Le seul cas où il y a des fortes oscillations est le cas ou il y a une grosse différence entre la puissance réelle et la puissance utilisé pour le calcul. Autre cas potentiellement problématique : si les variations sont plus rapides que la boucle : dans ce cas on "court derrière" sans l'attraper, mais il y a pas non plus d'instabilité. Dans mon cas, avec une boucle tous les 200-300ms et des pics tous les 30/40 secondes, ça ne devrait pas être le cas (boucle 100x fois plus rapide que la variation!).

[H3rv3]

j ai eu la même idée et je l'ai intégrer dans le code pour le multisinus,  j ai modifier  GestionOverproduction()  
pour l' activer j ai juste gpio4 a mettre a on .
j ai pas vraiment appronfondi car je suis sur ma version a distance avec firebase.
demain je ferai des screens pour voir la différence entre les deux régulations .  

Code :

  switch (Actif[i]) {                                                 //valeur en RAM du Mode de regulation
        case 1:                                                           //Decoupe Sinus pour Triac ou On/Off pour relais
          if (i > 0) LesActions[i].RelaisOn();
          StockMessage("relai On" + LesActions[i].Titre);
          break;
        case 2:  // Multi Sinus
         //#ifdef Active_Regul
           static int pdirectprec = 0;                                     //59jag changement en cours avec gpio4
           if (digitalRead(4) == 1){                                       //59jag   actif si gpio 4 = 1 
            int pdirect=pdirectprec+(( Puissance - SeuilPw)/16);           //16 pour 1600w/100   1%=16w(chauffeeau de 1600)
            if(pdirect>100)pdirect=100;                                    //59jag
            if(pdirect<0)pdirect=0;                                        //59jag      
            if (Type_En_Cours == 2)pdirect=100;                            //si sur ON alors 100
            PulseOn[i]=tabPulseSinusOn[pdirect];                           //59jag
            PulseTotal[i]=tabPulseSinusTotal[pdirect];                     //59jag
            pdirectprec = pdirect;
          }else{
         //#endif
            PulseOn[i] = tabPulseSinusOn[100 - Retard[i]];
            PulseTotal[i] = tabPulseSinusTotal[100 - Retard[i]];
          }
          break;
        case 3:  // Train de Sinus
          PulseOn[i] = 100 - Retard[i];
          PulseTotal[i] = 99;  //Nombre impair pour éviter courant continu
          break;
      }

Est-ce vraiment different de ce qui est fait actuellement?
RetardF[i] = RetardF[i] + (Puissance - SeuilPw) * GainBoucle / 10000.0;  // Gain de boucle de l'asservissement

Le GainBoucle est la valeur du curseur donc changeable de 1 a 100, donc un coefficient variant de 1/10000 a 1/100. Il doit y avoir une raison pour avoir un coefficient si petit (frequence de repetition de la boucle?), 16 ca risque d'etre rapide comme reaction!
Comme dit plus haut, le curseur est l'equivalent du choix de la puissance de la charge.

Dans le cas des regulateurs PID, celui ci serait uniquement I (on integre l'erreur pour charger l'actionneur jusqu'a arriver a une erreur 0). Peut etre qu'on pourait ajouter un peu de commande proportionelle (P) mais avec les temps de reponse des mesures ca a beacooup de chance de partir en grosses oscilations. Meme les appareils de marque ont besoin de temps pour reagir.

Franchement ca me parait pas mal comme c'est, il faut jouer avec le GainBoucle d'abord.
Perso, j'ai un systeme a batterie et si j'ai le four ou la machine a cafe en route, quand le termostat coupe, j'ai une grosse injection sur le reseau pendant un petit moment et a l'inverse quand il faut chauffer je tire sur le reseau le temps que la batterie reagisse.

Je ne sais pas comment c'est avec EDF, jesuis en Espagne et pour les contrats avec rachat d'excedents, la valeur de puissance retenue pour les factures est le bilan des exportations et des importations pour chaque heure donc tant que les variations sont centrees, le bilan sur la note est nul.

Mon chauffe-eau est de 1500W et j'ai 5 en GainBoucle et un seuil de -50W (a cause de la batterie qui elle a un seuil de 0W dans l'inverseur, a voir si je peux baisser ca a 20 ou 30W). Je suis content avec ca.

Hervé