Overkiz: climate entity "temperature" attribute not taking into account preset_mode.

jerry34ha commented 4 months ago

The problem

I configured the Overkiz integration with an Atlantic Cozytouch.

The target heating temperature can be set to a different value for Manual and Prog (i.e. schedule) mode per room.

However, looking at the resulting climate entity, I can see that the target heating temperature ("temperature" attribute) is always the Manual target, even when the "preset_mode" is "schedule".

What version of Home Assistant Core has the issue?

2024.3.0

What was the last working version of Home Assistant Core?

2024.2.5 works perfectly

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Overkiz

Link to integration documentation on our website

https://www.home-assistant.io/integrations/overkiz/

Diagnostics information

home-assistant_overkiz_2024-03-10T08-37-53.678Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

I see no error in the log. I see correct values for 
schedule: EcoHeatingTargetTemperatureState, ComfortHeatingTargetTemperatureState, TargetTemperatureState
manual: HeatingTargetTemperatureState

But it seems that no mater the preset_mode, the climate entity attribute "temperature" is set to HeatingTargetTemperatureState.

Additional information

No response

home-assistant[bot] commented 4 months ago

Hey there @imicknl, @vlebourl, @tetienne, @nyrodev, @tronix117, mind taking a look at this issue as it has been labeled with an integration (overkiz) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `overkiz` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign overkiz` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

overkiz documentation overkiz source _{^{(message by IssueLinks)}}

Tronix117 commented 4 months ago

Issue is that it's not really possible to set multiple temperatures at once on HASS entity. If we add a way to change the currently activated temperature through preset, it means you need to wait to be in the preset schedule to set the temp (wait for eco schedule to set eco, and wait for the comfort schedule to set comfort). In my opinion, comfort/eco temps should be set on the device itself if you want to use schedule. Because when you are using HASS, you can replace the device schedule with automation + manual on HASS.

I'm not sure if there is any need to support that here... (and if so, I'm also not sure about the best way to handle that)

jerry34ha commented 4 months ago

Thank you for your response. I must admit i don’t know about the internals of the application. What i think would be correct, would be something like: if preset_mode = schedule then Climate. Entity.temperature = ComfortHeatingTargetTemperatureState Elsif preset_mode=manual then Climate. Entity.temperature = HeatingTargetTemperatureState

of course, we would need to factor in Heating vs Cooling and Eco vs Comfort but you see the intent here.

it is not set the temperature, only to display it.

At least if all the variables above would be exposed, i could use templates to define my own target entity.

i think this used to work in the late 2023 release.

jerry34ha commented 4 months ago

I think i understand what you mean now. It shall not be allowed to set target temperature when the preset_mode is « scheduled ».

Tronix117 commented 4 months ago

I'll need to verify but I don't think it was working this way either in the late 2023 release. I think best way is to just disable when preset is set... another way would be to have multiple presets: "Comfort", "Eco", "Schedule". However I did not do that because there is no way (at least on my device", to manually select comfort or eco. I can however do it virtually, but it's more of a tacky way to do things

jerry34ha commented 4 months ago

I just tested with core 2024.1.6, 2024.2.0 and 2024.2.5:

2024.1.6, 2024.2.0 and 2024.2.5: preset_modes: eco, comfort, away, frost_protection, external, home temperature: the correct heat target temperature according to the preset_mode

2024.3.0: preset_modes: manual, schedule temperature: always shows the manual.

By the way, I have a Shogun Zone Control 2.0.

If I look how my physical Atlantic Thermostat (model 875074) work (resp. main thermostat):

When in "schedule" mode (PROG): pushing the down arrow (resp. turn the wheel counter-clockwise) sets the mode to Eco, pushing the up arrow (resp. turn the wheel clockwise) sets the mode to comfort. In both cases it sets the associated target temperature. I suppose it is a temporary bypass until the next scheduled mode switch happens.
When in "manual" mode: pushing up and down arrow (resp. turning the clock) changes the temperature by 0.5°C. Permanently.

eekamouze commented 4 months ago

Before 2024.3.0, I can confirm the displayed target temperature was the one corresponding to the preset mode: manual, schedule (and even derogated temperature for schedule mode)

Personaly, I find it very misleading to show the target temperature of the manual mode when you are in schedule mode

Tronix117 commented 4 months ago

I'll change that back. But do you think this should be editable ? Because it has big impacts on the overall system modifying comfort/eco temperatures... and the chosen preset is not this much shown without going to the detail (at least on base widgets)

eekamouze commented 4 months ago

Well this is my opinion but yes I think it should editable, at least for manual mode because it is the main purpose of this mode (I can admit it is a bit less useful in schedule mode). Regarding the presets display, I add it on the card because i find it is missing otherwise (edit / add functionnalities / presets). Btw it is missing icons there, but nevermind that's just cosmetic!

Tronix117 commented 4 months ago

Missing icons should be in another PR and should be generic enough to handle all climate device, so that will be later.

For manual of course always editable, but for preset temp edition, I'm still not sure, let's wait a bit to see others opinions.

jerry34ha commented 4 months ago

If I look at how my own Zone Control works, it is not possible to change the target temperature from the thermostat when in Schedule (PROG) mode. Which makes sense as setting the target temperature is done in the room settings (where comfort and eco temps are set).

So to mimic this behaviour, I would suggest that this is not editable either. In terms of usability, it would prevent that we change the overall Comfort/Eco set points forever by mistake.

As I wrote above, trying to change the temperature on a physical thermostat while in Schedule mode acts as a toggle between Comfort and Eco preset. Nice to have on the widget but I guess I could create a button to set the preset_mode ?

Tronix117 commented 4 months ago

@jerry34ha I also worry about accidental change on those temps.

(For the toggle between Comfort and Eco, you'll indeed need to do it with a button, the whole discussion here is to how it should be handled with what climate entity in hass provides. The quick-switch should be a separate discussion.)

jerry34ha commented 3 months ago

I'm closing the issue because this is not a bug, it is a design choice for the component, which changed a lot since 2024.2.4

home-assistant / core