Domotisation Frisquet Prestige Condensation Eco Radio System

Matériel Jeedom - Hardware
1

Bonjour à tous,

J’ai une chaudière à gaz Frisquet Prestige Condensation Eco Radio System de fin 2010.

(Ce n’est pas une Visio)

Je suis dans une maison à plusieurs niveaux (rdc, etage 1, etage 2, + cave où se situe la chaudière). Construction avant 1945. Je veux domotiser pour pouvoir paramétrer des températures de consigne pièce par pièce (idéalement un peu plus fin que niveau par niveau même si pas loin non plus) et ainsi éviter de chauffer là où c’est inutile (ex : la nuit au rdc, ou en journée en semaine les chambres des enfants…). En espérant économiser pas mal sans perdre en confort.

La solution que je voyais, c’était de coller des têtes thermostatiques connectées en Z-Wave+, une box sous Jeedom, coder la régulation PID qui irait bien (ou s’il y a des plugins qui savent envoyer ce qu’il faut au contact sec de la Frisquet…), un actionneur de chaudière via contact sec, et roulez jeunesse.

(Ou pas forcément contact sec si on pouvait faire mieux (plus intelligent))

Parmi les sujets que j’ai identifiés :

  1. Domotisation partielle des radiateurs

Si je fais le décompte, j’ai pas loin de 20 radiateurs dans la maison, dont peut-être une moitié avec des corps de vanne thermostatiques (pas là où ce serait forcément le plus intéressant de piloter en fonction de l’heure), et l’autre moitié robinets classiques (dont rdc et chambre). Si je devais coller des têtes à 50€ partout (+ corps de vanne à changer sur la moitié) ça ferait déjà un gros budget.

Sans avoir fait le parcours / décompte précis, ma réflexion était que je pourrais me contenter d’en connecter une partie seulement - ceux sur lesquels cela vaut le plus facilement le coup, par leur taille (les gros) et/ou leur situation (le fait que le besoin de chauffage de leur pièce diffère notablement selon le moment de la journée ou non).

Pour schématiser, domotiser en priorité les gros radiateurs du rdc et ceux des chambres. Ca en fait encore une dizaine, c’est beaucoup mais c’est quand même 2x moins. Cela vous paraît-il judicieux ou y a-t-il un piège ?

  1. Bonne communication des modules

J’ai conscience qu’il faut veiller à la bonne communication des modules jusqu’à la box (puis jusqu’à l’actionneur de chaudière).

J’en aurais 6 au rdc, 2 ou 3 au 1er, et 1 au 2ème. Avec le protocole Z-Wave normalement ça devrait passer ? Celui du deuxième serait au-dessus des deux chambres du 1er (qui seront équipées). Je pensais mettre la box domotique à la cave (juste à côté du régulateur, elle serait en-dessous d’un radiateur équipé au rdc, donc pas trop mal ?). Et comme ça elle est à côté de la box internet aussi donc raccord direct en filaire.

  1. Frisquet

Le principal gros sujet, en fait.

J’ai déjà beaucoup potassé le sujet Frisquet. J’ai bien vu qu’ils sont pénibles. Notez que j’ai :

  • une Prestige (pas Hydromotrix par exemple)
  • une Condensation
  • une Eco Radio System, mais PAS Visio
  • J’ai le ballon d’Eau Chaude Sanitaire en plus avec

Ainsi et par exemple, le câble F3AA40446 qu’on voit revenir souvent pour le contact sec n’est pas le bon chez moi (ou en tout cas semble pas le bon). Il se pourrait que ce soit le F3AA41241, mais normalement ce n’est que pour les Visio… Bref, y a de possibles pièges entre modèles proches.

J’ai lu (entre autres…) les deux topics ici et ici, mais pas facile d’être convaincu qu’in fine ce sera bon, et je me demande s’il vaut pas mieux repartir proprement pour cette section.

Est-ce que piloter cette chaudière ne peut se faire que via le contact sec, ou est-ce qu’il est possible de le faire autrement ?

  • si on le fait via contact sec :

a) j’ai vu que certains arrivaient à faire des régulations type PID avec leur Frisquet. Est-ce que ça reste aussi « clean » que lorsque la commande est gérée en interne (qui permet de faire tourner la chaudière continûment et de façon localement stable à x% de puissance), ou est-ce que les algos d’asservissement écrits pour le contact sec font « simplement » du PWM en sortie (modulation d’un on/off car seul fonctionnement possible de la chaudière en contact sec) ?

C’est pour moi la question avec le plus d’incertitude. Certains disent que oui c’est forcément du PWM de tout ou rien. D’autres disent que non.

Ce qui est sûr c’est que certains ont constaté sur leur chaudière que le rapport cyclique sur l’entrée contact sec donnait directement une dérivée de puissance de chauffe et non la puissance de chauffe => il n’y a donc pas directement un tout ou rien sur certains modèles.

b) est-ce que certains plugins existants (Thermostat que je vois souvent revenir ou autre) incorporent déjà ça ou c’est à récupérer / reprendre / adapter de quelque part ?

c) est-ce qu’il y a une contrainte particulière sur l’actionneur par contact sec ? un ou des modèles particuliers à privilégier ?

In fine, est-ce qu’on sait aujourd’hui gérer cette gamme de chaudière (ou au pire des cousines proches laissant supposer qu’on pourrait faire pareil ici) de façon efficace / optimale y compris du point de vue de son fonctionnement interne (donc pas juste en faisant de la PWM de 0%/100%), via le contact sec ?

  • pilotage par une autre voie

Y a-t-il d’autres modules de commande qui existent déjà et remplaceraient le module ERS plutôt que de passer par le contact sec ? Ca implique de savoir parler le même langage qu’un équipement propriétaire Frisquet.

Dans le même ordre d’idée (mais un peu différent car on conserve l’ERS), J’ai commencé à voir des choses où on émet soi-même des messages tels que ceux qu’enverraient l’Eco Radio System, le récepteur intégré les voit et la suite se déroule comme si c’était le thermostat d’origine qui les avait envoyés, et donc derrière tout est fait proprement par la chaudière. Mais ça semble encore tout nouveau pas encore finalisé, même si ça n’en semble pas loin. Je me trompe ? Quelqu’un a déjà fait de bout en bout de la sorte ? Voire mieux et comme précédemment, est-ce que certains plugins existants (Thermostat ou autre) incorporent déjà ça ?

Avec bien sûr à chaque fois la double question : est-ce qu’il y a des cas répertoriés avec cette gamme particulière (Prestige Condensation) ; et quid des cas avec ballon ECS ?

  • Autre option : je mets mes têtes connectées et je les programme. Par contre je laisse tomber l’espoir de remplacer la commande Frisquet, je continue avec mon thermostat Frisquet. Pour que ça explose pas : a) je paramètre le thermostat pour qu’il commande une température inférieure à celle demandée par les têtes (par ex 0.5° de moins, à bien calibrer)
    b) le soir il est dans les chambres, le jour dans le salon par ex
    C’est quand même un peu foireux…

Voilà, je réalise que c’est du coup encore très vaste en termes d’interrogations…

Merci de votre aide

2

J’ai aussi une Frisquet Hydromotrix compatible Eco Radio System. Au début, je la pilotais en contact sec avec les inconvénients que tu as listé. Depuis un an, j’ai réussi à la piloter en régulation en utilisant un RFLink avec un firmware développé par mes soins. J’ai tout documenté ici : https://github.com/ChristopheHD/frisquet-arduino (n’oubliez pas d’aller voir le Wiki pour la configuration Jeedom)

2 « J'aime »
3

Bonjour,
Beaucoup de questions :wink:
(je suis sur une hydromix)
Sur la partie câble, pour moi, c’est bien le F3AA40446, cf doc frisquet :
Frisquet-Installation.pdf (212,5 Ko)
si doute, il suffit de regarder le connecteur. les connecteurs entre les 2 versions de cable sont bien differents
Sur la partie contact sec, de mon coté, aucun changement de fonctionnement entre le contact sec et l’eco radio system si dépassement de consigne.
Dans le cas du contact sec, ma chaudière redémarre en chauffant par cycle de marche/arrêt jusqu’à atteindre la température nominale.
Le plugin thermostat me semble difficilement utilisable (au niveau de la chaudière car la température de chauffe n’est pas constante (mode auto)
Des contraintes particulières par rapport au contact sec, pas vraiment. il faut partir du principe que le contact sec fonctionne ni plus ni moins que comme un thermostat netatmo (on/off au dépassement de consigne) ou l’eco radio system (idem on/off).
La seule contrainte le semble lié à la mise en palce de vannes thermostatiques et le fait que tout le circuit puisse etre fermé … mais tu sembles vouloir laisser des vannes classiques, donc pas de souci de ce coté là

Pour aller plus loin, je t’invite à lire le très bon post suivant qui explique comment reguler la temperature de l’eau avec un contact sec sur une chaudière frisquet :
https://easydomoticz.com/forum/viewtopic.php?t=1486

je suis preneur de mon coté de toutes tes reflexions et essais

Norbert

EDIT : je viens de voir que tu avais déjà posté sur le thread indiqué, donc tu connais déjà ce tuto :wink:

4

Oui, merci de vos réponses. ChristopheHD j’ai bien vu ton super tuto en construction :slight_smile:

Notamment grâce à lui je visualise de mieux en mieux le truc et je pense m’orienter vers la solution de parler directement au récepteur radio ERS comme ChristopheHD donc. Et aussi parce que j’ai intérêt à laisser la chaudière gérer le plus de trucs possibles (j’ai un ballon ECS, et étant à condensation c’est mieux a priori si elle peut gérer intelligemment ses cycles).

Pour la partie domotique je pense que ce sera effectivement du Jeedom (une Atlas probablement, ou peut-être basculer mon abonnement Freebox vers une Delta, ce qui me fait un appareil de moins, avec les avantages et les inconvénients que ça a…), pour profiter des plugins notamment Thermostat qui apparemment fait notamment tout seul son apprentissage.

Le tout en Z-Wave+, qui me semble à la fois à peu près le plus courant, bien standardisé, et du fait que j’ai au moins deux niveaux entre la box et les têtes les plus éloignées (possiblement 3 niveaux si je mets la box à la cave, à voir). Et que les têtes que je vois avec contrôle de l’ouverture de la vanne en % semblent en Z-Wave.

En l’occurence je prendrais des Eurotronic Spirit Z-Wave+.

Pas de grosse erreur dans mes choix, ça vous semble cohérent ?

5

Un jeedom atlas, oui, une Freebox delta, bof, bof !!!
Le plugin thermostat, à mon sens non adapté, car température de chaudière non constate et valable pour du TOR au niveau des radiateurs … Ce qui ne sera pas le cas avec une chaudière et des vannes thermostatiques.
Pour le protocole, Zigbee est plus en vogue que zwave, mais tu trouveras des détracteurs sur les 2 solutions.

1 « J'aime »
6

Oui l’option Freebox Delta est en train de passer à la trappe.

Peux-tu expliciter pourquoi tu considères que le plugin thermostat serait inadapté ? C’est la solution qu’utilise christopeHD et cela semble bien marcher chezlui.

Si j’ai bien compris, avec la solution en question, on communique bien à la chaudière une température d’eau, qui sera établie en amont par le plugin thermostat en fonction des retours des têtes (et du paramétrage appris via l’apprentissage automatique). Alors oui la consigne en tempréature d’eau va varier quelque fois dans la journée, mais c’est déjà le cas aujourd’hui sans domotique, à la fois progressivement (évolution des conditions extérieures) et plus rapidement (lors des alternances quotidienne mode Confort / mode Eco). Bref je ne vois pas quelle serait la différence de principe ?

7

Sauf si je n’ai pas compris toutes les subtilités des plugin thermostat, il est là pour faire du on/off sur une commande avec fil pilote ou un thermostat en mode TOR. Il calcule le coefficient de chauffe nécessaire en fonction d’un apprentissage qui lui permet d’avoir un certain nombre de variables fonction de l’isolation de orientation de la pièce de la taille , et de la température extérieure. Toutes ces variables dépendent de la température de l’eau qui doit être constante. Une fois l’apprentissage effectué, en fonction de la température extérieure et intérieure, le plugin calcule le temps de chauffe nécessaire.
Pour moi, ce système fonctionne avec les radiateurs terminaux mais peu difficilement fonctionner avec la chaudière surtout si tu rajoutes des vannes thermostatique au milieu.
Norbert
PS : si je trompe dans l’analyse et que certains ont réussi, je suis preneur de la méthodologie.

8

La méthodo est celle présentée par @ChristopheHD ici.

De ce que je comprends (Christophe pourra confirmer), on est en mode temporel, le plugin Thermostat calcule comme d’hab une puissance de cycle souhaitée en %, et on lui configure comme action, non pas de faire des on/off, mais simplement d’appeler un autre script (le ERS.py) qui :

  • prend en entrée cette puissance calculée
  • en déduit la température d’eau correspondante (consigne attendue par la chaudière)
  • dit à un module RFLink d’envoyer la commande radio qui va bien au récepteur radio ERS de la chaudière.

Du point de vue de la chaudière, c’est exactement comme si un vrai thermostat Eco Radio System venait de lui intimer cette consigne de température d’eau. Y a pas de on/off, et ni la chaudière ni le plugin thermostat ne voient la moindre différence avec ce pour quoi ils sont prévus.

Néanmoins ça m’amène une question pour @ChristopheHD : tu écris dans ERS.py :

temperature = 0.9*float(puissance)

Vu qu’à puissance 0, l’eau ne sort pas à 0° mais à une température plus élevée (on va dire au moins 10° ?), ne serait-il pas préférable d’écrire

temperature = 10+0.8*float(puissance)

?

Ca me semblerait en tout cas plus proche. Comme en amont le plugin thermostat fait tout de même manifestement des hypothèses physiques et est assez élaboré, j’imagine qu’il y a à gagner si on reste fidèle à ce qu’il essaie de faire.

Avec la formule initiale, s’il commande 10% de puissance (voire 15-20%…), la chaudière risque de même pas se mettre en marche, ce qui n’est manifestement pas ce que le plugin cherchait à obtenir…

Ca impliquerait j’imagine aussi de lui dire que le temps de chauffe minimum par cycle est bien de 0 (par exemple). Peutêtre d’autres paramètes aussi ?

Y a-t-il une raison pour avoir procédé ainsi ?

9

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.

1 « J'aime »
10

J’ai mis :

temperature = 20+0.7*float(puissance)

et j’ai aussi modifier le minimum de chauffe du plugin Thermostat à 5%. On va voir ce que cela va donner.

11

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 :

  1. 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 :frowning: )

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.

  1. 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).

  2. 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 :slight_smile: 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 :slight_smile: )

12

Oui

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.

C’est une température d’eau. Source : Vaillant CalorMatic 340f (868MHz) PART 2: Decoding the wireless protocol of the heating control [Reinhold's Wiki]
Précision : c’est sur le forum Domoticz que quelqu’un a remarqué que Frisquet utilisait le même protocole que Vaillant. Ensuite il n’y avait plus qu’à adapter le code.

13

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.

14

ç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.

15

Ok, merci beaucoup :slight_smile: !

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 :slight_smile:

16

Je ne sais pas répondre à tes questions, mais voici des logs de mon installation si tu veux te faire une idée :
thermostat.log (19,6 Ko)

17

Merci !

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.

18

Oui.

Pour te convaincre, voici les logs d’appels du script :

[2022-01-18 05:45:18] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Eco 2>&1 [] []
[2022-01-18 05:50:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Eco 2>&1 [] []
[2022-01-18 05:55:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Eco 2>&1 [] []
[2022-01-18 05:59:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Eco 2>&1 [] []
[2022-01-18 06:00:19] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 7 Eco 2>&1 [] []
[2022-01-18 06:02:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 7 Eco 2>&1 [] []
[2022-01-18 06:05:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 7 Eco 2>&1 [] []
[2022-01-18 06:10:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 7 Eco 2>&1 [] []
[2022-01-18 06:14:03] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 7 Eco 2>&1 [] []
[2022-01-18 06:15:18] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 10 Eco 2>&1 [] []
[2022-01-18 06:17:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 10 Eco 2>&1 [] []
[2022-01-18 06:20:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 10 Eco 2>&1 [] []
[2022-01-18 06:25:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 10 Eco 2>&1 [] []
[2022-01-18 06:27:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 10 Confort 2>&1 [] []
[2022-01-18 06:30:19] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:32:03] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:35:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:40:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:42:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:45:17] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:47:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:50:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:55:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 06:57:03] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:00:08] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:00:19] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:05:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:10:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:12:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:15:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:15:18] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:20:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:22:52] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 100 Confort 2>&1 [] []
[2022-01-18 07:22:55] script.DEBUG: Execution de : php /var/www/html/plugins/script/data/rt1900ac.php true 2>&1 [] []
[2022-01-18 07:25:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 99 Confort 2>&1 [] []
[2022-01-18 07:30:07] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 99 Confort 2>&1 [] []
[2022-01-18 07:30:10] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 78 Confort 2>&1 [] []
[2022-01-18 07:35:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 78 Confort 2>&1 [] []
[2022-01-18 07:37:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 78 Confort 2>&1 [] []
[2022-01-18 07:40:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 07:45:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 07:45:08] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 07:50:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 07:52:03] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 07:55:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 08:00:07] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 57 Confort 2>&1 [] []
[2022-01-18 08:00:10] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:05:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:07:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:10:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:15:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:15:08] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:20:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:22:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 16 Confort 2>&1 [] []
[2022-01-18 08:25:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 36 Confort 2>&1 [] []
[2022-01-18 08:30:08] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 36 Confort 2>&1 [] []
[2022-01-18 08:30:10] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 35 Confort 2>&1 [] []
[2022-01-18 08:35:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 35 Confort 2>&1 [] []
[2022-01-18 08:37:03] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 35 Confort 2>&1 [] []
[2022-01-18 08:40:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Confort 2>&1 [] []
[2022-01-18 08:45:09] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Confort 2>&1 [] []
[2022-01-18 08:50:05] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Confort 2>&1 [] []
[2022-01-18 08:55:04] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Confort 2>&1 [] []
[2022-01-18 09:00:09] script.DEBUG: Execution de : python /var/www/html/plugins/script/data/ERS.py 0 Confort 2>&1 [] []
19

:+1:

Je vois aussi dessus des appels dont l’origine n’est pas évidente.

5h45 5h50, 5h55, ok, c’est le cron de 5 minutes

Ensuite, pourquoi 5h59 ?

6h00, ok…

Pourquoi 6h02 ?

6h05, 6h10, (6h15), ok

Pourquoi 6h14, 6h17…

Bon, c’est pas dramatique. J’essaierai de voir si j’ai la même chose chez moi quand j’aurai une install en place :slight_smile:

20

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.