Using the internal temperature option, but to prevent heating when over target.

[t0mb080]

Firstly, thank you for making such an excellent thermostat integration. I have aircon units but the internal temperature control is terrible, so your integration is extremely useful.

I have checked the option to use the internal temperature of the units to 'force' heating when it is required which solves the problem of the internal temperature sensor heating up and turning off the heat even though room temperature is below target. However, the internal control of the unit is so bad that I also have the same issue in the other direction, i.e. when not calling for heat. For example, the target temperature is 20, the room temperature is 21 so VTherm sends a target to the unit of 20 or similar but the unit starts heating anyway! Is there a setting to somehow fix this, i.e. send a very low temperature when no heating is required to prevent erroneous heating?

Maybe one way to do it would be to have an option to treat the control over climate more like a switch and just specify a very high target number (e.g. 30) when VTherm detects heat is needed and another very low target (e.g. 6) when heat is not needed just to guarantee the unit is in the right state?

[t0mb080]

An alternative scheme, which I think would be really useful for AC units with extremely poor self-regulation would be something like the logic below. Would you consider adding a mode like this? Or maybe adding parameters to the expert regulation such that this could be achieved with the right parameter choice?

Thanks again for a great extension.

def calculate_heating_action(current_room_temperature, target_room_temperature, is_heating_state, offset=5, threshold=0.25):
    '''
    A simple controller which forces the climate entity into a heat or not heat state using an offset around the heating target.
    Used for climate entities with very poor self-regulation to reliably force them into a heating or non-heating state.

    The threshold parameter defines a band around the target temperature such that it only starts or stops heating if it's moved
    outside the band to prevent constant switching on or off.
    '''

    if is_heating_state:
        # in heating state, check whether we should turn off
        if current_room_temperature > (target_room_temperature + threshold):
            is_heating_state = False
            climate_entity_target = current_room_temperature -  offset
    else:
        # not in heating state, check whether  we should turn on
        if current_room_temperature < (target_room_temperature - threshold):
            is_heating_state = True
            climate_entity_target = current_room_temperature + offset

    return is_heating_state, climate_entity_target

[t0mb080]

You can see the issue graphically below. See that the VTherm target in yellow does a good job of ramping up high to force the heating on, which then drags the room temperature (red) up to the desired temperature (green). However, see what happens at around 16:50, the desired temperature is reached so VTherm reduces the target to the underlying in yellow but because of the poor regulation of the underlying AC system it's not low enough because it fires up again (see blue line which is temperature of the actual AC) even though it's over target.

[jmcollin78]

Hello @t0mb080 ,

Your graph is very interesting and shows the job done by VTherm self-regulation with 'use internal temperature' checked.
What I see here around 16:50 is pretty good, the temperature is decreasing, very near the target, so the heater starts to heat but for a very little time (one minute ?).

Regulation and self-regulation should be look over a long period to see if it converge or not. Sadly we do not see in your graph what happens after 16:54, but I suppose we will have small variation around the target.

For me this is what is expected and you will not have better result with a pure On/Off algorithm as you propose.

If you want to experiment it, you can always create a virtual switch that implements your logic (there is example in the readme) and create a over_switch Vtherm with this virtual switch.

[t0mb080]

Thanks very much for the reply @jmcollin78.

You are right in that the self-regulation generally does converge after it's up to temperature, but it can take quite a while because the underlying continually fires up every ten minutes or so which sends the temperature above target but eventually the integrated error accumulates high enough to force the target low enough to keep the heating off. I suppose my fundamental question is why is the "use internal temperature" option asymmetric, i.e. why does it act to force heating but not act in the opposite way to prevent heating? The internal regulation of my underlying is equally bad in both directions sadly!

I did consider specifying it as a switch as you suggest (after all it really is a binary device, i.e. so-called bang-bang control in essence, just through the added complication of the temperature targets) but I couldn't work out how to achieve the other features you get with the climate control - most importantly getting the units to actually turn on and off when needed, either manually or by scheduler.

[jmcollin78]

why does it act to force heating but not act in the opposite way to prevent heating?

It works in both way.
If the current_temp is 20, internal_temp is 15 (-5 delta) and target is 19, then the regulated_temp will be 20 - (20-19) - 5 -> 14. And the device shouldn't heat (14 vs 15). The compensation is always applied and so works in both way

[t0mb080]

Ah, I see. In that case, I suppose the resulting 1 degree offset just isn't severe enough to force my units into the correct state. To use your example of a 15 internal_temp and a 14 regulated_temp, I completely agree that the device shouldn't heat under these conditions but sadly mine actually frequently does in this scenario! I don't know why, maybe there's some additional logic in there, or a hidden temperature offset that's not viewable externally. I'll keep playing with it to see whether there's some configuration I can use to really force it into the state the VTherm thinks it should be in.

[t0mb080]

Here's an example of the behaviour I mean. Here you can see that the room temperature (red) goes over target (green), with the internal temperature (blue) showing that the unit is still periodically firing out heat even though the regulated temperature (yellow) from VTherm is below target. You can see that over a period of three hours or so, the integrated error eventually drives the regulated temperature (yellow) low enough that it forces the heating off so the self regulation does work, it's just it would work much more efficiently if it sent a lower target to force the heating off sooner so it didn't rely on the error integration to force the target low enough.

[jmcollin78]

Have the strong regulation activated ?
If no, try it, you are clearly in the case of the strong regulation need + use internal temp.

If yes, you should maybe try much higher regulation to go down more quickly. There is a chapter on this subject on the README documentation: https://github.com/jmcollin78/versatile_thermostat/blob/main/README.md#self-regulation-in-expert-mode

You can try this values:

kp: 0.5
ki: 0.08
k_ext: 0.0
offset_max: 8
stabilization_threshold: 0.1
accumulated_error_threshold: 80

[t0mb080]

Thanks very much @jmcollin78. I am using the strong regulation but I'll give the expert mode a try and look at the values you suggest.

[t0mb080]

I'm wondering if something is actually wrong. See the plot below where I've used the same colour scheme as previously but I've added the regulated temperature as provided by VTherm in purple. I was expecting this to match the yellow which is the actual target reported by the underlying. Have I misunderstood or is something actually wrong here?

[t0mb080]

The purple regulated temperature looks very sensible, falling as the room temperature (red) goes over target. However, the link between that and the actual target that gets fed to the underlying (yellow) isn't at all obvious, and the system is firing up the heating from 1710 to 1800 even though the regulated temperature is much lower than target throughout this period. Is the offset being applied correctly here? I notice the blue (underlying internal temperature) updates and changes much more frequently than the regulated and target being sent to the underlying (yellow), is this the cause of the mismatch?

[t0mb080]

Here's another example of the same thing. The regulated temperature (purple) looks very sensible but it doesn't translate through to the actual target sent to the underlying (yellow) because the internal temperature offset just can't cope with the fast swings in the underlying temperature so it ends up still pumping out heat and overshooting even it's well above target and the regulated temperature well below.

Possible solutions I can think of are:

1. Increase the sample rate of the adjustment to keep up with the underlying. I don't think this is a good idea as it would feed out very fast changes in set temperature which may be an issue for the physical unit, and also possibly for the API the underlying could be using.

2. Have an option to make the internal offset option asymmetric. This might work as it seems very effective at forcing heating on but much less effective at getting the heating off and preventing the kind of overshoot seen in my plots. All the implications might be hard to predict though and it might have some weird behaviour where the target and actual are close so it flips states?

3. Play further with the expert regulation parameters? As I understand it, this probably wouldn't work as it would affect the regulated temperature (the purple line in my plots). However, this is already very good, the real issue is the translation of that line to the actual target fed to the underlying through the internal termperature offset mechanism.

4. Add an option like my proposal in the second post. I realise this is a very basic control scheme but it would also be extremely robust and as long as the offset was set high enough it would work even with large swings in the underlying temperature like I've shown with my units. It could be a great fallback option for units with problems like mine - which I don't think are that uncommon, these are standard Panasonic AC wall mounted units with (unfortunately) the internal temperature sensor in the unit itself which causes it to swing around wildly as it heats.

I'd love your input @jmcollin78 and if it helps convince you that (4) would be a worthwhile addition to your great integration then I'd be very willing to make a decent donation!

[jmcollin78]

Hello is something strange in your graph.

Why is the TV room target in yellow (I think it is the internal target of the device) not following the regulated temperature (in purple) ?
This should be the case, because the regulated temperature is send to device as target temperature. There is something not working here which explains the overheating period (cf. screenshot)

[jmcollin78]

Yes it seems good. Do you have activated the expert mode regulation ? (In VTherm configuration)

I'm looking the code on my side.

Here is my I have on my side:
configuration.yaml:

versatile_thermostat: !include versatile_thermostat.yaml

versatile_thermostat.yaml:

auto_regulation_expert:
  kp: 0.4
  ki: 0.08
  k_ext: 0.0
  offset_max: 4
  stabilization_threshold: 0.1
  accumulated_error_threshold: 40
safety_mode:
  check_outdoor_sensor: false

try to put only 2 blank for indentation. I see you have 6 blanks. Maybe it is the issue

[t0mb080]

Ah, I have, but only in one thermostat - do I have to switch them all to expert mode for it to work?

[jmcollin78]

All VTherm that you want to be in expert mode for sure. Not more.

Do you have seen this: try to put only 2 blank for indentation in your configuration.yaml. I see you have 6 blanks. Maybe it is the issue

[t0mb080]

It wasn't the spaces. However, I restarted the whole home assistant and it magically started working.

Thanks very much, I'll play with the expert parameters and report back.

[jmcollin78]

Thank you for the beer ! I just receive them. It is very pleasant 👍

[t0mb080]

Ok, I've done some initial playing with some fairly encouraging and interesting results. One thing to note, is that in order for VTherm to correctly update the expert parameters in the configuration.yaml, it seems to require a complete restart of Home Assistant - neither reloading the yaml, nor reloading the VTherm integration seems to do it. I don't know whether this is expected, or is specific to my setup - I'm running in docker if that makes any difference to anything.

Anyway, I've turned the internal temperature compensation off as you suggested because it's clear that it can't cope with the big and frequent swings in my units internal temperature which was causing the overshoot we saw previously. This means that I have to rely on very big gain in the self-regulation to force my units to reliably either heat or not heat to overcome the big swings in internal temperature. My initial experiment at this has been to simply set the kp value to 5.0(!). This actually works quite well as you see below. When the heating comes on at 8am, the error is big enough to basically force the unit to constantly heat to quickly get to target by about 0830. It then keeps it quite well at target, although it does involve quite big swings in the regulated temperature to do so and with some oscillation.

This is much better than it was as it is able to quickly get to target and not overshoot too much. I do still think adding a 'threshold' parameter to the expert regulation such that it doesn't update the regulated temperature when it's within +/-threshold of target might be a valuable addition as it would enable high gains without swinging around when close to target which would reduce the frequency of the heating cycle and therefore maybe increase efficiency and reduce wear on the heating units.

[jmcollin78]

neither reloading the yaml, nor reloading the VTherm integration seems to do it

You have an option in Development Tools / Yaml to reload all VTherm configuration. This should reload also the configuration.yaml:

You have a very stable and nice regulation curve !. Small oscillations around target, stable current temperature, ... really fine.
May I take it as an example in my README file ?

I do still think adding a 'threshold' parameter to the expert regulation such that it doesn't update the regulated temperature

There is already thresholds in expert mode: stabilization_threshold and accumulated_error_threshold
Have you try to change the stabilization_threshold which was designed for what you need (if I understand well, but I'm not totally sure).

[t0mb080]

Thanks @jmcollin78, yes, of course you may use it as an example. I think it's a good example to have, because it shows where an alternative approach to the internal temperature option is needed where the internal device regulation is very poor.

On the configuration reloading, that is where I tried to reload it from (see screenshot below) but the changed parameters only seem to take effect when restarting Home Assistant itself.

On those thresholds you mention, the accumulated_error_threshold seems to just be a cap for the integrated error (i.e. the bit multiplied by the ki parameter) applied in the code below:

versatile_thermostat/custom_components/versatile_thermostat/pi_algorithm.py

Line 81 in 60bd522

# Capping of the error

On that stabilization_threshold, the docs seem to imply that the integrated error will be reset when it's within the stabilization_threshold. However, I'm confused by this, because I can't find anywhere in the code that actually applies this logic or uses this parameter? Instead there's some logic that reduces it when it crosses through zero:

versatile_thermostat/custom_components/versatile_thermostat/pi_algorithm.py

Line 76 in 60bd522

if error * self.accumulated_error < 0:

Whilst we're on the subject of the integrated error term, one thing that slightly confused me is that the error integration/accumulation doesn't scale by the time difference? Surely this means that the more frequently the regulated temperature calculation runs, the faster the integrated error accumulates? What controls how frequently the calculation runs?

The threshold I was suggesting isn't specific to the integrated error at all. It's simply a line of logic at the end that says that if the difference between the target temperature and the room temperature is less than the threshold, simply don't update the regulated temperature at all.

[jmcollin78]

ok I see. You are refering to the regulation_threshold which designed exactly for this:

"Seuil de régulation" in FR is "Regulation threshold" in EN.

[t0mb080]

Ah, I thought that was just the minimum increment between regulated temperature changes.