Atlantic Cozytouch Zone Control 2.0 | Irrelevant thermostat card display and usage

eekamouze commented 3 months ago

The problem

Since core 2024.4.0, the overkiz integration has changed noticeably the way things are presented in the default thermostat card for zone control 2.0 HVAC (see #111830). I found several points that look irrelevant to me:

Whatever the mode (heating, cooling or auto) it shows a thermostat card with both heating and cooling temp values (with orange and blue curves on each side). This should be relevent only when auto mode (heat/cool) is set. Otherwise it should be only heating (orange curve) or only cooling (blue curve)
Heating or cooling state (with gradient color in the background) is wrong. I don't know where this state comes from as I don't think it is provided in any way but it doesn't reflect the real state of the zone.
Temperatures displayed are always the ones from manual mode even in schedule mode

What version of Home Assistant Core has the issue?

2024.0.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Overkiz

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 3 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 3 months ago

We discussed a bit about that in your previous issue #112602, I explained the limitations of the devices there. On my first PR, there was this comment: https://github.com/home-assistant/core/pull/110510#discussion_r1506872895 by @MartinHjelmare, advising me to not change the HVACModes during the lifetime of the entity, I find that it made sense, and it simplifies a lot the logic. This device being kind of complex already.

Like I explained previously: zone-control allows for the set of cooling and heating separately. When your device supports the cooling, and heating, zone should be able to set cooling as well as heating temperature, no matter the current HVAC mode on the main device. If your device only support heating, you will have a heating card.

I'm open to any suggestions, I plan anyway to better support those devices on the long run. However those ideas and suggestions should be viable technically.

Temperatures displayed are always the ones from manual mode even in schedule mode

Already discussed and explained there for the reason of that: https://github.com/home-assistant/core/issues/112602#issuecomment-2015776534 Support may improve over time, but ATM, I'm afraid it's more of a feature request, and it needs to be specified in a viable hass way.

Heating or cooling state (with gradient color in the background) is wrong. I don't know where this state comes from as I don't think it is provided in any way but it doesn't reflect the real state of the zone.

It's a valid point, I found this weird behavior too in my tests. The device send the active cooling/heating profile as well as the ON/OFF state of the Zone. However to get the latest updated value, a manual refresh must be triggered on the device (but if made too often, may cause the "Too many requests" issues), anyway, it's an ongoing discussion for a wider implementation of that. Nevertheless, even with a manual refresh, the device does not refresh the ON/OFF state correctly or fast enough (or maybe I misinterpreted it). At the moment, I have no solution to provide, except disabling entirely the active state.

jerry34ha commented 2 months ago

I support the OP comment. I even opened #112875 because I thought that 2024.3 had broken the component. I closed it now that I understand that it was a design decision.

I understand that all the work behind this component is achieved by benevolent contributors on their spare time, so please see this as user feedback, not a complaint or criticism.

I was very confused by 2024.4 because it displays 2 target temperatures on the same UI component, with the highest temperature being called "low" and the lowest being called "high". I'm still trying to find a use case where my room would be heated to 20°C and cooled down to 26°C at the same time ;-) Also, the system cannot be heat and cool at the same time. I will automatically switch states when in Auto mode, that's all. (In terms of usability, I'd rather use a toggle to show one target at time than showing both at the same time).

Since 2024.3 I cannot verify any more the PROG mode (Eco, Comfort) nor the actual target temperature (as it shows always manual), which is very important on Tempo Red days: I want to check on my dashboard that I'm not heating the house too much.

So I'm staying with Core 2024.2.4 at the moment.

Thank you again for all the effort and time you put in this component.

Tronix117 commented 2 months ago

I'm open to suggestions, the current behavior is also not of my liking.

However I think you misunderstood something about the heat-cool device, it's not "at the same time", it is just to set the dead zone between heating and cooling when in auto mode.

I could change it back so that this widget only show heat_cool when main device is in Auto mode. However if I do that there will not be any way to set the cooling temperature if we are in heating mode and vice versa (that is not much to my liking).

Then about your target temperature, I don't know what to do because like I explained before, targetTemperature on the device is not synced with the two cool/heat temperature we can set. I'll look again to see if I missed something...

jerry34ha commented 2 months ago

Using 2024.2.4, I made some tests to figure out how this is working.

"Shogun" means the main zone control configuration "Thermostat" means the configuration per room "Physical thermostat" is the actual device that is attached to the wall in my home office

Entity	State/Attribute	Value	Equivalent on Cozytouch
Shogun	State	heat	chauffage
		cool	rafraichissement
		auto	auto
		off	arrêt
		dry	déshumidification

Entity	State/Attribute	Value	Equivalent on Cozytouch	Comments
Thermostat	State	heat	manuel	"heat" is displayed even when Shogun is in "cool" mode.
		auto	prog	I changed the state to « manuel » on the physical thermostat. I turned off the heating on the physical thermostat. I then used the HA widget to choose « Auto ». This did not turn the physical thermostat on. However, when I manually turned on the physical thermostat, it was in « Auto » mode. So I guess on/off and heat/auto should be 2 different controls.
		off	arrêt	The state never changed to off. This is probably because in/off and heat/auto are 2 different variables.
	Preset_mode	Eco	Eco
		Comfort	Confort
		Away	Absence	Even though I used the physical thermostat to put the Shogun in Away mode, this was never reflected on the attribute state. Probably the « away » mode is a property of the Shogun, not the thermostat.
		Frost_protection	?
		External	?
		Home	?
	Temperature	Target temperature	Target temperature	This works well: it gets the correct target temperature based on the Preset_mode/state (manuel, prog eco/comfort, off)
	Current_temperature	Temperature as measured by the physical thermostat	Temperature as measured by the physical thermostat	Works great.

Some suggestions (I have no idea wether this is feasible or not):

Thermostat on/off and heat/auto should be 2 different controls/attributes
"Away" should be a state or attribute of the Shogun. I suppose Shogun "Away" state ignores all thermostats settings and will heat the house to 7 or 8 degrees.
It seems that the "Away" mode is not displayed on the secondary physical thermostat (heat/auto, comfort/eco and target temperature don't change) so either the HA entity behaves the same or it inherit the Shogun state.
When the Shogun is in "Away" mode, I can still change the secondary thermostat settings (heat/auto, comfort/eco and target temperature). So the thermostat entity could behave the same (i.e. whatever the Shogun state, the thermostats can be controlled). Of course, it is up to the physical Shogun to actually act on those settings depending on its mode.
When the thermostat entity is in "auto" mode, it should be possible to change the preset_mode to Eco or Comfort.
When the thermostat entity is in "auto" mode, it should not be possible to change the target temperature. This is to prevent making a permanent change to the target temperature of program. Target temperature override should be done by manual mode or by going to the settings and changing the target temperatures (see below)
Eco and comfort target temperatures (for heating and cooling) should be 4 independent thermostat entities.

I hope this helps.

jerry34ha commented 2 months ago

I update a test machine to Core 2024.5.1 and I can see:

Manual/Schedule and heat/off are 2 different controls. Great.
Away mode has been removed from the thermostat. Great (could be added to the Shogun but I use this once a year so not really important to me)

What is missing:

When in schedule mode, the target_temp_high and target_temp_low should be the Eco or Comfort mode (depending on the scheduled mode) target temperature, not the manual targets.
As written previously, it shall not be possible to change the Eco/Comfort target temperatures (climate.set_temperature shall do nothing).
It should be possible to see which schedule mode is currently set: Eco or Comfort.

Without this we cannot achieve even the simplest automation: switch to Eco mode at 8:30 and back to Comfort mode at 17:00 when back from work.

All right, I think I repeated myself enough :-) I hope this finds a friendly ear and some magical thing happens to free contributors time !

Tronix117 commented 2 months ago

Hello Jerry, I had no time to work on that recently, but it's still on my mind, and I will get back to it ! Thanks for your work ! However, please understand this device as some serious limitations I already explained before... For instance the heat info while off, is just the value sent by the device... Biggest issue is that states needs to be manualy asked to be refreshed (and even then it's not immediate), and refreshing of all relevant states for each device is too much for the overkiz integration to accept within a short period of time (ratios), so it needs to be spread over a longer period of time. It's not yet supported by this integration, but I plan to work on this.

It seems you saw my modifications in the 2024.4.0 version, I'm glad it's better for you, while not being better at the same time for the original author of this thread 😄, hard to content everybody !

For your last remarks, I still need to work on those presets, but right now, you already shall not be able to change eco/confort temperatures, it only changes manual temperatures, I guess you thought it was changing it, because we still let you change that while on preset. Here we are some options:

when in eco/confort, changes of temperatures are disabled (but it changes widget config, that's not much advisable)
when in eco/confort, changes of temperatures makes it switch back to Manual (no preset)
when in eco/confort, changes of temperatures, changes the actual eco OR comfort temperature depending on the mode

I don't like the third option, and I'll check if first one can be implemented easily.

jerry34ha commented 2 months ago

No worries, I know the situation.

Option 1: is the closest to the physical thermostat behaviour.

Option 2: Although it is not mimicking the physical thermostat behaviour, it makes sense (temperature override shall not change the default programs).

Option 3: Like you, I don't like option 3 either because it would make what is probably meant to be a temporary override a permanent change.

How about the climate.set_temperature service ? which temperature does it set ?

Tronix117 commented 2 months ago

The set_temperature, I mapped it this way:

if device only support heating: it uses the given value and set the HEATING_TARGET_TEMPERATURE on the device
if device only support cooling: it uses the given value and set the COOLING_TARGET_TEMPERATURE on the device
if device support cooling and heating: it uses two value (from the HEAT_COOL mode of the widget), the higher one goes to COOLING_TARGET_TEMPERATURE and the colder one goes to HEATING_TARGET_TEMPERATURE

Then the device uses those temperatures and set its own TARGET_TEMPERATURE when the mode is manual. (TARGET_TEMPERATURE can only be set directly by the real thermostats, not through the API)

If the thermostat is touched manualy, then the TARGET_TEMPERATURE changes but not the HEATING/COOLING_TARGET_TEMPERATURE, that's why syncing is hard to do when the thermostat is changed...

home-assistant / core