C’est ce que je pensais jusqu’à l’an dernier lorsque j’ai découvert que le plugin thermostat avait un mode PID qui permet donc de calculer une puissance que l’on applique à la température d’eau comme l’a justement compris ParkerLewis.
Non, ce n’est pas comme cela que j’ai fait. Jouer à la fois sur les têtes thermostatiques et la température de l’eau me semble contre-productif. Le plugin Thermostat ne peut influencer qu’un seul paramètre et dans mon cas c’est la température de l’eau.
Tu as raison, je n’avais jamais pensé à cette optimisation. Je vais tester ça.
Petite précision cependant : comme indiqué dans le tuto, le plugin Thermostat est configuré pour ne jamais chauffer en-dessous de 23% de puissance calculé, donc le cas n’arrive jamais. 23% = 20 degrés, et à 20 degrés ou en-dessous de température d’eau, la chaudière ne chauffe pas mais fait circuler l’eau.
Attends, il y a deux choses qui me perturbent dans ce que tu dis. (et j’ai l’impression qu’elles sont liées)
Si on se fie à la doc du plugin thermostat, le mode temporel avec PID reste du on/off, en tout cas si on utilise le plugin « normalement » (ce qui n’est pas le cas de ce que tu fais, toi in fine tu as bien une commande linéaire, mais c’est utile de bien voir que le plug in lui, il est pensé pour faire du on/off, et il pense faire du on/off).
Le PID prend en entrée l’écart entre la température mesurée et la consigne (on parle ici d’une température de pièce). En sortie, et en fonction des paramètres qu’il a appris pour régler son asservissement, il pond une puissance de chauffe comprise entre 0 et 1 (ou 0 et 100 peu importe).
Mais ensuite, voici comment il cherche à l’appliquer. Par exemple, pour un cycle de 30 min, avec une sortie de PID à 60% :
au début du cycle, il va lancer 1 seule fois l’Action définie dans le champ « Pour chauffer je dois ». C’est censé être, et il s’attend à ce que ce soit, paramétré pour que l’action en question mette le chauffage en marche (une commande « on »).
une fois durée_du_cycle*puissance minutes écoulées, ici 30min*60% = 18min écoulées, il va lancer 1 seule fois l’Action définie dans le champ « Pour tout arrêter je dois ». C’est censé être, et il s’attend à ce que ce soit, paramétré pour que l’action en question coupe la chaudière (une commande « off »).
Ainsi, en moyenne sur un « cycle », il respecte la puissance commandée (sortant du PID).
Ca c’est son fonctionnement « normal », on va dire. Tu es d’accord là-dessus ? C’est directement ce qui est décrit dans la doc du plugin en tout cas.
Par contre, ce que tu as mis en place, c’est :
prendre la sortie du PID, qui est un %age de puissance - ça ça ne change pas.
mais ensuite, et là est le point important, au lieu de lui donner des scripts mettant en marche à fond ou coupant totalement (le cas d’usage normal, attendu, tout ce que tu veux, et donc obtenir des cycles avec alternances de on/off) on a un appel de ERS.py, qui lui va prendre cette puissance, la convertir en une température d’eau, et l’envoyer au récepteur radio ERS comme ce dernier l’attend, et qui lui va l’appliquer de façon constante (sans interruption).
Et le tour est joué : il n’y a plus de on/off sur la chaudière, contrairement au fonctionnement « normal » du plugin. Mais le plugin lui n’en sait rien !
C’est très important de bien avoir en tête qu’il n’en sait rien, pour en conséquence tout penser en faisant attention à ce que cette différence majeure ne perturbe pas ou le moins possible tout ce qu’il peut y avoir sous le capot du plugin et donc son bon comportement.
En l’occurence, il y a selon moi au moins les points d’importance suivants à vérifier :
s’assurer que, lors de la commande « arrêt », il n’écrase pas temporairement la variable « Puissance » qui sort du PID par une variable valant 0 par exemple (ou autre). Il serait tout à fait susceptible de le faire, vu que pour lui, c’est censé être à l’arrêt, donc il pourrait s’autoriser à faire n’importe quoi avec cette variable pendant ce %age du temps du cycle (et donc sur la chaudière )
Pour se prémunir de tout risque à ce niveau, je suggérerais de laisser vide l’Action « Pour tout arrêter je dois », ou s’il faut impérativement en mettre une, mettre un script vide ou qui ne fait rien. Même si aujourd’hui ça marche sans faire ça, tu n’es pas à l’abri à n’importe quelle maj ou release que ce comportement change et de façon non documentée. Et fonctionnellement, ça ne changera rien : ta chaudière elle suivra toujours sa consigne connue.
s’assurer qu’in fine, la chaudière travaille bien au %age de puissance attendu / demandé en sortie du PID. Si c’est le cas, on respecte au mieux les hypothèses de modélisation internes (cachées) du plugin qu’il utilise fatalement notamment pour auto-apprendre et même pour commander (la commande / sortie PID est nécessairement pensée pour être respectée, ie que la puissance effective en sortie sera bien a minima proportionnelle à la consigne produite).
je dirais qu’il est probablement préférable de paramétrer des cycles « pas trop longs ». Pourquoi ? parce que le plug in regarde ce qui se passe et essaie d’apprendre l’inertie de l’installation, etc. Or le pb, c’est que lui il croit vraiment que sur x% du temps il était à fond et que sur le complémentaire il était à 0. S’il essaie de se servir de ça pour estimer l’inertie de l’installation, ça va le perturber, parce qu’il s’attend donc à voir la réponse de ton installation (chaudière + maison) à une variation brutale de consigne à la montée (passage attendu en « on ») comme à la descente (passage attendu en « off »). Or toi tu n’as ni montée ni descente donc il ne verra rien… En gros j’ai l’impression qu’il sera biaisé pour conclure que l’inertie de ton installation est supérieure au temps de cycle (qui est la limite haute qu’il pourrait constater dans le cas « normal » qu’il attend où il y aurait eu du on/off). L’intérêt vraisemblable de mettre un cycle pas trop long c’est qu’au moins le comportement qu’il observera sera moins aberrant par rapport à ce qu’il est susceptible de supposer.
Ben, comment ton plugin Thermostat détermine la température « ambiante » à laquelle il doit rapporter son scénario ?
(Désolé si ce que je dis par la suite est une évidence, mais comme je n’ai pas compris ta réponse je préfère vérifier qu’on est d’accord sur les principes)
Le principe c’est qu’en entrée de PID il fait la différence entre la température ambiante souhaitée et la température ambiante courante. Ce delta de température passe ensuite dans le « bête » correcteur proportionnel (le PID) et en ressort la consigne de puissance (je dis bête car un PID a une structure très simple, mais la valeur ajoutée ici c’est qu’il a été bien réglé par l’apprentissage).
Bref il a au moins besoin de deux mesures, qui par défaut doivent être une température ambiante souhaitée et une obtenue / mesurée. C’est ce que tu as chez toi ?
Je pensais qu’il saurait prendre les mesures de chaque tête, pour chacune dire si la pièce est à la bonne température ou pas, et générer une entrée de PID en conséquence, par ex, version ultra-naïve mais juste pour donner un exemple : moyenne des températures mesurées dans chaque pièce d’un côté, moyenne des températures souhaitées dans chaque pièce de l’autre. Ca sortirait bien une puissance qui ressemble à la consigne optimale. Et derrière les têtes thermostatiques, étant thermostatiques, se ferment d’elles-mêmes naturellement là où la t° ambiante est atteinte, restent ouvertes là où elle ne l’est pas, et l’eau chaude va bien là où il faut.
Oui, j’avais vu Néanmoins je pense que pas idéal pour le PID. La sortie étant pensée pour être un %age de puissance commandée, quand il sort 23% (pour reprendre cette valeur), c’est qu’il a déterminé que ta chaudière devrait tourner à 23% de puissance. Donc idéalement tu ferais tourner la chaudière à 23% de puissance.
Maintenant, si on est sûrs que l’ERS attend une température d’eau en entrée, alors il faut essayer de lui commander la température d’eau qui se rapproche le plus d’une puissance chaudière à 23%.
(D’ailleurs, on est sûrs que c’est bien une tempréature d’eau qu’il y a dans la trame ERS ? ça peut pas être directement une puissance par hasard ? ca simplifierait )
Il le fait, mais ce n’est pas grave, lorsque le PID indique une puissance de 0, il faut arrêter de chauffer.
Tu te trompes sur le fonctionnement du plugin Thermostat : il s’agit d’un algorithme PID, le résultat du PID (en pourcent comme tu l’indiques) donne le temps de chauffe qu’il doit appliquer.
Donc dans mon cas, utiliser le plugin Thermostat revient juste à utiliser son algorithme PID, puis j’ai modifié sa configuration pour que le mode temporel soit en réalité un mode de puissance. Le cron de répétition de la commande ERS.py est configuré toutes les 5 minutes, donc la puissance calculée par le plugin thermostat est transmise toutes les 5 minutes à la chaudière.
Via des capteurs de température installés dans la maison. Les têtes thermostatiques sont ouvertes en grand car ce ne sont pas elles qui régulent la température dans ma maison mais le plugin thermostat.
Le plugin thermostat se base sur la moyenne des capteurs de température de ma maison.
Je suis 100% d’accord que c’est bien ce que le plugin attend, et c’est ce que je décris est censé se passer quand on l’utilise « normalement » (comme il est prévu, ce que je sais n’est pas le cas ici) : PWM sur un cycle, il lance la commande qu’on lui a dit être « on » et la laisse la proportion donnée par le PID, puis envoie la commande qu’on lui a dit être « off » sur le reste du cycle.
Sur un cycle, il y a eu « puissance_calculée_par_le_PID » du temps un fonctionnement à 100%, et le reste du temps une chauffe à 0%.
En moyenne ça fait la puissance demandée.
Oui je suis 100% d’accord.
Prenons un scénario exemple si tu le veux bien pour identifier là où ne serions pas d’accord.
Scénario :
On est en début de cycle mettons c=60min.
Le PID trouve mettons p=40% de puissance moyenne à commander.
A t=0, le plugin Thermostat lance l’action « Pour chauffer je dois ».
Dans un fonctionnement « classique », celle-ci est (doit être) configurée pour mettre la chaudière à 100% (faire « on »).
Dans notre cas particulier, comme le moyen de commander la chaudière autrement qu’en tout ou rien a été trouvé, on essaie d’en profiter, et donc dans l’action « Pour chauffer je dois », on met un appel à ERS.py. ERS.py est lui codé pour prendre p en entrée et va faire en sorte que la chaudière se mette aussi en marche, mais à 40% et non à 100%.
Donc la chaudière passe à 40% (et non 100% comme « attendu » par le plugin, mais c’est pas grave. Ca peut être gênant d’un point de vue estimation des paramètres / auto-apprentissage, mais ce n’est pas le point que je souhaite soulever ici).
A t=p*c=40%*60min=24 min, le plugin Thermostat lance l’action « Pour tout arrêter je dois ».
Dans un fonctionnement « classique », celle-ci est (doit être) configurée pour éteindre la chaudière (faire « off »). Noter qu’à cet instant, cette action est ici totalement indépendante de la valeur informatique qui se trouve dans la variable « puissance » : la variable « puissance » n’a servi qu’à déterminer l’heure de lancement de l’action.
Dans notre cas particulier, il ne faut par contre surtout pas changer quoi que ce soit et maintenir les choses en l’état : la chaudière doit rester à 40%, pour que la puissance moyenne sur l’ensemble du cycle soit bien de 40%.
Ne rien mettre dans l’action « Pour tout arrêter je dois », ou mettre un script vide, fait donc ce qu’il faut.
Faire un nouvel appel à ERS.py comporte par contre un risque : puisque ce nouvel appel fait de nouveau usage de la variable informatique « puissance », pour que ça continue à faire du 40%, il faut être certain que la variable « puissance » n’a pas été écrasée par le plugin - ou utilisée temporairement pour stocker autre chose par exemple, ou remise à 0, ou quoi que ce soit d’autre.
Si le contenu informatique de cette variable a été remis à 0 par exemple (pour une raison x ou y interne au plugin), alors un appel de ERS.py à ce moment irait éteindre la chaudière pour toute la fin du cycle, ce qui est totalement contraire à ce qu’on souhaite faire dans notre cas (maintenir la chaudière à une valeur constante égale à la sortie du PID).
Et pire encore si c’est autre chose que 0.
Et ça ça peut arriver puisque du point de vue du plugin, cette variable n’est pas censée être utilisée par l’action lancée à cet instant (qui est censée être un « off »). Les développeurs pourraient tout à fait « jouer »/« utiliser » la variable informatique « puissance » pour en fait contenir complètement autre chose sur cette portion du cycle sans que ça n’affecte aucun utilisateur qui utilise le plugin « comme pensé / attendu » (en fonctionment on/off).
D’où mon point : dans l’action définie dans le champ « Pour tout arrêter je dois », il est intrinsèquement risqué d’utiliser les valeurs courantes de la variable « puissance », car ces valeurs pourraient (pourraient) sur cette section du cycle se transformer en n’importe quoi. Et même si aujourd’hui il s’avère que le plug-in ne l’altère pas, ou qu’elle reste « physique » (par exemple, éventuellement mise à jour mais en conservant son sens de puissance idéale), une version ultérieure du plug-in pourrait tout à fait changer ça sans prévenir, puisqu’aucun utilisateur utilisant « normalement », « comme attendu » le plugin ne verrait de différence.
Je suggèrerais donc pour l’action que le plugin appelle « Pour tout arrêter je dois » :
soit de mettre un script vide,
soit de répéter ERS.py, mais en prenant soin d’utiliser une copie stockée de la variable « puissance », copie datant / uniquement mise à jour lors de l’action « pour lancer le chauffage » (là où elle sera toujours forcément valide), si c’est possible.
La 2ème version a l’avantage de ne pas laisser la chaudière sans répétition commande pendant la durée c*(1-p) (ce qui peut ou pas la gêner, je ne sais pas). Il est aussi possible de faire du cron, mais dans tous les cas, avec la même logique de protection sur la variable utilisée en entrée.
ça y est, j’ai enfin compris ta remarque concernant l’arrêt et la puissance à 0. Merci d’avoir pris le temps de rédiger un exemple.
Après réflexion, le cas que tu décris n’existe pas car j’ai coché la case " Limite les cycles marche/arrêt incessants (pellet, gaz, fioul) et PID" du plugin Thermostat. Comme indiqué dans la documentation et confirmé dans ce fil de discussion Tutoriel | Plugin thermostat pour poêle a granulés connecté. La conséquence de cette option est de ne pas provoquer d’arrêt en cours de cycle et d’avoir toujours la bonne puissance sur tout le long du cycle.
Dans ce cas, effectivement le fonctionnement du plugin ne sera a priori pas celui précédemment décrit (alternance des actions « pour chauffer je dois » et « pour arrêter je dois »).
La doc officielle est bien succincte / pas claire sur ce qui se passe précisément dans ce cas…
Limite les cycles marche/arrêt incessants (pellet, gaz, fioul) et PID : Cette option permet de faire de la régulation avec différents niveaux de chauffe. Le retour de la puissance du prochain cycle doit donner la nouvelle consigne de niveau de chauffe à l’appareil de chauffage. Les cycles se terminent à 100%, il faut donc avoir un temps de cycle court.
« Le retour de la puissance du prochain cycle » : cette formulation me laisse ultra-perplexe. C’est juste la puissance calculée au prochain cycle ? Pourquoi cette formulation bizarre ?
« Les cycles se terminent à 100%, il faut donc avoir un temps de cycle court ». Hein ? Qu’est-ce que ça veut dire, « les cycles se terminent à 100% » ? A la fin du cycle, la commande est de 100% de puissance ? Je n’arrive pas à voir un autre sens à cette proposition, surtout couplée à la seconde - l’importance d’avoir un cycle court. De cette phrase, je déduirais que dans ce mode, la variable puissance monte progressivement jusqu’à 100% au cours du cycle, d’où la deuxième moitié qui dit « faites des cycles courts, de façon à ce que l’alternance soit assez rapide ».
Je trouve ça très surprenant comme fonctionnement, et je suis tout à fait prêt à croire que c’est pas ça tellement ça me semble un non-sens de faire ça, mais je ne fais qu’essayer de comprendre ce que raconte la doc et je ne vois pas comment l’interpréter autrement.
Et en tout cas ce serait bien de savoir in fine ce qui se passe dans un cycle : au début du cycle, j’imagine bien qu’il déclenche une action « Pour chauffer je dois », mais ensuite ? Est-ce qu’il en renvoie une de temps en temps (hors cron de répétion j’entends) pendant le cycle ? Et du coup il ne déclenche jamais (sauf éventuellement défaut / erreur / cas spécifique) l’action « Pour tout arrêter je dois » ?
Aurais-tu par hasard sur un cycle nominal un log des actions déclenchées et un relevé, par exemple toutes les minutes au cours d’un de tes cycles, de la variable puissance, pour valider ce qui se passe concrètement ? (Et/ou as-tu l’explication du sens de cette phrase…)
Au-delà de ça je pense que je commence à avoir assez dérisqué le sujet pour au moins lancer la première étape de changer une dizaine de vannes et d’installation des têtes
Dans le log en question il n’y a qu’un cycle de chauffe donc pas facile de tirer des conclusions.
Néanmoins :
on constate que « Cycle duration » (8.1375) vaut « Power calcul » (54.25) multiplié par 15 minutes. Tu as configuré avec 15 minutes dans le plugin ? Dans ce cas, « cycle duration » serait en fonctionnement tout ou rien la durée où il serait censé chauffer à 100%. Ici, si on suppose que la case « Limite les cycles marche/arrêt incessants (pellet, gaz, fioul) et PID » supprime bien cette notion d’alternance tout ou rien ça ne devrait pas avoir de sens physique, et idéalement du coup il n’y aurait pas cet affichage. Mais le plugin peut tout à fait « par négligence » quand même calculer cette valeur et la sortir même si en fait il l’ignore.
On voit bien la délcaration d’une « Action chauffage », ok. On voit bien le cron de 5 min que tu avais mis. je suis par contre un peu surpris que la première semble dédoublée, à 13:15:06 et 13:15:09 (4s d’écart). Je ne comprends pas bien pourquoi il y en a 2. Bon…
A l’inverse, on on ne voit pas d’« Action stop » sur ce cycle, donc vraisemblablement pas d’action « Pour tout arrêter je dois » (ce qui est espéré / attendu si on n’est effectivement plus en tout ou rien).
Donc à ce stade tout semble coller sur le 1er cycle du log (de 13h15 à 13h29m59s).
Ensuite ce sont des cycles vides (sans besoin de chauffage). Ils ont l’air ok, il y a bien uniquement de l’action stop (avec aussi cron de 5 min). Il y a un enchaînement « smart schedule qui s’active ; smart schedule qui constate que pas besoin de smart schedule ; cycle calculé sans smart schedule ». Ca ok, c’est logique si pas besoin de chauffer. Mais je vois cet enchaînement 2 fois, là encore.
Bref ça semble être bien cohérent avec ce qu’il faudrait. Le seul truc étonnant, c’est qu’il semble y avoir une duplication douteuse.
5h59 et 6h14 sont liés aux cycles de 15 minutes.
6h17 correspond au smart start qui anticipe la consigne de 7h (heure de mon lever).
Certes, cela fait beaucoup d’appels à la chaudière, mais il vaut mieux trop d’appels que pas assez.
@ChristopheHD
Bonjour,
J’ai également une chaudière Frisquet Bicérame basse température et le thermostat de commande Eco Radio Systeme.
J’ai commencé en suivant ta documentation et déjà je suis bloqué sur la récupération de l’identifiant du Thermostat. J’ai ceci
J’ai refait la manip, c’est a dire la compil et le téléversement.
Tout s’est bien passé mais quand j’ouvre le moniteur série et que je change de consigne sur le thermostat je n’ai rien. Alors que tout a l’heure avec le firmware officiel Rflink je recevais les trames que je t’ai envoyé.
C’est ce que je regardais. Et je ne vois pas bien comment le savoir.
Je l’ai acheté d’occasion.
C’est peut être un 433.920 Mhz
As tu une idée pour le verifier ?
)
Néanmoins je pense que pas idéal pour le PID. La sortie étant pensée pour être un %age de puissance commandée, quand il sort 23% (pour reprendre cette valeur), c’est qu’il a déterminé que ta chaudière devrait tourner à 23% de puissance. Donc idéalement tu ferais tourner la chaudière à 23% de puissance.
