C’et très intéressant tout ca. Par contre un truc physique me freine.
Mes chauffages sont controlé par des switch zigbee qui font « tic » a chaque changement d’ordre. J’imagine que la, l’enchainement est bien plus frequent sur les ordres et donc bien plus nuisible de façon sonore … particulièrement dans une chambre
Oui et mal réglé ça peut aussi les abimer…
Bonsoir, il faut utiliser le paramètre min_cycle_duration pour empêcher une commutation trop courte. Il oblige le système à chauffer ou rester éteint au moins le temps indiqué.
Il est aussi possible de dissocier le temps mini off avec min_off_cycle_duration.
Ce qui serait top c’est de pouvoir faire un reload…
Hello à tous,
Une petite question bête : j’ai fait une boucle avec un chauffage (je n’arrivais pas à faire fonctionner l’autotune), et j’ai les données brutes (temps, on/off, et temperature). Je pensais utiliser PIDTuner pour trouver les Kp, Ki, et Kd, mais je ne comprends pas comment les obtenir… Un petit conseil pour les obtenir ?
Merci !
Bonjour @lpaso,
Si l’autotune ne marche pas (il est très dépendant de la régularité de l’oscillation), vous pouvez extraire à la main les informations nécessaires sur la courbe de chauffage (et ça peut même se faire dès qu’on a une oscillation complète, ce que l’autotuner n’arrive pas forcément à faire) :
Mesurez l’amplitude de l’oscillation Yosc en degrés et la période de l’oscillation tosc en secondes.
Ca vous permettra de calculer le gain ultime Ku:
Ku = 8.0 * difference / (Yosc * pi)
(difference = 100 par défaut)
Ensuite, en fonction des règles d’autotune que vous souhaitez utiliser (elles donnent des résultats variables) vous pourrez calculer les gains Kp, Ki et Kd en utilisant les diviseurs correspondants de la règle:
| ruler | diviseur1 | diviseur2 | diviseur3 |
|---|---|---|---|
| « ziegler-nichols » | 34 | 40 | 160 |
| « tyreus-luyben » | 44 | 9 | 126 |
| « ciancone-marlin » | 66 | 88 | 162 |
| « pessen-integral » | 28 | 50 | 133 |
| « some-overshoot » | 60 | 40 | 60 |
| « no-overshoot » | 100 | 40 | 60 |
| « brewing » | 2.5 | 6 | 380 |
| en utilisant les formules suivantes : |
Kp = Ku / diviseur1
Ki = Kp / (tosc / diviseur2)
Kd = Kp * (tosc / diviseur3)
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
Les valeurs obtenues sont une base de travail, à vous ensuite de les ajuster pour coller à votre besoin, selon si vous voulez plus de réactivité ou plus de stabilité.
4 « J'aime »
Quand j’aurai fini de mettre au point mon chauffage, je ferai un article avec les équation thermiques simplifiées et un réglage simple: précommande, proportionnel et intégral…
Là je découvre les joies du yaml et du template. 
4 « J'aime »
Aaaaah super ! C’est parfait ce tableau ! Merci 1000x !
Juste une question sur ce « difference » qui est à 100 par défaut. Cette valeur de 100, est-ce que c’est parce que par défaut l’oscillation demandée est de 1° (+0,5/-0,5) ou c’est lié à autre chose ?
Bon les amis, j’abandonne l’idée de l’autotune car ca prends enormement de temps, maison bien isolée et radiateurs a inertie seche ceramique.
Je suis parti sur ces paramètres partout pour commencer et j’ajuste en fonction de ce que je vois
Kp = 50
Ki = 0.01
Kd = 200
D’apes ce que j’ai compris des differentes docs et videos que j’ai pu me taper
Je baisse le Kp si ca depasse le target de beaucoup (et inversement)
J’augmete le Kd si ca monte trop vite (et inversement)
Et au final j’augmente (ou baisse) le Ki si ca se stabilise au dessous (ou au dessus) du target (mais j’en suis pas encore a cette etape)
1 « J'aime »
@ejalal : tu peux regarder ce message (le lien devrait marcher en attendant que les messages du sujet soient remis dans le bon 'ordre) :
https://forum.hacf.fr/t/hacs-smart-thermostat-le-chauffage-controle-par-pid/7633/85?u=scratman
à partir de la courbe de température dans l’historique de Home Assistant tu peux recalculer à la main les gains dits « ultimes » Ku et Pu, qui te permettent de calculer les gains Kp, Ki et Kd en fonction de la règle d’autotune que tu auras choisie.
1 « J'aime »
Hello
Serait il possible d’intégrer une gestion de master et de slave dans ce thermostat pour les chaudière ?
Un exemple qui était vraiement bien sous jeedom
h***s://github.com/DavZero/jeedom_boilerThermostat/
Avec une gestion Pid et de chaudière le plugin couvrirai quasiment tous les cas de figure.
Merci pour cette superbe avancé.
Il y a un autre thermostat qui semble faire ça : GitHub - vindaalex/multizone-thermostat: This is a home assistant custom component. It is a thermostat including various control options, such as: on-off, PID, weather controlled. The thermostat can be used in stand-alone mode or as zoned heating (master- satellites).
je vais attendre la fin de l’hiver pour le tester.
Merci mycanaletto pour tes articles, la partie thermostat ma bien inspiré.
@ScratMan Je viens de tester le fait d’init les valeurs des presets au 1er lancement puis les retirer par le suite pour garder une gestion des température via l’interface et une fois que je retire les PRESET_temp: les presets disparaissent des thermostat 
Pour rappel, de mon côte j’ai une gestion de mes preset par piéce via des input_number dans chaque zone :
En effet, j’ai pu reproduire le problème, mais je ne parviens pas à le régler. À l’initialisation de l’intégration on indique à Home Assistant les fonctions supportées par le thermostat, c’est là que les preset sont activés. S’il n’y en a plus aucun spécifié dans le fichier de configuration, HA semble enregistrer que l’entité ne supporte pas les preset.
J’ai essayé de modifier les fonctions supportées après l’initialisation, lors de la restauration des derniers états connus, mais ça ne marche pas.
Il faut donc garder les réglages dans le fichier config, puis les ajuster dans l’UI. Les dernières valeurs utilisées seront restaurées au restart. Et au moins en cas de crash de la base de données de HA les fonctions ne seraient pas désactivées.
Sur simple_thermostat, j’ai aucune idée de comment ils ont fait mais les preset sont tt le temps présent même si leur température n’est pas renseigné dans le yaml
Parce que dans leur init, le support des preset n’est pas conditionnée à la présence d’un preset dans la configuration.
Alors je n’ai peut être pas tt les billes, mais qu’est ce qui t’empéche de faire pareil ?
Après c’est mon point de vue, mais je trouve que c’est pas très « user friendly » de set une valeur en dur dans un fichier de conf (surtout pour un thermostat)
Ce sont des valeurs qui peuvent être amener à evoluer en fonction des saisons par exemple.
C’est pour ça qu’il y a le service pour changer la température des modes preset. Avec la configuration par fichier on peut rendre disponible un ou plusieurs presets, puis les ajuster comme on veut avec le service sans forcément tous les activer.