Bonjour, j’utilise depuis environ 1 an le plugin thermostat (en mode temporel), qui est vraiment une pépite. S’il y avait toutefois une amélioration à y apporter, à mon sens, ce serait la prise en compte de l’inertie des radiateurs à cheval sur deux cycles. Je m’explique : je suis équipé de radiateurs électriques à inertie sèche, pour lesquels on constate un décalage d’environ 30 min entre la génération de la chaleur et sa restitution à la pièce. En gros, si le radiateur est allumé de 8h à 9h en continu, la température de la pièce va s’élever entre 8h30 et 9h30. En rythme de croisière, quand le temps de chauffe est relativement faible (moins de 50% du temps du cycle), la chaleur a le temps d’être presque complètement restituée à la pièce, et le calcul du cycle suivant est très précis. Par contre, au moment d’une augmentation importante de la température de consigne (mode éco à 15°C, la température de la pièce est de 16°C, passage en mode confort, la consigne passe à 19°C), le radiateur doit enchainer 2 cycles à 100% + éventuellement un autre partiel pour atteindre la nouvelle consigne. Et là ça se corse : A l’issue d’un cycle de chauffe à 100%, le calcul du temps de chauffe pour le cycle suivant se fait en fonction de la température de la pièce à l’instant t. Or comme les radiateur sont resté en chauffe jusqu’à cet instant, ils ont encore 30min de chaleur à dissiper, qui va peut-être faire s’élever la température de la pièce de 1°C. Résultat : à la fin du 2ème ou 3ème cycle qui devrait permettre d’atteindre la consigne « 19°C », celle-ci est dépassée de 1°C, qui correspond à l’inertie non prise en compte dans le calcul du début de cycle.
Je pense qu’il serait possible d’intégrer ce paramètre en ajoutant un élément au calcul du temps de chauffe. Lorsque les paramètres déjà présents sont déterminés (période d’apprentissage terminée), il est possible de déterminer de combien la température va augmenter en fonction du temps de chauffe. Ca revient d’ailleurs au même que le calcul qui se fait en début de cycle (sauf qu’au lieu de chercher le temps de chauffage nécessaire à l’augmentation de la température de x °C, on cherche de combien de °C la température va s’élever avec un temps de chauffage de x %). Il suffirait donc de faire la différence entre cette élévation de température théorique et l’élévation réelle maximale durant le cycle (généralement atteinte en fin de cycle), pour obtenir l’élévation de température encore à venir du fait de la chaleur encore présente dans les radiateurs. Voici un schéma considérant un seul cycle de chauffe à 100% :
Il faudrait ensuite ajouter cette élévation de température à venir à la température réelle de la pièce pour obtenir la température à intégrer à la formule de calcul du cycle …
Est-ce que ça vous semble pertinent ou trop compliqué / à côté de la plaque ?
Merci en tous cas aux courageux sont arrivés jusqu’à la fin de mon message !
Merci de ton retour Loic. Mes compétences en programmation sont malheureusement très limitées, mais si un jour je trouve le temps de me former je m’y pencherai. Quoi qu’il en soit merci pour ce super plugin qui à lui seul justifierait de passer à jeedom !
Oui, bonne idée, ce serait une approche relativement simple et qui améliorerait déjà bien le résultat. Il faudrait que la valeur qu’on saisisse soit retranchée du % de temps de chauffe calculé en fonction des coefficients de chauffage et d’isolation : le calcul « brut » donne 70% de temps de chauffe, j’ai saisi -30%, donc au final le temps de chauffe sera de 40%. C’est bien ça ?
Ca permettrait déjà de tester le principe, voir si les fins de grosses chauffes sont mieux négociées.
Super, merci ! Tu veux que je regarde ce soir pour installer le plugin en beta (je suis encore en V3, c’est bon aussi ?), et que je te tienne au courant ?
Ok, donc je garde le core en V3 stable, et je ne fais que passer le plug-in thermostat en beta, c’est bien ça ? Question bête : est-ce qu’après c’est possible si nécessaire de retourner sur la branche stable du thermostat ? Je n’ai qu’un jeedom de prod, et en pleine saison de chauffe j’avoue que je préfère être prudent (je ne voudrais pas que madame m’ordonne de retourner au bon vieux programmateur modulaire analogique qui lui au moins est très fiable - la preuve, avec lui, il fait 19°C partout dans la maison, de jour comme de nuit et même quand on est partis en vacance :-p !)
J’ai installé la version beta du plugin. J’ai une coche « Offset lors d’un second cycle à 100% (% du cycle) » qui apparaît, mais pas de champ de saisie pour le pourcentage …
Bonjour, mise à jour faite, le champ apparaît bien cette fois-ci, merci ! Le prochain gros cycle de chauffe a lieu en fin d’après-midi, je te tiens au courant dans la foulée du résultat.
le premier cycle de chauffe a eu l’offset d’appliqué (variable initialisée à oui ?) ; il serait peut-être préférable que par défaut l’offset ne s’applique pas, mais uniquement si un cycle à 100% a bien été réalisé avant ?
par contre le second est bien parti à 100% et le troisième a bien eu l’offset fixé (40%), donc la prise en compte est ok.
Juste une question : si on a un premier cycle calculé à 250 %, donc lancé à 100%, puis un deuxième à 150%, l’offset est appliqué à 150 % (ce qui donne dans mon cas 110% ramenés à 100%), ou appliqué à 100%, ce qui donne 60% de temps de chauffe ? La question peut se poser quand la chauffe doit se faire sur 3 cycles, et dans ce cas c’est le premier mode de calcul qui est pertinent : 100 %, puis encore 100%, puis 50%-40% = 10% .
Merci en tous cas pour la super réactivité. Je continuerai à te tenir informé demain de comment ça continue à fonctionner.
Bonjour, cette nuit la séquence de chauffe (passage du mode éco au mode confort) s’est très bien lancée, avec un premier cycle de chauffe à 100%, comme il faut. Par contre le deuxième cycle ne m’a pas apporté la réponse à la question que je me posais hier soir à savoir si l’offset s’applique aux 100%, ou au pourcentage qui résulte du calcul brut (par exemple 140% si le calcul brut donne un temps de chauffe nécessaire encore supérieur à la durée d’un cycle) : cette nuit, un deuxième cycle complet n’a pas été nécessaire … Et je ne conservais pas assez de lignes dans mes logs pour retourner au moment ou le calcul intéressant s’est fait hier après-midi. J’ai donc rallongé mes logs … A suivre !
!