chore: Add a high level direction for improving device and feature discovery

[allenporter]

This is meant to try to summarize the device features progress and potential next steps, and discovery pieces that need to be improved to get to the next level of home assistant quality.

[allenporter]

I wonder if we should follow this rule:

If a feature is supported on only some devices - it should be split up into a separate trait.

This may mean that things like 'Status' need to be split up.

It is a lot easier for us to check/organize the logic if it were checking one trait rather than checking the attribute of a trait. But that may have some complexity to it. What did you have in mind for this part of the system? The actual entity/feature mapping.

This sounds like a reasonable proposal to me.

[allenporter]

I wonder if we should follow this rule:
If a feature is supported on only some devices - it should be split up into a separate trait.
This may mean that things like 'Status' need to be split up.
It is a lot easier for us to check/organize the logic if it were checking one trait rather than checking the attribute of a trait. But that may have some complexity to it. What did you have in mind for this part of the system? The actual entity/feature mapping.

This sounds like a reasonable proposal to me.

By this i mean: It sounds like it can work, i don't have any objection to it, and i don't have any other better suggestions. I like the idea of treating "device features" as an internal implementation detail.

[allenporter]

I wonder if we should follow this rule:
If a feature is supported on only some devices - it should be split up into a separate trait.
This may mean that things like 'Status' need to be split up.
It is a lot easier for us to check/organize the logic if it were checking one trait rather than checking the attribute of a trait. But that may have some complexity to it. What did you have in mind for this part of the system? The actual entity/feature mapping.

This sounds like a reasonable proposal to me.

By this i mean: It sounds like it can work, i don't have any objection to it, and i don't have any other better suggestions. I like the idea of treating "device features" as an internal implementation detail.

Although - some devices have more data for things like dnd than others. and we may end up with something like DnDTrait DnDTraitv2 or DndConsumableTrait

Then consumables as well can be different per devices, meaning we may need to have a seperate trait per consumable.

I guess this may get pretty big pretty fast.

What about a custom decorator for properties?

If no decorator -> if the device ahs the trait it is supported.

If decorator -> device must have specific trait(s) for this property to be supported. We can still abstract this up somehow, but then device features stay grouped with the specific thing that they are supporting.

What would the caller API be to check if a feature is supported?

An alternative I can think of is to have an enum with supported features on the trait (an enum value per optional field) and the convention would just be that it has a similar name to the specific fields.

[allenporter]

The points I am hearing that resonate with me are, that I think can be "decisions" we agree on:

• Device features are too granular to use directly and make sense of, therefore we need a new higher level abstraction.
• We will prioritize what "features" are exposed, and they will be a subset. They can be based on any lower level signals or heuristics (could be device features, product info, or hard coded based on model info if that happens to make sense. we can leave that to the specific "feature").
• The exact mechanism has a few options, but likely needs to be able to point at specific fields. it seems like it will be too difficult to make new traits. We'll want an easy way to associate a feature with one more more fields.

if you agree with that, as a next step we can try a couple specifics like what you are proposing and see if we like them. Your proposed API makes sense, so a prototype is probably in order. I would say we try to use this to identify the existing optional sensors / binary sensors in home assistant (mop, cleaning area, dock entity stuff) and see if we can get something to make sense.

[allenporter]

3. We add further logic onto the RoborockBase object as metadata. to determine if a specific attribute is supported it would be something like device.is_supported(Consumable.side_brush_work_time)

Attempt to implement this #740