Update device_class based on shade configuration

[chemelli74]

Describe you new feature you'd like

First of all, one more time thank you for your fantastic work. Amazing !!!

I just completed the configuration and found a small space for improvement. Do you mind updating the device_class based on the shade configuration ?

so to be aligned with https://www.home-assistant.io/integrations/cover/#device-class

I also think you can avoid setting explicitly the icon, as it's part of the device_class itself.

Thank you in advance

[rstrouse]

I am not sure what you mean the plugin does set the device class based upon the configuration. If you make changes in ESPSomfy RTS after first installing the plugin you may need to reload the plugin to reflect this since I haven't found a way to dynamically reload it after it has been initialized.

However, the icons must be explicitly set or the open/closed states end up being goofball. The invert position function comes into play with this since HA insists on representing it in percentage of open not percentage of closed. But it also flips the state names on the movement to make it even more annoying. For awnings however, originally, the icon chosen to display from the device class was actually a window icon. I don't know if this has been fixed or not but users asked to explicitly change it.

[chemelli74]

I did a restart of the integration but device_class didn0t change, this is why I opened this FR. I then did a full restart of ESP32 first and HA after, and now I see the correct device_class.

About the icon, I think it should be consistent with HA, and if a user want to change it it can then edit the entity or use customize.yaml.

[rstrouse]

The cover entity for awning in HA is a mess or at least it was when I first built the plugin. I have not gone back and checked to see if it had been fixed. Like the icon they chose the open/close didn't work correctly with an awning and you would end up with controls disabled at the endpoints that didn't match the direction it needed to move. Sadly, this has been reported to the HA devs many times and there is a huge misunderstanding between open and closed on a regular cover and extended and retracted when it comes to an awning. Some of the discussions are just dismissive. I suppose if you developed the component and an awning is not one of the things you care about, then you are in charge.

In the mix of all this the plugin has special code to make sure the states are reflected appropriately. That includes the icon which is originally represented in HA as a window. To make the right thing show and have the proper buttons disabled in HA you needed to change the direction of movement from the remote, but that conflicts with how some of the sun sensors work. And alas everything ends up being backward again. That is the primary reason for the invert commands and invert position checkboxes. This lets you get around those quirks and still be able to control it all appropriately.

About half of the home automation platforms get this messed up for awnings. I'll have a look to see what has changed on the cover since they started using vertical sliders in the UI.

[chemelli74]

Thx for the details. Let me know if you think there is something wrong in HA, as a member of the Team I can try to look at it.

[rstrouse]

Thanks @chemelli74. Don't get me wrong I love HA and fully understand that my goals may not match the folks willing to contribute to the repo. I have boxes of hubs, radios, and have contributed to quite a few of those platforms. Many of those were my ride-or-die at some point but all of those platforms either fizzled, turned into online service platforms, or moved away from open platforms. I have been at this for quite some time and given the track record I am simply hoping HA does none of those things.

I believe, many of the issues in the cover component stem from the script implementation on the UI side. While several of the device classes are fine, awnings have the icon positions reversed and therefore the open became closed and closed became open and just went downhill from there. To be fair open and closed have an outer semantic relationship to the actual state of an awning so the confusion probably started there.

The hardware doesn't help much either as it ends up being up and down. Lots of ways to get twisted around but horizontal movement where open is extended and closed is retracted couldn't be further from the movement of a gate which is what the awning seems to be based on.

Interestingly, I could either get it to show the correct icon with the proper state, or I could have an incorrect icon with the wrong command buttons (open and closed reversed) or I could have all the icons correct but you couldn't command movement because the wrong command button was disabled. When you threw Homekit into the mix it got worse where opening was closing and closing was opening.

I did submit an issue but then did some research to see how often it had been reported. After reading several shut up and go away replies I simply went about working around it, closed the issue, and poked fun at the silliness. After all I don't have any awnings, had bigger fish to fry, and didn't need to jump into the fray. I will go back in and see where we are now to see if I can find parity with the default functions.

[011V32]

If someone other is interested in the mentioned issue: Issue 16706

[rstrouse]

Yeah HA is not going to change any of this anytime soon. I just had to work around all the group functions as well to get the device class and display class to work together with for groups that contain awnings. Awnings are particularly goofy but I suspect these issues are also the ones the homekit users on the interweb experience as well. I will keep an eye on it and if someday it gets fixed I will change it.

Either way I am going to close this as waaay too much effort has been placed on this. Users are able to control and manage their devices properly so trying to shoehorn this into a non-operable design is not at the top of my list.