[Feature Request] Option to use local_temperature_calibration offset for self-regulation

[0verEngineer]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

• The self-regulation works by adjusting the target temperature on the thermostats which can be confusing because then they display a wrong target temperature
• It seems way easier to have a boolean to allow self-regulation with the local_temperature_calibration variable, just re-calculate and re-set the variable every time the external temperature sensor or the internal one change the temperature

Describe the solution you'd like

• Add a boolean if one wants to use the local_temperature_calibration instead of the current self-regulation that edits the target temperature
• The boolean switch can (if possible) be hidden if the TRV does not have a local_temperature_calibration

Describe alternatives you've considered

• There is no alternative besides the current self-regulation which has some drawbacks

Additional context

• Here is the discussion i found: https://github.com/jmcollin78/versatile_thermostat/discussions/494
• I opened this FR as an Issue instead of commenting on the discussion because i think it is important to use the local_temperature_calibration for this because that is the reason it exists and a developer who wants to contribute will not look through the discussions but the issues
• Here is a screenshot of the variable in homeassistant:

[maia]

Which TRV exposes this specific variable? The tricky thing is that the vendors name these differently, usually it has „offset“ or „calibration“ in its name. Ideally vtherm would identify these (by regex or a lookup table for most common TRVs), otherwise users will have to enter the variable in the config.

[0verEngineer]

• This is a Tuya TS0601 (_TZE200_p3dbf6qs)
• Ok if this thing can be named differently by vendors the user should just be able to select it if he turns this feature on

[0verEngineer]

Another discussion about this: https://github.com/jmcollin78/versatile_thermostat/discussions/342

It seems the Author don't want this, but for TRV's that have this settings this is just the correct way to do it and the current solution is just a workaround.

[hilburn]

I'll have a think about how to implement this in a fairly universal way and see if I can make a PR for him

[maia]

Variables used, taken from: https://www.zigbee2mqtt.io/supported-devices

local_temperature_offset: Ubisys Hi regulation_setpoint_offset: Danfoss Ally, Hive Radiator, Popp Smart Thermostat local_temperature_calibration: Sonoff TRVZB, Avatto TRV06

For ZHA devices and probably also Matter the default seems to be local_temperature_calibration. So I guess this is the most common variable name.

[maia]

@hilburn In case you're very motivated, would you be interested in enabling the offset feature in the Matter implementation for Eve Thermo TRVs? It's visible in Matter Server: "Endpoint 1 > Thermostat > LocalTemperatureCalibration" but not accessible yet in HA.

[hilburn]

I'm afraid I don't know anything about matter setup so not able to help with the latter.

I should be able to query the trv device the climate is inside and find matching offset entities. We'll see how it goes

[maia]

This is exciting news.

[jmcollin78]

It seems the Author don't want this, but for TRV's that have this settings this is just the correct way to do it and the current solution is just a workaround.

No, it is a very good solution if you are able to make it generical. I don't want to over-complexify but with a simple and universal solution, of course I'm ok. This solution avoid to display a wrong temperature (the regulated temp) to the user. This is a great enhancement.

@OverEngineer It seems that in your case, this is a separate entity of type number. So the only way I see it to configure the number entity. I don't see how I could find it automatically.

EDIT: how should this offset calculated ? internal_temp - room_temp or room_temp - internal_temp ? Does someone know ?

My point is that I will not be able to test this IRL, I don't have device with calibration.

[jmcollin78]

@hilburn ,

I should be able to query the trv device the climate is inside and find matching offset entities. We'll see how it goes

I'm pretty sure you cannot do that. device is not an object in HA but only some attributes in entities.

[hilburn]

@hilburn ,

I should be able to query the trv device the climate is inside and find matching offset entities. We'll see how it goes

I'm pretty sure you cannot do that. device is not an object in HA but only some attributes in entities.

You can get the device id for the climate entity from the device registry helper Then the entity registry helper can give you every entity for that device - you then just need to look for ones that match some offset/calibration strings

You can even get it working in templates

[jmcollin78]

ok fine. But how to select the right number entity (if there is many number entity in the device) ?

[hilburn]

By only searching for certain suffixes - there are a few that @maia referred to above in https://github.com/jmcollin78/versatile_thermostat/issues/595#issuecomment-2453001332 That is what that template used to filter out all the unrelated valve_opening/closing_degree and frost_protection number entities - without even checking for numbers it also filtered out the switches and battery sensors etc There's not much reason why a device would have multiple entities that fit those suffixes - but you could narrow it down further as they all follow the format climate.entity_name -> number.entity_name_suffix. If that have 2 that fit it quite so precisely, they've probably done it just to mess with the integration as it would require adding the entity maually through something like pyscript as you can't generate number entities easily though yaml config or the ui - and that solidly falls under "not a bug, don't be a dick" An alternative would be making a registry of the models and entities associated with them, but that seems like a lot of work for very little gain

[hilburn]

As for how to actually apply it: The offset that is currently calculated and applied to the set point temperature should instead be applied to the offset entity as a negative value

Current behaviour:

1. Calculate some offset based on self-regulation and internal temperatue - room temperature
2. Set underlying climate temperature to VTherm + offset temperature

Offset behaviour:

1. Calculate some offset based on self-regulation and internal temperatue - room temperature
2. Set underlying climate temperature to VTherm temperature
3. Set offset to -offset

Another difference is that the temperature set point of the climate doesn't need to be updated when the offset changes - which happens much more often than the VTherm target temperature changes

[maia]

I find a simple regex for searching for the suffixes the best solution. It's possible that someone will mention a device that's not yet supported, but then all that's necessary is adapting the regex. A database feels like way too much work to maintain, as there are hundreds of TRVs out there.

[jmcollin78]

By only searching for certain suffixes - there are a few that @maia referred to above in ...and that solidly falls under "not a bug, don't be a dick"

this make sense the only caveheat I see is that entity_id can be modified by user. I often localize my entity name to have it in French (I'm not the only user). Power is puissance, offset is décalage, ... So no need to be "a dick" to make the algo failed. I wonder if we should rather ask the user what is the entity name. As an optionnal field. If not given by to try to use offset, if "use internal temp" is checked -> set offset as room_temp - internal_temp (as today). This seems quite simple and universal. That makes one more parameters in the already complex self-regulation configuration. Maybe we should organize the self-regulation page differently: in a separate configuration page. Let think about how to organize this page if you think it is relevant.

An alternative would be making a registry of the models and entities associated with them, but that seems like a lot of work for very little gain

Me alive, this will not happens 😉

[jmcollin78]

As for how to actually apply it: The offset that is currently calculated and applied to the set point temperature should instead be applied to the offset entity as a negative value

Current behaviour:

1. Calculate some offset based on self-regulation and internal temperatue - room temperature
2. Set underlying climate temperature to VTherm + offset temperature

Offset behaviour:

1. Calculate some offset based on self-regulation and internal temperatue - room temperature
2. Set underlying climate temperature to VTherm temperature
3. Set offset to -offset

Another difference is that the temperature set point of the climate doesn't need to be updated when the offset changes - which happens much more often than the VTherm target temperature changes

yes but we should keep the regulated temperature. Today sent temperature is regulated + offset. Tomorrow, set calibration in the dedicated entity, set setpoint to regulated. The regulated temp helps to reach the target.

[hilburn]

I think it makes sense to keep regulation and offset bundled together tbh - another config setting!

[jmcollin78]

I think it makes sense to keep regulation and offset bundled together tbh - another config setting!

yes. I will think how to present the regulation configuration. Maybe next week, I will have some time.

[maia]

I often localize my entity name to have it in French (I'm not the only user). Power is puissance, offset is décalage

I can understand using other languages for the device name, but you also manually localise the automatically assigned suffixes for the entities for a device? Oh wow, that sounds like lots of work, I think I currently have 1000-2000 entities.

[0verEngineer]

Something to consider for this feature is that some (if not all) thermostats have a maximum and minimum for the offset/calibration variable, the TS0601 Tuya Thermostats i have allow a maximum of 9 in every direction, but i also have 2 TS0601 Tuya Thermostats (newer ones) that have a maximum of 10, i know there are also some with have it at 3.

[jmcollin78]

Sonoff TRVZB have -12 offset also. It will be a supplementary mess if it not possible to get the min and max in the entity itself. Is that the case ?

[0verEngineer]

It seems they don't have a variable for the min/max in the state but somehow homeassistant knows that it is +-9 for my thermostat, see here:

here is the state from zigbee2mqtt of one of my TRVs:

{
    "battery_low": false,
    "child_lock": "LOCK",
    "current_heating_setpoint": 23.5,
    "frost_protection": "OFF",
    "last_seen": "2024-11-15T18:07:54.657Z",
    "linkquality": 21,
    "local_temperature": 22,
    "local_temperature_calibration": 0,
    "running_state": "heat",
    "scale_protection": "ON",
    "schedule_friday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_monday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_saturday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_sunday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_thursday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_tuesday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "schedule_wednesday": "06:00/21.0 08:00/16.0 12:00/21.0 14:00/16.0",
    "system_mode": "heat",
    "error": null
}

For my TS0601 the local temperature calibration is shown like this in homeassistant:

[jmcollin78]

The number entity should have a min / max value set to 9, I guess.