eco_temp: 18
boost_temp: 22
comfort_temp: 20
home_temp: 21
sleep_temp: 17
activity_temp: 20
Le problème de les set comme ceci, est que tu ne peut plus les modifier via l’interface, il reviennent tjr à leur température initiale que tu set dans le yaml.
Perso je préfère avoir la main sur leur valeur via mon IHM :
Oui, en effet, c’est une limitation du thermostat générique. Il va falloir que je me penche sur comment ajouter des services à une intégration pour permettre de jouer sur ces paramètres directement dans Lovelace
En regardant plus en détail la prise en compte de la température extérieure, de ce que j’en comprends la partie b * (consigne - temp_ext) ajoute un offset dépendant de la température extérieure pour compenser l’erreur résiduelle qui viendrait des pertes caloriques de la pièce.
Mais dans un PID c’est exactement le rôle de la partie intégrale: une compensation automatique de l’erreur résiduelle du régime établi.
Sur le net je ne trouve que des implémentations type loi d’eau (donc linéaire gain/offset avec prise en compte de la température extérieure) ou alors type PID (donc uniquement basée sur l’erreur consigne/ambiante et l’évolution temporelle).
J’ai peur qu’au final le PID devienne instable si on ajoute une composante température extérieure, qui viendrait perturber l’intégration du PID.
Perso je n’ai plus cette limitation avec le thermostat « simple_thermostat » :
Je ne set aucune valeur au boot de l’addon (et donc dans le YAML) et je set ensuite via les input_number.
Vous cherchez à intégrée la « temp_ext » pour intégrée un potentiel mode temporel (anticipation de la courbe de chauffe pour atteindre la température à heure souhaité) ?
Merci pour l’info, je vais regarder le code du Simple Thermostat pour voir comment il gère ça et m’en inspirer. Ca permettrait aussi de ne plus avoir besoin de surveiller la fin de l’autotune pour mettre à jour les gains du PID.
Non, ça nécessiterait d’implémenter une gestion de planning dans le thermostat. C’est déjà plus compliqué à faire. C’est ce que font les Netatmo ou Tado°, mais dans notre cas il faudrait ajouter une interface avec une autre intégration custom genre Scheduler, pour que le thermostat sache quelle sera la prochaine température de consigne et à quelle heure elle est prévue, plus une moulinette qui permette d’évaluer l’anticipation du démarrage à appliquer dans le thermostat en fonction du delta de température qu’il va y avoir.
Ca serait top, si ça marche je peux revendre mes deux thermostats connectés, mais ça sera pas pour tout de suite.
Là je cherche à comprendre comment faire pour que le thermostat puisse tenir compte du PID et de la température extérieure pour encore améliorer la régulation sans que tout parte en couille.
Bah si t’arrive à faire ceci, je te baise les pieds 
C’est quelques chose que je faisait via Jeedom et je trouve ca vraiment top, j’ai le code du thermostat si tu veut faire du reverse engineering :
Si @ScratMan nous reverse le Thermostat de Jeedom on va être plusieurs à lui baiser les pieds et chez Jeedom ils vont le maudire car c’est une des rares choses qui retient leurs utilisateurs…
2 « J'aime »
Bah il est clair que ca comblerais pour moi le plus gros manque coté HA. 
1 « J'aime »
Hello. Je teste aussi le smartThermostat! Je suis entrain de tester la fonction autotune mais aprés 5 cycles de chauffes je n’ai toujours pas de retour et j’ai l’impression qu’il na pas finit ca fonction d’autotune. Est-ce que c’est normal?
En tous cas good job @ScratMan !
Quel est l’état de l’attribut autotune_status du thermostat ?
Quelles étaient les durées du lookback et du keep_alive ?
humm j’ai pas précisé ca dans ma config.yaml:
- platform: smart_thermostat
name: Smart Thermostat Example
heater: input_boolean.chauffe_radiateur_2
target_sensor: sensor.zigbeechambre_temperature
min_temp: 12
max_temp: 25
ac_mode: False
target_temp: 18
keep_alive:
seconds: 60
away_temp: 14
#kp : 50
kp : 75
ki : 0.001
#ki : 0.001
#kd : 150000
kd : 70000
autotune : ziegler-nichols
pwm : 00:05:00
autotune_status: relay step up
Est-ce qu’il serait possible d’avoir un export des données du thermostat (température, consigne et on/off) au format csv stp ?
Tes courbes ont l’air parfaites pour le calcul, je vais essayer de faire une simulation du système voir ce qui ne va pas.
Ok je te fais ca. Je sais exporter des valeurs avec influx DB en CSV par contre j’arrive pas a récupérer l’état : heat ou off du thermostat sur influx db. Quelqu’un a une idée?
Bonsoir,
Très intéressant tout ça, j’étais sur le TPI qui fonctionne déjà très bien.
Pour ma part, il semble que l’autotune boot :
Autotune will run with the next Setpoint Value you set. Changes, submitted after doesn't have any effect until it's finished
Mais reste sur :
autotune_status: relay step down
Config:
climate:
- platform: smart_thermostat
name: Smart Thermostat bureau
heater: switch.radiateur_bureau
target_sensor: sensor.bureau_temperature
min_temp: 15
max_temp: 29
target_temp: 19
keep_alive:
seconds: 60
away_temp: 14
kp : 75
ki : 0.001
kd : 70000
autotune: "ziegler-nichols"
Je loupe quelque chose ?
Merci
Le on/off est optionnel pour l’analyse, le tuner n’en a pas besoin pour le calcul (c’est lui qui le contrôle), sinon il aurait fallu ajouter un sensor qui vienne récupérer l’attribut control_output et l’envoyer dans InfluxDB.
Je pense que l’autotuner n’est pas encore fonctionnel.
J’ai analysé plus en détail son code et j’ai remarqué plusieurs choses :
- La durée du
lookbackdoit être assez grande pour avoir 4 pics (min et max) dans le buffer, soit 1 cycle et demi. - La taille du buffer est définie par la durée du
lookbacket lesampletime(le temps fixé entre deux runs de la boucle d’autotune).
Mais comme le thermostat fait un run sur l’autotune dès que HA envoie un update, quelle qu’en soit sa source (boot, température qui change, consigne qui change, ou timer du keep_alive), ça lance des runs avec un délai entre les échantillons bien foireux. Et comme souvent le taux d’échantillonnage dépend du capteur de température, par défaut on ne le spécifie pas dans la configuration du thermostat, donc l’autotuner prend 1 seconde par défaut… bref le buffer est interminable et si HA envoie un échantillon toutes les 15 minutes, si le buffer fait 2h / 1s = 7200 éléments, ça veut dire que le buffer ne sera pas plein avant 1800 heures… et le calcul de l’autotune ne se fait qu’une fois le buffer plein… bref, rendez-vous dans 75 jours 
Je suis en train de faire une mise à jour pour que l’autotune démarre sans savoir le sample_time et le calcule sur les 5 premiers échantillons. Je publierais une version beta quand j’ai quelque chose qui marche.
Malheureusement je ne peux pas la tester moi même, ma salle de bain étant très bien isolée, un cycle dure déjà plus de 5h… dans une pièce dont la température varie beaucoup, impossible de laisser tourner sur un régime établi 24h sans risquer de fausser l’autotune en prenant une douche.
Si vous avez des csv avec des valeurs de température/consigne, je pourrais essayer une simulation. Merci.
2 « J'aime »
OK merci, je mets en stand-by et je suivrais l’avancement de près car pour le reste ça me dépasse un peu 
Release beta avec la tentative d’amélioration de l’autotuner. Plus besoin d’un step, il démarrera tout seul en fonction de l’arrivée des mesures du sensor.
J’ai ajouté des attributs autotune_... pour avoir plus de visibilité sur ce qu’il fait.
1 « J'aime »
Alors chez moi c’est un immeuble ancien, donc oui on constate que c’est pas trés bien isolé 
J’ai galéré mais j’ai enfin les exports, j’éspère que ca va t’aider.
Merci pour les exports. Je testerais l’autotune dessus quand j’aurais un moment pour développer un banc de test.
Sinon, déjà une beta3