Replies: 11 comments 34 replies
-
|
Hello @t0mb080 , Thank you for the report. To monitore the auto-start/stop feature, I have implemented this automation which report each decision taken by the algo. Maybe you can install it, then you will have a persistant notification at each switch. Please give the persistent notification when you think it is wrong: You can keep only the auto-start/stop part if you want but It can be useful to monitore others safety event from VTherm. Then you will have some message like this: which be easy to see if something goes wrong. You can also set the debug level for the auto-start/stop algo with this lines in the logger.yaml: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks very much @jmcollin78, I've now turned on that logging you suggested and isolated what I think is a problem. I'll try and explain it step by step below:
This does seem like a clear issue to me, surely the start/stop should only be active when the VTherm is meant to be on in the first place and not turn the VTherm on when it's meant to be off on the schedule? Two things occur to me that might help: A) Because the auto start/stop turns on and off the actual VTherm, you can't tell the difference between it being off because it's meant to be off, or whether it's off because the auto start/stop has turned it off and therefore it might come back on unexpectedly. A further issue here is that when the VTherm is off from the auto off, it's actually impossible to manually turn off? Wouldn't it be much easier if the VTherm stayed on, and the auto start/stop simply turned off the underlying climate instead? That way a genuine scheduler/manual off signal wouldn't get mixed up with the auto start/stop? It would be clear that when the VTherm was on but the underlying was off, it was because of the auto start/stop? B) When a VTherm is turned off, either manually or by scheduler, shouldn't the saved_havc_mode get reset to None so that it doesn't accidentally turn it back on again? Thanks again though @jmcollin78, this is a great integration. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @t0mb080 ,
I clearly understand your case and I had to thank you for the explanations. In a general manner, there could have conflict when features or human or scheduler turns off. This has been identified during the design phase (see: #585).
No this will lead to incomprehension. VTherm state and underlying state should be aligned each time (VTherm is following the underlying state).
You are right, when it is off (for what ever reason), it is impossible to turn it off again (capt'ain obvious is near us). I not totally convience it is really an issue. Since this feature, I never try to turn on/off my devices. I let the Vtherm do its life with the auto-start/stop feature. And that is the point I guess, why do you turn-on/off the device with the Scheduler ? What is the use case behind this need ? Since auto-start/stop feature, do you still need to turn-on/off with the Scheduler.
This is certainly what I should do (if I get the off event while the Vtherm is already off, i'm not of this). I should also remove the |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, I'm a bit confused @jmcollin78, the logging below implies that it's received the 'off' command but not changed the saved_hvac_mode? The problem is though, I'm not completely sure the beta release has properly installed. I did download it in HACS, and the code I see in the config directory does look like the one in the change with the new save_state code, but the version number still shows 6.6.0?? |
Beta Was this translation helpful? Give feedback.
-
|
I forget to change the version in the code. That is why you see 6.6.0. Yo uhave the correct version installed if you see thus log: The other method is to go to HACS, find Versatile Thermostat. You should see the correct release: 6.6.3.beta1 |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks @jmcollin78. In that case something isn't right as I have the correct beta installed but you can see from my logs that when it receives the 'off' command I don't get that "Change the reason to MANUAL and erase the saved_havc_mode" log entry and the saved_hvac_mode isn't changed? |
Beta Was this translation helpful? Give feedback.
-
|
Your OFF command have not been taken into account because too near of the previous one. This is a check to prevent loop.
This should work also if you click on OFF on your telecommand. But in that case, wait at least 10 sec before the previous command. This is the temporal filter to avoid loops. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if it that temporal filter is the issue but two of my VTherms came back on tonight after the scheduler had turned them off so something doesn’t seem to be as expected in that beta version. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to throw more issues in, but maybe it's worth some slower parameters? Or maybe some expert mode parameters, like for the self-regulation because below is a case where it was on 'slow' start/stop but it still started and stopped within two minutes. |
Beta Was this translation helpful? Give feedback.
-
|
Huuum, I have seen something like that but I was not sure. I will see how to tweak the parameters. |
Beta Was this translation helpful? Give feedback.
-
|
I create an issue based on your logs. |
Beta Was this translation helpful? Give feedback.
-
|
I have a similar problem. I'm using a schedule to change preset, never change them manually. Noticing that my HVAC started acting strange around the times when the schedule changed preset and that the preset attribute was then set to none. So I added a state listener for when the preset attribute was set to none, which can be seen in the debug entry at 22:04:02.730. This problem started when schedule changed preset from comfort (20C) to eco (19C) at 22:00:00. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, This log at 22:04:02 is the problem : The device change its target temperature to 21 itself (maybe someone change the target on the device itself). So VTherm change its own target to 21 and set preset to manual (None). That is a feature: VTherm follows the underlying changes. But 21 make the auto-start/stop think it must start, so it starts. and at 2024-11-11 22:04:04.186 it decide to stop (itself) if I understand correctly the logs. The device that changes its state alone are a big trouble for Vtherm. 75% of the issue are due to that and I'm stuck with those cases. |
Beta Was this translation helpful? Give feedback.
-
|
My underlying climate is an IR-transmitter that is connected to HA via network and only controlled by VT. So the problem is at Maybe it would be safe to assume that if the underlying climate reports what was expected then it is ignored even if it is >10s since last command? Or maybe if it was possible to tell VT that it has exclusive control to the underlying. |
Beta Was this translation helpful? Give feedback.
-
|
I'm actually seeing something almost identical in my system @carlolars. From the logs below the scheduler turns off the system at 0740, however in that same action it changes the target temperature from 19.0 (which was programmed by the scheduler) to 21.0 (I don't know why). Then when it starts up again from the scheduler at 1500, it changes from the 19.3 from the scheduler back to 21.0, which it claims is because "Underlying climate climate.xxxxs_room have changed." However, the issue is that I'm absolutely certain that the underlying climate did not change. There wasn't even anyone in the house at that time, there is no automation or schedule controlling it other than VTherm, and you can see it occurs exactly 10s after the VTherm schedule starts. I think there's some weird state/loop effect in the VTherms going on here that it thinks is from the underlying - is this possible @jmcollin78 ? |
Beta Was this translation helpful? Give feedback.
-
|
One more thing to note here, I am running the beta version, but auto start/stop isn't even enabled - I had to turn it off because it was still firing up the units after the scheduler had turned them off. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Thanks @jmcollin78, that should certainly fix it, at the cost of the loss of functionality. Do we know what actually causes the issue though? It must be some timing/state issue, or maybe that VTherm messages simply aren’t registered by the underlying which causes the next run of VTherm to assume the underlying has changed when it hasn’t? |
Beta Was this translation helpful? Give feedback.
-
|
i write some root causes in the issue #628 |
Beta Was this translation helpful? Give feedback.
-
|
Sorry @jmcollin78, I've installed 6.7.0 and all the issues still seem to be there for me. In the logs below the scheduler turns off the VTherm at 0740, however the logs seem to indicate that it's the underlying climate that has turned off and VTherm is responding to that?? Then at 11:18 I turn the auto start/stop feature back on, and the VTherm immediately fires up with an auto start despite it meant to be in off mode from the scheduler? |
Beta Was this translation helpful? Give feedback.
-
|
will have a look this week-end. Why do you think the restart is wrong ? |
Beta Was this translation helpful? Give feedback.
-
|
Because it was manually turned off at 11:36. |
Beta Was this translation helpful? Give feedback.
-
|
I've looked through the code and maybe found the issue @jmcollin78? The code below resets the saved_hvac_mode if an off command is received when it's already off. However, I can't see any code that resets the saved_hvac_mode when it's been switched manually (or by scheduler) from on to off? Maybe this is the cause of the problem in my logs? |
Beta Was this translation helpful? Give feedback.
-
|
You are in the |
Beta Was this translation helpful? Give feedback.
-
|
I suppose you don't have the correct setting for logs. You should have something like that (else you will miss some logs): |
Beta Was this translation helpful? Give feedback.
-
|
Hello @t0mb080 , I will try to synthetize the case because this thread begins to be confusing. I forget the earlier message, and I will concentrate on the last one.
Is it correct until here ? If yes:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks very much for looking at this @jmcollin78, this is a complex system with a lot of state management going on so I know it's not easy. Yes, I do seem to see that behaviour you describe, however, the more immediate issue is that it was manually turned off, but the saved_hvac_mode wasn't reset so it auto started back up again. To start with, I'm on 6.7.0 and my logger settings are below which I believe is correct, and why I do see INFO messages in the logs below. From the logs below the VTherm is manually turned off at 11:36 but still auto starts back up at 12:08. The log message at 11:36 still implies that it turned off because the underlying climate changed though. I find this strange, as it was definitely the VTherm itself that was manually turned off, not the underlying climate. Is this a clue as to why it failed to reset the saved_hvac_mode? From the code below it only seems to reset the saved_hvac_mode when manually turning off and already off. I can't see where in the code it would reset the saved_hvac_mode when manually turned off from an on state? Is this the issue? However, a further issue is that I've never actually seen that "Change the reason to MANUAL and erase the saved_havc_mode" log message appear, I can't trigger it even if I replicate the precise conditions where it should trigger (and I tried on both the beta release and 6.7.0). I think the first issue described above is easier to fix though, and maybe fixing that will also fix this issue in some way. |
Beta Was this translation helpful? Give feedback.
-
Si your log is not correct and you don't see the set_havc_mode logs. This was a partial log to ficus on auto_start/stop. Now you should change with what I suggest above: |
Beta Was this translation helpful? Give feedback.
-
|
Ah.... sorry @jmcollin78 I hadn't noticed the difference in the log statement. I'll change it now. The issue remains the same, auto start comes back on after it's been manually turned off but I'll try and capture the full log output to try and help work out why. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, new example of the same issue with the log settings exactly as you asked for @jmcollin78. VTherm manually switched off at 1805, but auto start/stop still turns it back on at 1820. |
Beta Was this translation helpful? Give feedback.
-
|
ok. So, the set_hvac_mode is now called with off. Can you please check the attributes AFTER the auto-start/stop turns off and BEFORE you manually turn off. You should see: What I though is that the VTherm was not off when you turn it off manually. That is the only explaination. |
Beta Was this translation helpful? Give feedback.
-
|
But that's exactly the problem here, the |
Beta Was this translation helpful? Give feedback.
-
|
It seems my last comment was lost. In one word, ok I finally understand the case. The procedure was wrong till the beginning:
That is why I couldn't reproduce the case. We should not reset the saved_hvac_mode when turning_off because it is used to toggle the Vtherm state. But the correct solution is to check whether the VTherm was off due to auto-start/stop before turning it on again. I have created a new issue to fix that. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
You can try this directly in your code if you want: ** thermostat_climate.py line 924 :
|
Beta Was this translation helpful? Give feedback.
-
|
Great, thanks @jmcollin78. Sorry, I was trying to explain but it’s difficult to precisely describe sometimes. |
Beta Was this translation helpful? Give feedback.
-
|
No worry (and on my side it is sometimes very hard to understand) |
Beta Was this translation helpful? Give feedback.
-
I love the new auto on/off functionality, seems like a great feature so I turned it on to try.
However, I'm seeing some very strange behaviour when my thermostats are meant to be off. They are controlled by the scheduler component recommended in the docs but now they seem to be turning themselves on and off randomly through the day, when they're meant to be completely off. Even stranger is that sometimes it turns on at random times in heat/cool mode when the scheduler only ever turns it on in heat-only mode. My questions are:
How do you tell the difference in state between the thermostat being off because it's been manually turned off, or turned off on a schedule versus when it's been automatically turned off by the algorithm and therefore might come back on again? Is this reported in the entity or sensor in some way? Without this it's quite hard to know what's going on.
Is there potential for some strange interaction between schedules and the auto on/off? Imagine you have auto on/off on, the thermostat turns on because it's scheduled, then it's automatically turned off by the algorithm, and then the schedule turns it off. If the thermostat is already off (from the auto algorithm) when the scheduler is meant to turn it off, does that mean it might automatically turn back on again even though it's scheduled to be off? Could this be the cause of the weird turning on and off I've been seeing?
Thanks to @jmcollin78 and anyone else that might be able to shed light on this.
Beta Was this translation helpful? Give feedback.
All reactions