Repository navigation
[Feature Request] - Implement a keep alive like function for over_climate #1501
Replies: 20 comments
|
Hello @MatthieuF44 , First a big thank for the issue description. All is there at the first time 👍 I've got one preliminary question : is that a new behavior ? If yes do you since when (a new release or something like that) ?
Does it mean it was not working with previous release also ? I just have done a new test in my house all is fine. I'm with release 8.1.1. If the attributes, I see that the presence is well detected (the sensor is working fine): So at first glance, it works (else you will have If I look at the logs I see that all is working fine: Presence has been set to off, and temperature is set to 17 which is the comfort away temperature. Immediatly after this change, there is another change in the "chambre parents": --------------------> NEW EVENT: VersatileThermostat-Thermostat Chambre Parents - Temperature changed to state 19.1 So for me all is fine, I don't see any issue. Why do you think there is an issue ? |
|
Hello, and thanks a lot for your detailed analysis and quick reply. To answer your questions: Is this a new behavior? No, the issue was already present with version 7.4.1. UI cards Yes, I have updated all VTherm UI cards at the same time as the upgrade. Why I think there is still an issue Even though everything looks fine in the logs, the behavior is not stable in real use. It doesn’t happen all the time, but:
To avoid overheating when presence changes, I’ve temporarily created an automation that forces any radiator still in comfort for more than 45 minutes to switch to away. Hypothesis It seems that VTherm sometimes fails to apply the preset change during presence transitions for Heatzy thermostats specifically. Thanks again for your time and for your great work on VTherm! 
|
I just release the 8.1.1. So i guess you talk about another release.
Yes I already heard about that. One contributor develop the keep alive feature for this case : VTherm will send the same command multiple time in over_switch but for over_climate i don't have anything like this. Maybe I will have to think about that in the future. So keep you automation, I think this is best solution while waiting for a Vtherm solution. I transform your issue into a feature request for implementing a kind of keep alive for over_climate. |
|
Thank you for your reply. Actually, I meant 8.0.0 and 8.0.1, not 8.1.1 — sorry for the confusion. Regarding the configuration: This morning I tested enabling keep-alive option (set to 2). With keep-alive enabled, I noticed that I no longer had proper regulation at all — regardless of whether presence was ON or OFF. So I disabled it again. I will try creating one thermostat in over_climate to test the behavior and compare. Thanks again for your help! |
|
Yes you are right. You use the over_switch to control a climate with personnalized command. I don't know exactly why you do that, and you should rather the over_climate directly as you propose in the previous message. The keep alive is for over_switch over a real switch. Not sure it will works for personallzed command. If command are lost this will not help to solve your issue and you have to keep your automation. |
|
I chose over_switch because the documentation seems to recommend this mode specifically for Heatzy devices. Quick start — Heatzy / Ecosy / similar climate entity Over-switch — personalized commands Based on these parts of the documentation, I understood that Heatzy should be configured using over_switch with personalized commands, which is why I set up my thermostats that way. But since you confirm that over_climate is more appropriate, I will try that configuration instead and compare the behavior. Thanks again for your support. |
|
I made some additional tests using over_climate, but unfortunately this mode does not fit my setup at all. In my installation, the Heatzy Pilote modules simply allow me to control my electric radiators remotely (via the Heatzy app or Home Assistant). Because of this, over_climate seems more suitable for devices that already embed their own thermostat logic, which is not the case here. Thanks again for your help. |
No the documentation is right. For Heatzy this configuration is recommended as a workaround because it works badly with |
|
@MatthieuF44 Hello, I come back after a while to close this request. May I then close this request ? Not sure a keep alive for |
|
Hello, Thanks for coming back to this. I wouldn’t say the issue is solved, but rather worked around. Initially, I used an automation that stopped heating cycles when they lasted too long. I’m currently testing another approach: I would also like to clarify one point: What I consistently observe is that when a problem occurs, it happens during setpoint changes, typically when switching between home and away (presence transitions) or vice versa. So for now, I’m mitigating the issue, but I haven’t fully solved it. Finally, I’d like to thank you and everyone involved for the time and effort put into VTherm, especially the work around the Auto TPI, which looks very promising. Thanks again for your time and for all the work done on this project. |
|
Ok, so I will tranform the issue into a discussion, so that we can continue to discuss if needed. |
|
I’d like to add a new observation that may help narrow down the issue. I tried to simulate my absence by using a global window sensor (input_boolean acting as a window open detector).
More precisely:
So in this case:
I captured the logs at the exact moment this happened and attached them to this discussion for reference. This seems consistent with what I previously observed: Thanks again for the follow-up and for moving this to a discussion. home-assistant_versatile_thermostat_2026-01-01T23-00-31.656Z.log |
|
Hello, I ran another test, this time by toggling the global house presence sensor. When I simulated the house becoming empty (presence OFF):
The affected Heatzy modules are:
All three were in comfort mode at the moment the presence changed, and none of them received the command to switch to away / off. This is consistent with my previous observations:
I captured the logs during this test and attached them to this discussion. This reinforces the idea that the problem is not random, but specifically linked to mode / setpoint transitions triggered by presence changes, where the command is sometimes not propagated to the underlying Heatzy entities. home-assistant_versatile_thermostat_2026-01-02T14-10-00.007Z.log |
|
Hello, comme tu as l'air d'être Français on va switcher en fr c'est tellement plus simple. Si oui ce sont les 2 pour lesquels il y a ce log : Après je vois un truc très bizarre: Ce -9999 comme température extérieure indique que le capteur extérieur ne donne pas de valeur (None en Python). Il faut au moins résoudre ça avant de chercher plus loin. |
|
Une autre idée, comme la fenêtre éteint le VTherm peut être que c'est ça qui empêche la commande de partir. Essaye de configurer ta détection de fenêtre sur Hors gel pour voir si c'est ça le soucis. |
|
Merci pour le retour, on peut continuer en français 👍 Pour préciser le contexte : le problème est présent sur l’ensemble de mes VTherm. Comportement observé
À propos de la température extérieure
|
|
Bonjour @jmcollin78 , Je reviens avec de nouveaux éléments capturés cette semaine, avec les logs DEBUG activés simultanément sur Observation principaleGrâce aux logs websocket, j'ai pu confirmer que lorsqu'un changement de consigne ou de mode intervient en cours de cycle de chauffe, VT interrompt le cycle en cours, recalcule, et si Voici la séquence exacte capturée le 2026-04-08 à 22h45 :
Le log websocket est sans ambiguïté : La condition qui déclenche le bugLe bug ne survient pas systématiquement : lors des cycles normaux où En revanche, le problème apparaît lorsqu'un événement externe interrompt un cycle en cours et que le recalcul donne
Dans ces cas, VT interrompt le cycle ( Conséquence observéeLors d'un incident réel (2026-04-07, 4h00–6h15), ce comportement a provoqué une montée de +2.8°C pendant 1h45 dans le salon (19.5°C → 22.3°C), car les deux Heatzy sont restés en
Ce que cela confirme par rapport aux observations précédentesCela rejoint ce que j'avais observé en janvier : le problème apparaît spécifiquement lors des transitions de mode (présence, fenêtre, consigne), pas en régime stable. Les logs websocket permettent maintenant de confirmer que ce n'est pas une commande perdue sur le réseau, mais bien une commande qui n'est pas générée. Configuration de référenceJe reste disponible si vous avez besoin de logs supplémentaires ou d'un test dans des conditions particulières. Merci encore pour tout le travail sur VTherm. |
|
Je reviens avec un log complémentaire qui permet d'élargir la condition de déclenchement identifiée dans mon message précédent. Nouveau scénario : la fin de cycle normale est aussi concernéeDans mon message précédent, j'indiquais que le bug survenait lors d'une interruption de cycle (changement de consigne ou de mode en cours de chauffe). Un nouveau log capturé ce matin (2026-04-11) montre que le problème se produit également lors d'une fin de cycle tout à fait normale :
La température a continué à monter pendant 1h21 sans aucune intervention de VT :
Conclusion mise à jourLa condition de déclenchement est donc plus large que ce que j'indiquais : dans tous les cas où Cause identifiéeDans if hvac_mode == VThermHvacMode_OFF or on_time_sec <= 0:
for under in self._underlyings:
if under.is_device_active: # ← le problème est ici
await under.turn_off()La condition if under.is_device_active peut échouer pour plusieurs raisons : Solution proposéeNe pas se fier à is_device_active dans ce contexte. Forcer l'envoi de la commande turn_off pour tous les underlyings quand on_time_sec <= 0 : if hvac_mode == VThermHvacMode_OFF or on_time_sec <= 0:
# Turn off all underlyings - FORCE turn_off regardless of current state
for under in self._underlyings:
await under.turn_off() # toujours envoyé
under._should_be_on = False
# Schedule next cycle evaluation
self._cycle_end_unsub = async_call_later(self._hass, self._cycle_duration_sec, self._on_master_cycle_end)
returnImpactLe bug survient à la fin normale d'un cycle et lors des interruptions de cycle |
|
Salut @MatthieuF44 Peux tu tester avec cette build: https://github.com/jmcollin78/versatile_thermostat/releases/tag/9.3.3 |
|
Hello @MatthieuF44 , Bon désolé, j'avais mal vu la première fois mais la soucis est connu: Ca ne fonctionne tout simplement pas. C'est expliqué dans la doc ici: https://www.versatile-thermostat.org/fr/docs/over-switch/#la-personnalisation-des-commandes 
VTherm n'a aucun moyen de savoir que le switch est actif puisque l'état ne réflète pas le preset sélectionné. La seule solution pour l'instant est d'utiliser un switch virtuel qui lui va tester le preset pour savoir si il est on ou off. Je vais supprimer cette partie de la doc. La solution qui fonctionnerait serait d'ajouter un template qui check si le sous-jacent est actif. J'ai fais ça pour le Solar Optimizer. |
Uh oh!
There was an error while loading. Please reload this page.
Version of the custom_component
8.1.0 and earlier versions
Configuration
My VTherm attributes are the following:
Describe the bug
Some of my VTherms do not update their preset according to the presence state, but only when the house becomes empty.
I read issue #1284, but my situation is different:
I am not using Sonoff TRVZB devices
I do not have the follow_underlying_temp_change option
My Heatzy modules cannot perform automatic frost protection, cannot detect window openings, and do not change temperature or preset by themselves
What I am trying to do
Use the global presence sensor (binary_sensor.maison_occupee) so that all VTherms switch between comfort, eco or away depending on occupancy.
What I expect
When presence switches from home → away, all VTherms should change their preset accordingly.
What I observe
Because my devices cannot change presets internally, and have no window detection, it does not seem related to the TRVZB behaviour mentioned in issue #1284.
I read the README and troubleshooting section but found nothing relevant to explain this behaviour.
I read the documentation on the README.md file and I don't find any relevant information about this issue.
Debug log
All reactions