radiator valve stuck in loop ("changed to heat / turned off / … triggered by service Climate: Set HVAC mode") until HA reboot #121
Comments
|
Maybe related: With an Aqara E1 thermostat, I can trigger an infinite loop switching back and forth between two target temperatures when manually switching mode on the thermostat hardware several times. I don't really understand what happens here, but it can be stopped when deactivatimg the integration. |
|
(Edit: the link I came across which I thought might be related is most likely not related) |
|
@maia, this is a vert bad news. and another time when switching off a thermostat and the response was 'on' with hvac_action = 'idle'. If I look more closely to the logs, what is relevant is that: So the underlying is changing without VTherm command I think. If yes, this is the issue: and so on. |
|
@jmcollin78 Good thought, but as Eve Thermo devices are Homekit/Thread only (and not Matter), they can only be paired with one smart home system. I'm currently gradually removing these thermostatic valves from my Apple Home setup, resetting them and then repairing them with Home Assistant (as Homekit Device, they have no native integration). As the issue mentioned above appeared with a thermostatic valve that was added to Home Assistant only 30 minutes earlier, I don't even think there is a way it might have ended up being controlled by another Home Assistant integration. All I did was adding it as Homekit Device to HA, creating a VTherm device, then adding it to a scheduler-component and then a simple thermostat card. And 30 minutes later I tried turning it off via the UI (as it's too warm outside to heat) and the issue started. |
|
I will think about a security to avoid this when its happens. This is quiet dangerous or very annoying when its happens. Waiting for an eventual fix, I suggest you to remove the VTherm and the underlying climate from export to Homekit. |
|
I have made some test with climate in HA and in Homekit, it is working as expected. |
|
Neither the thermostatic valve nor the VTherm device are currently exported to Apple Homekit, so excluding them will most likely not help. As mentioned, here is my setup:
That's all I did, and as soon as I tried to change the preset/temperature from the lovelace UI, the on/off loop started. |
|
And I can easily trigger the issue by clicking a few times on the simple thermostat card, changing the temperature and the presets, turning on/off. I clicked like 5 times and the loop started. Reloading the device in the integration didn't clear the loop, I had to reboot Home Assistant. Here's the simple thermostat config: type: custom:simple-thermostat
entity: climate.schlafzimmer_heizung
layout:
step: row
mode:
names: true
icons: false
headings: false
header:
name: Schlafzimmer
sensors:
- entity: binary_sensor.badezimmer_oben_heizung_window_state
name: Window |
|
Update, I think I can now reproduce the issue: The loop starts when changing the target temperature, the preset or the heating/off switch "too fast" in the control of the versatile thermostat device. It doesn't matter if I make the changes from a simple-thermostat card, from the lovelace UI or from the integration device overview. As soon as I make about 5 changes within 2-3 seconds, the loop starts. The loop can be stopped by disabling the underlying TRV device and reenabling it. When making the same changes in the underlying TRV device, the problem does not appear. Only when making too many quick changes in the versatile thermostat device, the loop starts. From my testing, it makes little difference if I change the preset, turn the binary heat/off switch on/off or change the temperature. After clicking a few times (like pressing "+" five times in a row to go from target temp 22,0° to 22.5° and then pressing "-" again for 3 times to go back to 21,0°) the loop begins, e.g.:
I think that whenever the TRV is still changing the valve position to switch to the new target temp, it will get stuck when you already change it to another target temp. But I have no explanation why this is only an issue when controlling it via VTherm. There is no problem when making exactly the same changes from the underlying Eve Thermo TRV device. |
|
Here's a 900KB debug log of about 45 seconds time with a stuck loop which I triggered by quickly changing the temperature as described above. It has 137 occurrences of "Checking new cycle", so 2-3 cycles per second: vtherm debug 231013.log. |
This will definitively helps me to reproduce to case (+ the logs) |
|
Cannot reproduce on my test env and neither on my prod env (my home). My logs are the followings: I will compare with your logs. I'm now pretty sure it is a specific behaviour with your TRV thermostat. |
|
Ok having a rapid look i can see that the TRV is answering to command in 6 sec approx. During this time, you have clicked almost 3 times on temperature change: You send the 21.0 target temp at 18:09:19: And this is not "normal". If you look at my logs, the "underlying climate changed" log is in the same second. So I guess this is the reason why it is not reproductible (and until now you are the only one with this problem). EDIT : this is not a reason to loop indeed |
|
Hmm, well clicking 6x in 3 seconds happens when you see the thermo is set to 21°C, you decide you want it warmer, so you click 3x the "+" to 22,5°C, then decide that it's a waste of energy and you'll revert back to 21°C, so you click 3x the "-". Boom, 6 clicks in 3 seconds. (And as mentioned, when doing this directly on the hardware itself or on the HA underlying thermostat device, it's not an issue. Only when doing this in the VTherm device it is an issue. Thanks for looking into it! |
|
In my case I can reproduce the behavior (if it's the same) when clicking my Aqara Thermostat directly on the hardware 3x in a row, which is the sequence used to start a valve calibration. Seemingly this three fast clicks are interpreted somehow by VT and cause confustion. |
|
Ok, I got exactly the case (for @maia at least). This is a side effect of the #101 issue and the #113 issue that were released in the last version when the response of the underlying is slow. The scenario is the following:
If response of the underlying is instantaneous, you don't have this effect because the target temp of the underlying is equal to the target temp of the VTherm and nothing is done by VTherm. Fixing this is tricky (without removing #110). I will to see with your logs if i can ignore the target of underlying when a manuel change have been made after. I'm sure I will have all the dates to do that. |
|
I have published a pre-release with more logs to see if I can use the event dates to filter "late" events coming for your underlying climate. Can you please, install it, redo the procedure to reproduce the bug and send me the log you have. Don't worry, I have commented the #101 which causes the loop. Thank you ! EDIT: It is there: https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.5.3.beta4 |
|
Using 3.5.3beta4 I managed to recreate the bug, it got stuck in a loop again. Maybe it took a bit longer, but here is the log, I hope it's useful: |
|
I need also non WARNING logs. |
You mean I should enable debug logging? Because the above part is the only thing showing up in my HA logs. Maybe there's a way to change the log level to info, but I'd need to check how, I'm running the default. |
|
Here's a log with debug set for the integration and info for everything else. It's a minute long. Until about 15:55:22 I manually clicked and changed the target temp and switched heat/off a few times, then the loop started. Near the end of the log I disabled the underlying TRV: VTherm loop 231014.log |
|
I see in another thread that you don't have the INFO log level ? But above you gave me logs with debug level (hte 900 kb logs). So I guess you known how to change the log level. |
|
@maia I have a good new for you. With your last log, I think I found a way to avoid loops. @Ra72xx I suggest you to install also the 3.5.3.beta6 and do the procedure (click 3 times). I have tested on my home and it is working fine (but I don't reproduce the loop). If it works you should see some log like this: |
|
Just q auick first "thumbs up": I had no time to enable and look into the logs, but "my error" seems not to occur anymore with the beta version. |
I will wait for @maia feedback and then I will release the fix. |
|
Great news: I cannot reproduce the issue anymore. Jean-Marc, thanks a lot for all your work. (I've actually bought you some beers a few days ago, I'm seeing a transaction on my Apple Pay, but you didn't receive it. The support team is looking into what happened and will hopefully fix it on Monday) |
|
I just push the release ! 3.5.3 which officialize the fix.& Thnak for the beer, I really appreciate. Cheers from France ! |
|
When playing around with the hardware thermostat, I noticed that some adjustments done manually with the knob (to be honest, some quickly done up/done regulations) were not implemented (seemingly reverted) after a few seconds. I assume that is a side effect of the fix? |
Yes. Exactly, I discarded some events when it comes just after a manual change (and so avoid the loop). The delay is 10 sec. |
Version of the custom_component
I'm running the latest VTherm version 3.5.2, all other integrations and HA have no available updates either.
Configuration
climate.schlafzimmer_eve_trv (the underlying radiator valve controlled by versatile thermostat):
climate.schlafzimmer_heizung (the versatile thermostat service):
Describe the bug
After creating a Virtual Thermostat for a Eve Thermo Homekit Device and a simple thermostat lovelace card, when switching the preset in the UI the thermostat valve started turning on/off/on/off/on/off as fast as it could, until its battery was nearly empty and I rebooted HA. Other than the reboot of HA I couldn't find anything to stop this loop.
As this happened to me a week ago with a different virtual thermostat, this seems to be a more frequent issue than initially expected, at least in my setup.
Here's everything I could find that might be relevant to debugging the issue. I might be able to reproduce it, it was just a very bad timing when it happened.
Debug log
Logbook of the VTherm device:
Logbook of the underlying Eve Thermo TRV (thermostatic radiator valve):
Versatile Thermostat debug log while the TRV turned on and off constantly (I can provide more if necessary):
Homekit Device debug log (one cycle, this continues endlessly too)
TRV configuration
The text was updated successfully, but these errors were encountered: