Add favorite position to Cover entity

[timstallmann]

Context

I'm working on an integration for the Wevolor controller for Levolor shades, which have the concept of setting a "favorite" position and then returning to that position.

It seems like this is something which other shade brands also support and are mainly handling through workarounds on the Home Assistant front-end -- e.g. in the somfy mylink example, triggering stop_cover when the cover is not currently moving has the effect of setting the favorite position.

Proposal

Add a SUPPORT_FAVORITE_POSITION flag to the CoverEntity, along with associated methods. On the front-end this could be represented by a heart icon for devices which support it.

Consequences

This would supplant device-specific workarounds on various cover integrations.

The main complication I can envision would be how or whether this interacts with set_position on devices which support setting a specific position, as depending on how the "favorite" position is set it might not be clear how to update the state of the device to reflect the favorite position.

[tetienne]

Such property will be also used by the Overkiz integration. Somfy expose a My Position which is a favorite. Currently we expose it as a button and add a number entity to set its value.

This flag can also be applied two a light and its brightness level.

[balloob]

I think that it makes more sense for integrations that support a favorite position to expose this as a scene.

[tetienne]

@balloob indeed a favorite position can be assimilate toa scene. But with the current implementation of the scene, how do you map a scene to a device? Using an entity (or a new property here), the user can directly see his favorite position in the device page.

[timstallmann]

@balloob also I think this is maybe a slightly different case than you're describing -- Levolor blinds (and I think also Somfy) don't actually support directly setting the position (so I don't think scene support would actually help here).

But they do support a "favorite" position that is stored on the device, and there's no current way for a cover device to support that particular behavior in Home Assistant; so devices which have favorite positions but don't support SET_POSITION have to create a separate button entity to toggle the favorite position on the device. It'd be clearer to integrate that into the Cover entity directly.

[Jc2k]

I think the preferred style in HA these days is to have many simpler entities linked together by the device registry, rather than adding lots of complexity to a single mega entity. Eg we have been getting rid of the air quality platform entirely (instead having many sensors), and the "is battery charging" attribute on a battery entity should now be instead a binary sensor on its own linked to the battery via the device registry.

I think the suggestion is that these integrations you mention could create a scene.my_favourite_position entity linked to the cover via the device registry. Rather than it being a "core" scene (that called set_position) it would be a device specific implementation (a scene is just an entity type with multiple implementations aiui). It wouldn't need to know or set a specific position. It would just activate that position, much like the button does in your description.

(Eg https://github.com/home-assistant/core/blob/dev/homeassistant/components/hue/scene.py)

[balloob]

What @Jc2k says is correct and I should have been more clear. Integration scenes are not built-in scenes and can just be activated on the controller.

[tetienne]

Many thanks for the example, I didn't know it was possible. I didn't find it in the dev docs.

So to sum up, a scene to apply the favorite position and an other entity to set the value like a number.

[Jc2k]

And you'd probably want to set the entity category on the number entity so it shows up as a config type on the device page for the cover. IMO you'd not want an entity category on the scene though.

[timstallmann]

Cool! I did not realize that was a possibility.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck