Improve Legrand 064882 cable outlet heat mode

[piitaya]

Proposed change

Following #2807

Expose multiple entities :

• device mode enum to choose between "Pilot wire" mode and "Switch" mode.
• pilot wire mode to choose the heat mode (device mode should be set to "Pilot wire" mode

The pilot wire mode should be replaced by a climate entity but it requires some work on zha library.

Additional information

Checklist

• The changes are tested and work correctly
• pre-commit checks pass / the code has been formatted using Black
• Tests have been added to verify that the new code works

[codecov]

Codecov Report

Attention: Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.85%. Comparing base (e3d3849) to head (7c55e1e).

Files with missing lines	Patch %	Lines
zhaquirks/legrand/cable_outlet.py	96.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #3031      +/-   ##
==========================================
- Coverage   89.85%   89.85%   -0.01%     
==========================================
  Files         322      322              
  Lines       10380    10385       +5     
==========================================
+ Hits         9327     9331       +4     
- Misses       1053     1054       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dmulcahey]

After the cluster changes are cleaned up we should look at converting this to a v2 quirk instead which would remove the need to open a PR in HA.

[dmulcahey]

After the cluster changes are cleaned up we should look at converting this to a v2 quirk instead which would remove the need to open a PR in HA.

legrand.patch

[piitaya]

@dmulcahey How does it work with translation_key ? Where the translations file should be located?

[dmulcahey]

@dmulcahey How does it work with translation_key ? Where the translations file should be located?

Translations will default to the attribute name. Strings.json will still need a HA PR

[piitaya]

I updated to quirk v2.
I didn't add the enum to create the select entity because of multiple reason :

1. entity_type seems to not work with standard. Also, why is it called entity_type instead of entity_category? Standard is not a category, the category should be set to None instead.
2. the ZCL select entity replace _ by spaces in Home Assistant that make hard the usage of entity translations. IMO, it should convert the enum in lowercase and keep the _.
   What do you think @dmulcahey?

I also have an issue with tests

[dmulcahey]

tests will pass after the Zigpy bump I think.

[TheJulianJES]

entity_type seems to not work with standard. Also, why is it called entity_type instead of entity_category? Standard is not a category, the category should be set to None instead

Yeah, some classes like ZCLEnumSelectEntity (in ZHA) override the entity category if it's None for now.
The main use case is to provide config entities via quirks v2. I think this would be the first case where we'd have a select entity that's not a config entity.
#3030 even mentions that this device could provide a climate entity in HA. This is not possible via quirks v2, but might be worth considering?
FYI, the metadata and entity type is matched a ZHA class here.

the ZCL select entity replace _ by spaces in Home Assistant that make hard the usage of entity translations. IMO, it should convert the enum in lowercase and keep the _.

Yeah, the enum states aren't translatable at the moment. There's this PR: home-assistant/core#109309, but I see some issues with state restoration when coming from an old version (due to _/ ) for ZHAEnumSelectEntity (used for non-ZCL stuff like IasWd).
That would need to be addressed (and the test for quirks v2 to see if translation keys are provided would need to be expanded).
It's still something I plan on looking at/working on, but the enums (split between quirks and ZHA atm) would all stay the same at least. Like you mentioned, ZHA would just lower-case them for the translation keys.

I also have an issue with tests

A helper for creating a quirk v2 device is added with #3032

[piitaya]

#3030 even mentions that this device could provide a climate entity in HA. This is not possible via quirks v2, but might be worth considering?

Yes I was considering this too. I'm not sure my python level is enough for that but I can give a try 🙂 As I know, there is no standard attribute for the preset in the thermostat cluster right?

The idea is to map the 6 heat mode into 2 hvac modes and 5 presets :

• heat - splitted into 5 presets :
  • comfort preset
  • comfort-1 preset
  • comfort-2 preset
  • eco preset
  • away preset
• off

I already did something similar in my home assistant qubino custom component : https://github.com/piitaya/home-assistant-qubino-wire-pilot

[TheJulianJES]

Yes I was considering this too. [...] As I know, there is no standard attribute for the preset in the thermostat cluster right?

Correct, at least not one that's mapped to HA presets for the "generic thermostat implementation" in ZHA.
Some thermostats are implemented like this for presets: homeassistant/components/zha/climate.py#L578-L667 (and further below are some other examples).
The "comfort -1" and "comfort -2" presets might be an issue though (since they don't seem to exist in HA)?

(Also, other devices like the Aqara E1 thermostat currently just implements the preset mode (manual, auto, away) as a config select entity. Of course, it would be better if it were added to the climate entity though.)

[luke7101]

#3030 even mentions that this device could provide a climate entity in HA. This is not possible via quirks v2, but might be worth considering?

Yes I was considering this too. I'm not sure my python level is enough for that but I can give a try 🙂 As I know, there is no standard attribute for the preset in the thermostat cluster right?

The idea is to map the 6 heat mode into 2 hvac modes and 5 presets :

• heat - splitted into 5 presets :

  • comfort preset
  • comfort-1 preset
  • comfort-2 preset
  • eco preset
  • away preset

• off

I already did something similar in my home assistant qubino custom component : https://github.com/piitaya/home-assistant-qubino-wire-pilot

Just my 2 cents :
pilot wire has 6 modes: comfort, comfort-1, comfort-2, eco, away and off (in my experience comfort-1 and -2 aren't used very often)
The off order is a "soft off" ie the heater stops heating but it's still powered.

Legrand 064882 cable outlet provides a "hard off" state, by toggling the switch in standard mode, that completely turns off the power (ie no power on the L wire)

It's a big advantage compared to the other devices I tried because, for example:

• you can completely switch off the power over summer to prevent your kids to turn the heater on unintentionally, convenient if the heater doesn't have a physical switch
• you can avoid electric smog when you don't absolutely need to heat (heaters have huge electric field >100V/m at 30 cm) still present in the soft off pilot wire state, and if you would like to turn it off automatically in the inter-season without toggling the circuit breaker once or twice a day !

What I'm trying to say is that you maybe should keep the 2 different off modes, mapping it for example like that;

• heat - splitted into 4 (or 6 presets ?) :

  • comfort preset
  • comfort-1 preset?
  • comfort-2 preset?
  • eco preset
  • away preset
  • off preset (soft off)

• off (hard off mode)

[bemble]

IMHO, it feels strange to have a climate entity for a device you can't actually set the temperature, just the mode.
From the doc, a climate is here to control the temperature. The pilot wire does not allow that, just setting a mode, the temperature is up to the heater it controls.

[luke7101]

IMHO, it feels strange to have a climate entity for a device you can't actually set the temperature, just the mode. On some heaters (like mine), you set up the comfort temp yourself, the solution can't be universal. Also, that would give more intelligence than the device provides (you can't get the actual temperature for example, you don't know when it's heating or not unless you look at the consumption). That goes a little against HA mindset: stick to what the device provides. Otherwise, we should also add the total power consumption for the energy dashboard directly in the quirk. A custom integration that handles that creates the climate for this particular device seems a better choice IMO.

My suggestion #3030 was inspired by the solution I'm actually using: a custom integration for the Heatzy Pilote device. It creates a climate entity (I agree it's weird without temperature setting!).


I'm also using this convenient Heatzy Pilote custom card

It just have to be ergonomic for the end user I guess, regardless of the entity domain 😉

[bemble]

It just have to be ergonomic for the end user I guess, regardless of the entity domain 😉

Having that useless big slider, a wrong information (heating, with this device we don't know when it's actually heating) and 2 clicks to do what the device is supposed to do (change a mode) is not what I can call ergonomic.
TBH, and as I said directly to @piitaya, if this entity would be a climate with just presets instead of a select, users should not use the climate card, just a tile card with the presets features, the climate card with this device is a non-sens to me.

[luke7101]

Having that useless big slider, a wrong information (heating, with this device we don't know when it's actually heating) and 2 clicks to do what the device is supposed to do (change a mode) is not what I can call ergonomic. TBH, and as I said directly to @piitaya, if this entity would be a climate instead of a select, user should not use the climate card, just a tile card with the presets features, the climate card with this device is a non-sens to me.

I agree that a climate card is not designed for this case scenario, however we must be sure that giving the wrong class (ie not climate) to a device supposed to drive a heater wouldn't lead to disadvantages in the HA ecosystem, for example in the interactions with other integrations supposed to deal with climate entities (voice assistants, cards or custom cards, or custom integrations designed to work around climate management, etc...)

[bemble]

I agree that a climate card is not designed for this case scenario, however we must be sure that giving the wrong class (ie not climate) to a device supposed to drive a heater wouldn't lead to disadvantages in the HA ecosystem, for example in the interactions with other integrations supposed to deal with climate entities (voice assistants, cards or custom cards, or custom integrations designed to work around climate management, etc...)

Yeah, talking with Paul I realized my only issue is finally the climate card and the more info dialog. If the auto-generated dashboard use a tile card in this situation instead of a climate, then I'm fine with it.

[piitaya]

I exposed the mode as a select and not a climate using zha thermostat because it was too complicated and I prefer to have a minimal working solution as many people will want to use the device with ZHA.

[piitaya]

I can also remove the select as discussed in this PR : #3364

I tried to create a PR to use it as a climate in ZHA but it seems to be to much work as the ZHA Climate is currently linked to the Thermostat Cluster.