GeezerVison

It would be good to close out the open question here from @bdraco home-assistant/core#111151 (comment). It might be helpful to list some of the things/scenarios we're currently unable to derive in HA. For example I thought it was going to be sufficient to use the Feature.Category.Debug to drive entity_registry_enabled_default and I'm not sure why we need entity_registry_visible_default because they both hide the entities and I don't believe we have a need for entities that are enabled & hidden.

For the DeviceClass and StateClass it does seem to suggest a lot of HA development knowledge when creating a feature as to how these are all treated in HA. Maybe we could maintain a set of FeatureName to class mappings in the HA integration for those we want to set specifically and then derive a sensible default for those not specified.

I commented on that thread on this, but I agree that we should not proceed with this approach, but leave it to the homeassistant integration to do the mapping. Some of this can be done automatically, but for some we are going to need a mapping inside homeassistant. At least for those that require manual mapping, we are going to need to set the id manually to avoid breaking things if we one day decide to update the naming.

The difference between hiding & disabling is that the disabled entities won't be added to the state machine at all, but hidden ones are not added to the panes like the dashboard automatically. If you take a look at the screenshots in the description, you see that not all sensors (mainly the historical emeter ones) are not added, even when they are shown in the device page and recorded as expected.

On categorization, we could use the Debug to disable the entities, and moving the ones we want to be enabled to use Info, while mapping both Info and Debug to be entity_category=Diagnostics. Is that what you mean?

This would make us have the following categorization rules:
Primary: primary controls (state, brightness, etc.) & sensors (like temperature, emeter)
Config: secondary controls, entity_category=Config
Info: diagnostic information that is enabled per default in homeassistant
Debug: diagnostic information that is disabled per default

At least for those that require manual mapping, we are going to need to set the id manually to avoid breaking things if we one day decide to update the naming.

Or we set the id if/when we change the naming?

On categorization, we could use the Debug to disable the entities, and moving the ones we want to be enabled to use Info, while mapping both Info and Debug to be entity_category=Diagnostics. Is that what you mean?

Yes, I think this is simplest and we can always use overrides in HA if necessary.

This would make us have the following categorization rules: Primary: primary controls (state, brightness, etc.) & sensors (like temperature, emeter) Config: secondary controls, entity_category=Config Info: diagnostic information that is enabled per default in homeassistant Debug: diagnostic information that is disabled per default

Agreed. Then in HA we have a mapping of feature ids > (device_class, state_class) etc. The mappings can presumably live in each of the entity files as different entities have different description values.

Or we set the id if/when we change the naming?

I think we should do this from the get-go, as it will also allow us to use the the ids as translation keys.

Yes, I think this is simplest and we can always use overrides in HA if necessary.

Okay, I'll proceed to create a new PR that updates the categorization to follow this plan.

Agreed. Then in HA we have a mapping of feature ids > (device_class, state_class) etc. The mappings can presumably live in each of the entity files as different entities have different description values.

Makes sense to me, thanks for your input! 👍

Replaced with #904.