J’ai du attendre un peu avant que ça se mette en place mais maintenant que c’est parti c’est bon :
Après allumage et consigne à 19° :
Et la fréquence d’allumage :
Je vais regarder pourquoi y a un temps d’attente au début (certainement une valeur de température pas bien initialisée au démarrage et il faut attendre un changement de valeur)
T’as bien mis un sensor sur la température extérieure ?
edit:
si tu as des doutes tu peux ajouter ça dans ton logger.yaml:
logs:
custom_components.versatile_thermostat: debug
et regarder le home-assistant.yaml.
je vois bien les valeurs de cycle calculée qui sont cohérentes avec les entrées :
2023-01-07 14:23:23.780 INFO (MainThread) [custom_components.versatile_thermostat.climate] VersatileThermostat-TPI Thermostat - Temperature changed. Event.new_state is <state input_number.fake_temperature_sensor1=17.0; initial=None, editable=False, min=0.0, max=35.0, step=0.5, mode=slider, icon=mdi:thermometer, friendly_name=Temperature @ 2023-01-07T15:23:23.778756+01:00>
2023-01-07 14:23:23.780 DEBUG (MainThread) [custom_components.versatile_thermostat.prop_algorithm] heating percent calculated for current_temp 17.0, ext_current_temp 4.0 and target_temp 19.0 is 1.00, on_time is 60 (sec), off_time is 0 (sec)
2
Le pourcentage calculé est dans « is 1.00 » ci dessus soit 100% dans l’exemple.
edit2: autre exemple à l’instant:
2023-01-07 14:26:51.781 DEBUG (MainThread) [custom_components.versatile_thermostat.prop_algorithm] heating percent calculated for current_temp 18.5, ext_current_temp 4.0 and target_temp 19.0 is 0.45, on_time is 26 (sec), off_time is 33 (sec)
Le pourcentage calculé est de 45% soit 26 sec On et 33 sec Off (cycle à 1 min de test).
Je vais ajouter le pourcentage en attribut, j’ai vu comment faire. Ce sera plus pertinent en effet (et fixer le bug sur l’init des températures).
Publication d’une beta.2 qui contient :
hvac_modes:
- heat
- 'off'
min_temp: 7
max_temp: 35
preset_modes:
- none
- eco
- away
- boost
- comfort
- power
- activity
current_temperature: 16.5
temperature: 19
hvac_action: heating
preset_mode: comfort
away_temp: 17
eco_temp: 15
boost_temp: 20
comfort_temp: 20
power_temp: 12
on_percent: 0.50
on_time_sec: 30
off_time_sec: 30
ext_current_temperature: 4
current_power: 290
current_power_max: 760
cycle_min: 1
bias: 0.25
function: tpi
tpi_coefc: 0.6
tpi_coeft: 0.01
is_device_active: false
friendly_name: TPI Thermostat
supported_features: 17
notamment les attributs suivants: on_percent: 0.50, on_time_sec: 30, off_time_sec: 30, is_device_active: false qui donne respectivement, le pourcentage du cycle a On, le temps en secondes a On, le temps en secondes à Off, si le device est actuellement actif.
Normalement, on va avoir tout ce qui faut pour bien vérifier que ça marche.
Je teste en // chez moi et ça se passe bien. Vous pouvez y aller.
C’est génial !!
Alors j’essai de faire la mise à jour, tout est ok, j’ai rebooté, rechargé l’entité et tout mais j’ai un nouveau message d’erreur :
Si je vais dans l’état pour voir si il apparait les nouvelles données mais rien :
Ah oui même bug qu’au début 
. Je fixe (et définitivement cette fois)
edit: c’est fait. 0.2.beta4
Avec une consigne à 19° ca plafonne à 18°6. Y a eu qqes oscillations mais on venait de loin et avec l’intertie importante de mes radiateurs ca ne me parait pas choquant. Le fonctionnement est très proche de ce que j’avais ma fonction ATAN expliquée plus haut.
@Argonaute pour atteindre la consigne, tu me suggères d’augmenter le coef_c ou le coef_t ?
Si j’augmente le coef_c ca va osciller encore plus je pense.
Coef_c permettra d’ajuster la pente de montée en température. Coef_t doit compenser les pertes thermiques.
La montée en température me semble bonne, mais il manquerait le % de puissance sur la courbe pour contrôler.
Si tu arrives proche de la consigne mais ne l’atteins pas, il faut peut-être augmenter coef_t effectivement (pertes thermiques non compensées).
Si tu as des oscillations et avec de l’inertie sur les radiateurs, essaie d’augmenter un peu la période. Cela enlève de la réactivité et les diminuera.
@Argonaute En poussant le coef_t à 0.05 j’obtiens cette très belle courbe :
En jaune la target, en bleu la temp courante et en rouge le % de chauffe.
Quasiment pas de rebond et une belle convergence rapide.
PI : j’ai quasi fini la gestion de la présence avec un mode je change de preset en cas d’absence et un autre, j’ajoute un offset. Ca devrait répondre à ta suggestion @Argonaute
C’est génial ça !! As tu réussi à exposer le % comme attribut ou entité pour pouvoir l’afficher ?
Il faudra vérifier que c’est toujours bon quand il fera très froid dehors et plus chaud… On devrait trouver une méthode moins empirique.
Pour le mode absence, j’ai réfléchi et il faudrait 2 offsets :
Est ce bien cela que tu as en tête ?
Hello !!
Petit retour de mon coté ! Ca me semble parfait !! je l’ai mis en place depuis un peu plus d’1 heure, et pour l’instant cela fonctionne plutôt bien 
C’est génial ça !! As tu réussi à exposer le % comme attribut ou entité pour pouvoir l’afficher ?
Oui j’ai pu de mon côté récupérer l’attribut. Les 2 auraient été du luxe 
, mais dans mon cas, ce n’est pas gênant.
yep. j’en en profité pour mettre tous les attributs possibles et l’état des ouvertures, mouvements, presence, … On a tout pour bien mettre au point.
j’en ai fait qu’un. Sinon il va falloir un offset par preset et franchement je ne vois pas l’intérêt vs complexité du truc.
Si le but c’est toujours d’atteindre 17 qd y a personne (ma config), je préfère utiliser le preset « away » qui met à 17. C’est quand même plus simple. Mais j’ai certainement pas bien compris ton use-case.
La gestion de la présence est dans la release 0.2.beta6
Faut reconfigurer pour ajouter le capteur de présence et la config (preset ou offset). Je le teste chez moi en ce moment et pour moi c’est bon.
Si vous avez le temps de tester de votre coté, je prends.
J’attends un peu avant de releaser pour avoir plus de retour.
On a l’impression que tu n’atteindras pas le 21 en regardant les courbes. Si ca t’arrive j’ai passé le coef_t a 0.05 et ça marche mieux de mon coté.
Merci pour tes retours en tout cas !
Effectivement, je viens de le passer a 0.05. J’attends un peu plus de temps pour vérifier
Pour la release 0.2 beta 6, que voudrais-tu que je teste exactement. J’ai vu qu’il y avait ce nouveau panneau :
Il manque des traductions on dirait:
Le premier champ c’est le capteur de présence (l’entity id). Il doit être True si il y a qq’1 à la maison.
Ensuite tu choisis :
J’ai ça moi:
Pourquoi 1 par preset : il n’y en aurait que 2 (eco et confort).
Une seule température d’absence fixe serait bloquant pour moi. Il y a bien trop d’inertie pour réchauffer uniquement quand on revient à la maison.
Je vais essayer d’expliquer une nouvelle fois en prenant l’exemple du use case d’une chambre.
Je passe typiquement en absence quand je met l’alarme de la maison.
Actuellement j’ai une planification libre avec différentes températures quand on est à la maison (appelée confort dans mon cas), une autre quand on n’est pas à la maison (appelée eco/absence).
Typiquement pour la chambre, planification si on est à la maison :
Planification si on est absent :
Avec cette planification absence, comme je sais que l’on va à priori rentrer dormir à la maison, je commence à chauffer dans la soirée (19°C). Du coup, la maison est vraiment très confortable et n’est pas froide pendant 2 heures quand on rentre. On n’a jamais de sentiment de froid, sans pour autant surchauffer.
J’ai des logiques similaires avec les pièces de vie (cuisine, salon…).
Certes, avec les presets en dur, on perdrait déjà avec juste 2 températures possibles quand on est à la maison (on aurait juste eco et confort). Mais c’est encore acceptable.
Par contre avec avec une température unique en absence, on perdrait vraiment beaucoup en confort et la ce n’est plus acceptable.
On arriverait à régler le problème de la maison froide suite à une absence en détectant qu’on va revenir (calcul de la distance de la maison via le mobile), mais compliqué à mettre en place et pas forcément souhaitable en terme de traçabilité. Ou alors il faudrait le faire manuellement, mais c’est pénible.
Avec un offset absence sur confort et un autre sur eco, on est certes moins flexible, mais ce serait encore acceptable tout en étant simple.
Ree !
Alors coté gestion de la température, c’est parfait rien à dire ! tout fonctionne avec la formule de @argonaute. C’est génial, un grand merci à vous 2 !!
Concernant l’automatisation des différents modes présent, absent etc pour mon use case que je souhaite, qui à mon avis est différent du vôtre.
Je souhaiterais intervenir sur les modes confort (présent) et away (absent) depuis alarmo (il me demande une entité et / ou depuis une automatisation (entité aussi, mais peut-être via les attributs ?)
Hors je ne trouve pas comment intervenir sur ces modes là.
Et je trouve que finalement ça serait le plus simple afin d’avoir une intégration parfaite sur HA qui permettrait de mailler différents plugins.
Du coup est-ce que c’est faisable / ensisageable facilement ou pas du tout ?
Pour argonaute, en soit c’est ce que je fais, avec l’application et le geofencing. mais si tu ne souhaites pas « tracer » le ou les téléphones, effectivement, il faut trouver d’autres astuces.
ok, je comprends mieux. Y a 2 planifs qui sont exclusives et déclenchées en fonction de la présence ou non, ce qui n’est pas la même logique. Tu cherches a éviter de rentrer avec une maison froide et qqe-part tu préchauffes même si absent.
Je crois qu’on le peut faire sans soucis avec ce que j’ai fait, puisque c’est exactement ce que je fais pour les chambres:
Y a 4 preset possible pour les chambres:
Ca fait ta première planif chambre si présent.
Si absent tu changes de planification (ce que tu fais en utilisant d’autres préset):
En gros, tu as 4 températures (5 si j’ajoute le preset « sleep ») par thermostat, à toi de planifier le switch des presets en fonction de ton use-case.
Comme tu as l’air plus axé température que preset, tu pourrais même rester en manuel et piloter la température directement.
C’est sur que tu n’utilises pas la gestion de la présence intégrée au thermostat mais tu peux tout à fait faire l’équivalent. Ce qui est dommage c’est de garder un switch de planification hors thermostat. Je comprends. Ce qui me fait un peu peur, c’est que je pense qu’il y a autant de façons de programmer son chauffage que de personnes : rien qu’ici @frankb , @Argonaute , @mycanaletto et moi on a manisfestement 4 façons différentes de faire. Et répondre à tous les besoins, c’est faire une usine à gaz ; donc difficilement compréhensible par les users et inmaintenable dans le futur.
Avec un offset absence sur confort et un autre sur eco, on est certes moins flexible, mais ce serait encore acceptable tout en étant simple.
Après c’est pas non plus la mer à boire que de le faire, je suis d’accord avec toi. Mais si t’es en mode boost + absence il faudra bien définir un offset aussi, si je veux être générique et pas spécifique à ton cas ou tu n’as besoin que de Confort et Eco. Je vais regarder quand même, je sens que ca peut servir à d’autres : y aurait un offset par preset. Donc tu pourrais avoir une seule planification et c’est la gestion de présence qui applique l’offset du preset courant en fonction si absence. C’est pas mal quand même à la réflexion.
