Actuellement c’est le thermostat Secure. Il pilote directement un relais Zwave. Il n’y a pas d’autres intéraction et pas d’autres intelligence.
Je ne sais pas répondre à ta question…
Le thermostat actuel Secure Zwave ne met jamais 100% en continu. J’ai effectivement vu le PWM à 20 min mais sur cette plage, il y a jamais de 100% ON. Même quand l’écart avec la consigne est important. Je pense de mémoire qu’au mieux il doit etre ON pendant 50% de la plage de 20min.
On voit mieux ici ou j’ai rajouté directement la courbe de mesure de puissance avec une torre
Est ce que le parametre keep_alive ne sert pas justement à appliquer la largeur de l’impulsion ON par rapport au PWM ?
Et justement ces 2 parametres ne permettraient ils pas de protéger
min_cycle_duration
min_off_cycle_duration
Après c’est sur que je pense que le plancher chauffant ne doit pas etre sur ON en permanence pour la montée en température, même ne serait ce qu’une heure.
EDIT : je confirme, PWM 20 min sur mon thermostat. Sur cette période de 20 min, il n’est jamais à ON plus de 10 min consécutive. Je pense qu’il faut en déduire que quand on lui demande 100% de puisance, ça équivaut à 10 min ON et 10 min OFF.
J’aurais donc tendance à mettre ces parametres
pwm : 20m
min_cycle_duration: 0m
min_off_cycle_duration: 10m
Mon raisonnement est il bon ?
Autre question, quand tu donnes l’exemple ci dessous
Exemple avec les mesures que @lulakhub m’a fournies:
Amplitude de l’oscillation `Yosc = 2.1°C`, période de l’oscillation `tosc = 10200 secondes`.
Selon Ziegler-Nichols on a donc :
Ku = 8 * 100 / (2.1 * pi) = 121.261
Kp = 121.261 / 34 = 3.567
Ki = 3.567 / (10200 / 40) = 0.01499
Kd = 3.567 * (10200 / 160) = 227.396
Le keep_alive sert à contrôler la réactivité du thermostat et assurer que le module de contrôle soit bien dans l’état attendu (on ou off). Sur un PWM de 20mn, mieux vaut rester sur 1mn
Au vu de la courbe de puissance consommée par le plancher, alors oui, il module. Du coup j’ai l’impression que la hauteur des barres oranges correspond au rapport cyclique du on/ff, non ?
Je pense qu’il serait pas mal de limiter de la même façon la puissance, dans un premier temps, afin d’être sûr de ne pas faire surchauffer le plancher (vu les désagréments que ça cause). Il faudrait d’ailleurs s’assurer que le plancher dispose bien d’une sécurité pour ne pas faire monter la température trop haut en surface du sol (par exemple les chaudières alimentant un plancher chauffant doivent limiter la température de l’eau à 40°C max, et une sonde de sécurité vient couper le circulateur si l’eau est au delà de cette limite).
Il y a un paramètre difference qui n’est plus documenté mais qui existe encore, et qui te permettra de limiter le rapport cyclique max. Dans ton yaml, mets:
difference: 50
pwm: 1200
keep_alive: 60
Ca devrait te permettre de reproduire le même comportement que ton thermostat actuel.
pi, c’est la constante pi = π = 3.14159265359, comme dans 2πr²
Ah ok pour le pi, j’avais pas fait le rapprochement.
Du coup je laisse tomber le min_off_cycle_duration ?
Ca ressemble à ce que tu me dit du coup pour regler le rapport cyclique
Pourquoi difference n’est il plus documenté ? des chances qu’il disparaisse ?
Concernant les barres Orange, je ne sais pas te dire. Mon thermostat actuel Secure est vu comme un climate dans HA. le haut de la barre correspon à la temperature effective du thermostat (pas la consigne), et le retour n’est pas régulier. Je pense donc qu’il ne faut pas tenir compte de la hauteur de ces barres mais surtout de leur largeur, le rapport cyclique quoi !
Concernant la protection, il n’y en a pas. Le contacteur de puissance est directement sur les résistances chauffantes.
Avec tes calculs, j’obtiens ça. Attention mon Tosc est très long : 10h, même 13h parfois, à priori vu l’inertie de la dalle
Ku = 363.782
Kp = 10.699491
Ki = 0.011888
Kd = 2407, 385475
Ah oui, OK, la hauteur des barres est gérée par HA, mais ça va à la température mesurée par le thermostat, qui n’est pas affichée. Elle semble effectivement mise à jour assez lentement comparé aux deux autres capteurs.
Je te recommanderai d’utiliser le capteur nommé « Température » dans tes courbes (le Aqara je suppose) comme référence de ton Smart Thermostat, il m’a l’air plus stable.
C’est parti. Y a plus qu’à attendre.
Combien de temps il faut pour qu’il s’auto apprenne ? OU que la régul commence à faire effet ?
La ma consigne est à 19. Il fait 19,1 et il a toujours pas lancé le switch.
J’en ai profité pour rajouter le capteur outdoor avec le Ke à 0,6.
Est ce que le fait de redémarer HA modifie le comportement du thermostat ? Ou redémrre son cycle d’apprentissage ?
Si tu as déjà calculé tes gains à la main, ne le lance pas en auto-tune, d’expérience c’est beaucoup trop long sur un plancher chauffant.
Et malheureusement les gains ne s’ajustent pas tout seuls, il n’y a pas d’apprentissage. Il faudra corriger tes gains à la main en fonction du comportement du thermostat.
Oui c’est ce que j’avais lu. J’ai pas utilisé l’autotune.
Je vais attendre que ça commence à chauffer
Je ferais un point ce soir.
Mais je pense qu’il y a quand même une période d’apprentissage notament quand la température baisse afin qu’il anticipe la remontée en température…
La j’ai créé le thermosat alors que la température était en chute libre
Pour ça il te faudra ajouter une ligne de paramètre dans ton yaml:
debug: true
et que tu créées des capteurs sur les attributs pid_p, pid_i, pid_d et pid_e en plus du control_output pour voir comment ils évoluent et voir qui active ou empêche l’activation de ton chauffage, et donc savoir quel gain modifier et dans quelles proportions.
Avec ça tu peux par exemple voir si ton pid_d monte très haut et active le chauffage à la moindre petite baisse de la température mesurée, alors que la température est déjà au dessus de la consigne, ce qui la fait monter petit à petit. Dans ce cas, ça veut dire qu’il faut baisser le kd.
Merci. Je regarderais ce soir pour le faire.
Sinon depuis début d’aprem, voici les courbes avec le thermostat PID.
Par contre le parametre difference ne doit pas fonctionner car j’ai une période en début d’aprem ou le switch est resté on plus de 30 min…
Du coup je me demande si faudrait pas utiliser ma méthode avec min_cycle_duration et mon_off_cycle_duration…
Sans regarder les infos de debug, pour l’instant ça a l’air de bien réguler. la température n’a que peu oscillé. Je suis étonne pour 4 ou 5h de régulation vu l’inertie de la dalle chauffante ;-).
Appliquer un paramètre différence de 50% limite la valeur de control_output dans le PID, mais je le recompare par rapport à cette valeur différence au moment de calculer le temps ON. Donc ça reste à 100% max
Les min ON et min OFF ne changeront pas ce comportement, ça ne fera que empêcher un rythme allumage/extinction trop rapide. Mais si le PID dit 100% ça restera ON tout le temps.
Ca limite le temps minimum dans chaque état. Dans ton cas on veut limiter le temps maximum à l’état on.
Si tu veux essayer, tu peux corriger le bug vite fait dans le fichier du composant.
Avec un éditeur de fichier, vas voir dans ton dossier de configuration de Home Assistant (là où il y a le configuration.yaml). Tu dois avoir un dossier custom_components/smart_thermostat/
Tu trouveras dedans le fichier climate.py
Ouvre le et vas à la ligne 1122, tu y verras la ligne
Ca marche. J’essaye demain ou dans la semaine. La je laisse tourner comme ca pour voir., boulot oblige…
Sauf à la création je n’ai pas reu du 100% donc pas trop inquiet. Je surveille tout de même
Et oui j’ai lu trop vite pour les 2 paramètres, c’est le temps min effectivement alors qu on veut le temps max !!
@ScratMan
Hier soir, sans faire ta modif de code, j’ai essayé de supprimer le difference: 50
Ca a fait n’importe quoi. Pas compris pourquoi on avait toujours bcp de puissance alors que la temperature dépassait la consigne…
Ton P est beaucoup trop faiblement négatif par rapport à ton I qui monte beaucoup.
Essaie de faire x2 sur le kp et fais un smart_thermostat.clear_integral dans les services pour le laisser se recaler.
Dans l’idee de le mettre sur un seche serviette salle de bain, pense tu qu’il fera le boulot avec ton smart thermostat
j’ai un studio sur Paris ou j’allume le chauffage a distance et ca me permettrai de completer le chauffage de la sdb
J’ai un capteur de temperature dans cette piece et ca me permettrai d’etre plus précis je pense que le thermometre du seche seviette?
Je réponds un grand OUI ! c’est exactement ce cas d’utilisation qui m’a fait regarder du côté du thermostat PID et qui m’a poussé à en reprendre le développement.
J’ai un seche serviette électrique que j’avais équipé d’un module fil pilote Qubino Zwave, histoire de pouvoir le programmer,et dont la régulation n’était pas extraordinaire.
Malheureusement le panneau du sèche serviette étant accessible depuis la table à langer, et les bébés adooooorant jouer avec des boutons et des lumières, ma fille a joué avec, ce qui au final a un peu plus détraqué le potentiomètre du thermostat (elle arrivait à passer outre le pion de blocage de la sécurité enfant, la chipie).
Et voilà comment je me suis retrouvé à redévelopper un thermostat virtuel plus performant qu’un simple hystérésis.
Le thermostat physique du sèche serviette est maintenant à fond (et le bouton de réglage retiré pour plus que les enfants ne jouent avec), et le smart thermostat contrôle un input_boolean en PWM.
Pour finir, une automatisation bascule mon fil pilote entre le mode confort et le mode hors-gel selon l’état du booléen.
Le module NodOn est intéressant parce qu’il propose en plus la mesure de conso du radiateur
C’est marrant l’engouant pour le module Nodon, surement très bien par ailleurs !
Perso j’ai sur mon sèche serviette un Shelly 1 avec une diode installé à l’arrache il y a 3/4 ans et ça fait le job avec un thermostat virtuel. Et pour la mesure de conso, vu que c’est que charge fixe, Powercalc fait très bien le job…
Mais le Nodon me plait bien et surement plus simple à utiliser que la sortie de câble Legrand montée chez un ami…
