Does Off not mean Off?

[benzo8]

I may well be missing something, but it seems to me that, when my VThermostat is set to Off (and it correctly turns my equipment off), if the temperature passes the threshold the equipment will turn back on again. Ideally, I want to be able to turn the Thermostat off, not just the equipment - can this be done without disabling the entity every time?

[jmcollin78]

Hello @benzo8

but it seems to me that, when my VThermostat is set to Off

No, when the VTherm is off, it will never turn on again until you command it or a schedule turns on explicitly.
There is no automatic turn on in VTherm.

I want to be able to turn the Thermostat off, not just the equipment

That is exactly what VTherm does. It turns off the equipment (switch or climate or valve) and turns itself off.

What kind of VTherm do you have (over climate or over switch or over valve) ?

[benzo8]

That's what I would have hoped, but the behavior I'm seeing isn't so.

Here, the VThermostat was manually turned to Off at 23:00 and then it turned itself back on three times during the night. (I was awake, so I turned it off again each time once I noticed.) And again, the 8:45am and 9ish turn-ons were weird. Later this morning I tried setting the Target Temperature to 16 so it wouldn't cross it and you can see at just gone 11am it turned on again.

I have a climate set-up, and it works fine when it's one and doing its thing, but I can't trust it to stay off at the moment!

[jmcollin78]

The VTherm doesn't do that it self, but it follows the underlying climate state.
What I suppose is that, you underlying climate starts alone. Do you think it is possible ?

Can you please post the attributes of the VTherm with this behaviour ? It is available in Development Tools / States.

EDIT : look also if you don't have an automation or a scheduler running in the background

[benzo8]

underlying climate starts alone. Do you think it is possible ?

Well, all I can say is that it never has before. Up until now I've had my AC and Radiators connected to homeassistant's standard Thermometer widget without issue. I suppose it's possible that one of the devices has some momentary false-start-up situation which the default widget ignores but VTherm picks up on?

lounge.climate is a Sensibo device, lounge.climate_radiator is a Rointe radiator device. The main reason I'm looking at VTherm is its ability. The temperature source is a min_max average combination of those two devices.

There is no scheduler. Though I have the scheduler installer as recommended by your readme, I disabled it as soon as this issue became apparent to remove it from the equation.

[jmcollin78]

I suppose it's possible that one of the devices has some momentary false-start-up situation which the default widget ignores but VTherm picks up on?

I have never seen that before but it is possible. So you have an over_climate VTher
m with two base climate (underlying climate). The configuration seems good. This could the first or the second which awake. Maybe you can suppress one to see if its happens again.

I have a look at Sensibo because I don't know what it is and here is what I see:

Maybe this is a good explanation of what happens. You try to remove it from VTherm config to see if it is happening again.

The main reason I'm looking at VTherm is its ability. The temperature source is a min_max average combination of those two devices.

I don't understand what you are trying to achieve with this. What is a temperature source ? Is that the temperature of the room ? Don't you have any temperature sensor ?

[benzo8]

Thanks for giving your time to look at this.

I don't understand what you are trying to achieve with this. What is a temperature source ? Is that the temperature of the room ?
Don't you have any temperature sensor ?

I don't have a separate temperature sensor - the Sensibo is, in effect, a temperature sensor which then controls my dumb AC using IR. It sits on the opposite side of the room to my radiator, which also has a built-in temperature sensor (ie: thermostat). I use the min_max to average those two sensors, as otherwise, what's been happening before is the radiator heats up its corner of the room and the switches off before the heat makes it across the rest of the space, and vice-versa (to a lesser degree) with the AC.

With this VTherm set-up, I'm getting a pretty even heat throughout, which I am very much enjoying!

Maybe this is a good explanation of what happens.

That's a configurable function, and I have it off, preferring home assistant to control things. And it worked fine before VTherm!

This could the first or the second which awake. Maybe you can suppress one to see if its happens again.

I will do this, removing one and then the other from the VTherm configuration and try and ascertain whether one of them is for sure at fault. Then maybe we can try and find why it's doing so...

[benzo8]

OK, after some testing with a couple of different set-ups, including a number of different devices:

I can say the following with confidence:

1. It's the Rointe integration
2. It doesn't happen with either the built-in(to homeasssitant) Themostat, nor the Simple Thermostat from HACS.
3. It doesn't appear to be related to crossing back over the target line in Versatile Thermostat

I can make the following suppositions:

1. The Rointe integration is, at some point, sending a signal/state which VTherm interprets as the device being manually switched on, and as such it goes through it's processes and sends out it's current calculated target temperatures to all connected devices, thus switching them all on.
2. The signal/state the Rointe device is sending is not and On signal, as this would turn on one of the other Thermostats, which it doesn't not.

I will contact the Rointe integration's author to see if he has any ideas, but I'm hoping that you can help narrow things down by suggesting what VTherm might be listening for that it interprets as a change-in-state even when it's in its own Off state.

Thanks!

[jmcollin78]

If you set the VTherm into INFO log, you will have the exact event received. This could help for diagnostic. Le lun. 6 nov. 2023, 20:33, benzo8 ***@***.***> a écrit :

…

OK, after some testing with a couple of different set-ups, including a number of different devices: I can say the following with confidence: 1. It's the Rointe integration 2. It doesn't happen with either the built-in(to homeasssitant) Themostat, nor the Simple Thermostat from HACS. 3. It doesn't appear to be related to crossing back over the target line in Versatile Thermostat I can make the following suppositions: 1. The Rointe integration is, at some point, sending a signal/state which VTherm interprets as the device being manually switched on, and as such it goes through it's processes and sends out it's current calculated target temperatures to all connected devices, thus switching them all on. 2. The signal/state the Rointe device is sending is *not* and On signal, as this would turn on one of the other Thermostats, which it doesn't not. I will contact the Rointe integration's author to see if he has any ideas, but I'm hoping that you can help narrow things down by suggesting what VTherm might be listening for that it interprets as a change-in-state even when it's in its own Off state. Thanks! — Reply to this email directly, view it on GitHub <#159 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANCB5UA7EGXJLQIXEA4IA3YDE3O3AVCNFSM6AAAAAA65RWHVCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TIOJRGQYDM> . You are receiving this because you commented.Message ID: <jmcollin78/versatile_thermostat/repo-discussions/159/comments/7491406@ github.com>

[benzo8]

OK, so this is what comes up in the log:

2023-11-07 11:49:43.578 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - Regulated temp have changed to 21.0. Resend it to underlyings
2023-11-07 11:49:44.446 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - Underlying climate changed. Event.new_hvac_mode is off, current_hvac_mode=off, new_hvac_action=None, old_hvac_action=None
2023-11-07 11:49:44.898 WARNING (MainThread) [custom_components.rointe] Ignoring Rointe device of type acs
2023-11-07 11:49:44.901 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - Underlying climate changed. Event.new_hvac_mode is heat, current_hvac_mode=off, new_hvac_action=heating, old_hvac_action=off
2023-11-07 11:49:44.901 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - underlying just switch ON. Set power and energy start date 2023-11-07T11:49:44.899262+01:00
2023-11-07 11:49:45.517 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - Underlying climate changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=heating, old_hvac_action=heating
2023-11-07 11:49:45.809 INFO (MainThread) [custom_components.versatile_thermostat.thermostat_climate] VersatileThermostat-Lounge V - Underlying climate changed. Event.new_hvac_mode is heat, current_hvac_mode=heat, new_hvac_action=None, old_hvac_action=None

It goes without saying that I did nothing manually.

[jmcollin78]

Hello @benzo8 ,

1. What means the warning message:

WARNING (MainThread) [custom_components.rointe] Ignoring Rointe device of type acs

2. what we can in the log is this message (just after the warning message) :
   ... Underlying climate changed. Event.new_hvac_mode is heat, current_hvac_mode=off, new_hvac_action=heating, old_hvac_action=off

This means that the Rointe has change its hvac_mode to heat alone. A short moment before it sends the same message with hvac_off.

After VTherm receive two other message saying that the Rointe was up again (but it was already up).
Because VTherm is listening and interpreting this message, it will not work as expected with such an equipement. Very sorry for that.

[benzo8]

What means the warning message: Ignoring Rointe device of type acs

I think that's because I also have a Rointe Water Heater device on my network which the homeassistant integration doesn't support

Because VTherm is listening and interpreting this message, it will not work as expected with such an equipement.

This is disappointing, because in every other way, VTherm is exactly what I'm looking for, and works spectacularly well!

I guess this all comes down to my headline question - how off is Off? Taking your original stance, that "...when the VTherm is [O]ff, it will never turn on again until you command it...", I'd argue that the equipment (erroneously) changing state is not me commanding it. If VTherm is listening for signals still, and prepared to turn on when it receives one, Off is not quite as off as I assumed!

But I wonder if this couldn't be a configurable option: allow the user to choose between: 1) the current, existing behaviour where VTherm can be controlled either by the card, or from the equipment connected to it, or (2) "In Off mode, VTherm will never turn on again until commanded from the VTherm card ONLY. So when it's in Off mode, it just ignores signals from the equipment, and waits for the user to actively and intentionally reactivate it? (Or, be reactivated by Scheduler, I guess.)

[jmcollin78]

...when the VTherm is [O]ff, it will never turn on again until you command it...

yes you are right, the correct sentence is:

...when the VTherm is [O]ff, it will never turn on again until you command it or you command the underlying directly...

The goal is to take care of users which are using directly the TRV to switch on or change target temperature. The VTherm will listen to this state changes and adapt itself to the new required state.

If the underlying Rointe turns on but this was not expected, the VTherm will follow this new state without beeing able to distinguish a real turn-on and a wrong one. In my opinion, there is maybe a feature in the Rointe to never turn-on automatically not ?

[benzo8]

there is maybe a feature in the Rointe to never turn-on automatically not ?

I don't think it's actually turning on. At least, the equipment isn't, and if it weren't connected to VTherm there'd be no sign anything was happening. Whether it's a glitch in the equipment itself, or in the Rointe Integration, I don't know. I'm still hoping the author of that integration will have something to say on the matter.

The goal is to take care of users which are using directly the TRV to switch on or change target temperature. The VTherm will listen to this state changes and adapt itself to the new required state.

I understand this. I just wonder if there might be some mileage in giving the user the option to limit this behavior so as to allow Versatile Thermostat to connect to more equipment (including badly behaved equipment), and ultimately making VTherm, well, even more versatile!

[jmcollin78]

I just wonder if there might be some mileage in giving the user the option to limit this behavior so as to allow Versatile Thermostat to connect to more equipment (including badly behaved equipment), and ultimately making VTherm, well, even more versatile!

Not in short terms because I have a lot to do with "normal" behaved equipment and it will add some others options which begans to be a little complex (more than 60 options are available and there is many misunderstanding at now).

I don't think it's actually turning on. At least, the equipment isn't

What is sure, is that the Rointe is sending this state change to VTherm. You can send this to the Rointe integration builder if needed.

[jmcollin78]

I will wait some days and after I will add the Rointe into not compatible equipment for VTherm.

[benzo8]

Not in short terms because I have a lot to do with "normal" behaved equipment and it will add some others options which begans to be a little complex (more than 60 options are available and there is many misunderstanding at now).

I'm not sure that 1/61 makes a great deal of difference, given that this is Versatile Thermostat, not Simple & Easy Thermostat! It could even be a yaml, not UI, option, given it's set-once-and-forget.

I might look at this myself, in that case - would you accept a Pull Request if I can sort it?

What is sure, is that the Rointe is sending this state change to VTherm. You can send this to the Rointe integration builder if needed.

I have already done so, but sadly the maintainer doesn't seem to be as on-the-ball as you are, so far at least!

I will wait some days and after I will add the Rointe into not compatible equipment for VTherm.

Will this mean it won't work at all, as in Rointe devices will be blacklisted from even being added to VTherm? Because, if so, I'm going to very strongly request that you don't do that. It works perfectly, 100% of the time, when one wants it to do its job. It's only when it's off that there's an issue, and, most likely as it gets colder I'll just be setting it to Eco at night rather than wanting to turn it off at all. It would feel a little intentional to be punished for raising an issue by being cut off entirely from VTherm...

[jmcollin78]

Will this mean it won't work at all, as in Rointe devices will be blacklisted from even being added to VTherm

No this is not a blacklist because I'm not able to detect the underlying model but just a warning in documentation so that people will know the behaviour is not optimal. Before buying sometimes people checks if the hardware will fit their need. So there are warned.

It would feel a little intentional to be punished for raising an issue by being cut off entirely from VTherm

Really not :D. On the contrary I thank you for the warning and the investigations.

[jmcollin78]

The message I put into documentation:

4. Thermostats of type Rointe tends to awake alone even if VTherm turns it off. Others functions works fine.

[benzo8]

So, I've finally had some time to look at this. It seems that Rointe devices turn on when a new regulated_target_temp is sent and they are in HVACMode.OFF. As a test, I've wrapped a brute-force condition around that part of _send_regulated_temperature in thermostat_climate.py thusly:

        self._regulated_target_temp = new_regulated_temp

        if (
            self._hvac_mode
            not in [
                HVACMode.OFF,
            ]
        ):
            _LOGGER.info(
                "%s - Regulated temp has changed to %.1f. Resend it to underlyings",
                self,
                new_regulated_temp,
            )
            for under in self._underlyings:
                await under.set_temperature(
                    self.regulated_target_temp, self._attr_max_temp, self._attr_min_temp
                )
        else:
            _LOGGER.info(
                "%s - Regulated temp has changed to %.1f but HVACMode.OFF is set. Not sending to underlyings.",
                self,
                new_regulated_temp,
            )

And this has stopped the devices from turning on during an Off period. As far as I can tell, it doesn't affect the behaviour of any of the other functionality, and as the new_regulated_temp is still being calculated and recorded - just not being sent to the devices if they're off - I don't think this breaks anything in the background either.

Now, of course, I need to make this configurable. My first point of consideration is whether this should be a global setting or per VTherm Device. Then, configuring a flag "OffMeansOff" (or similar!) which can also be part of the condition above should make this change transparent to anyone who doesn't need it, but useful to those of us who do, right?

[jmcollin78]

I agree with you, who want to send temperature to an off device ? What is the use case ?
I think your proposal should be directly usable as is.

I will test and integrate that for a future release.

[benzo8]

Thank you - until then I'll keep applying my patch to updates as I don't think I can live without Versatile Thermostat now!

[tggm]

Hi @benzo8

What exactly happens when regulated_target_temp is called? I mean, what's the target device (the rointe integration) expected to do, and what is being called on rointe\climate.py ?

Also, could you please turn on debug logs ? (custom_components.rointe: debug) and check if you get any useful logs for that scenario.

Thank you

[tggm]

Could this be caused by Versatile sending a temperature value to the rointe heater? Because if you call set_temperature on the rointe integration it will turn the radiator on (the example below is from the rointe-SDK here)

def set_device_temp(self, device: RointeDevice, new_temp: float) -> ApiResponse:
        """Set the device target temperature."""

        if not self._ensure_valid_auth():
            return ApiResponse(False, None, "Invalid authentication.")

        device_id = device.id
        args = {"auth": self.auth_token}
        body = {"temp": new_temp, "mode": "manual", "power": True}

When I was implementing this I was interpreting "setting a temperature" as a signal by the user that the radiator should also be turned on. (and in this case also set to manual mode).

Also, please keep in mind that the Rointe API is not always cooperative. Their devices are managed by a Firebase API (essentially a large JSON DB) and the way of interacting with devices is to make REST calls to set values.

There are multiple attributes that need to set together for the intended action to succeed (mode, power, temperature, status). If the device doesn't like it it will revert to an unknown state. That will then be picked up by HA during the next update.

I've been painfully trying to iron out the quirks of how Rointe devices operate. This integration is a new scenario for me so I have to debug it. Logs would be useful.

Please try to update to 1.5.0-b0 (beta version under HACS) and turn on debug logs for rointe. That has more bugfixes that came from this PR review and may help. If needed I could try adding more debug statements for the rointe integration.