Specifically:
- Name or friendly name (pick one, at the moment it is a confusing mix of both)
- Icon
Agreed.
A perfect example is one I used yesterday when adding a new entity, light switch. You can’t assign an icon other than doing it via customisation. Why not just add the option for icon in the config…?
1 Like
Another example is the core GPIO binary sensor not supporting device_class.
No that is not the same at all. You are asking for extra features, not consistent features and TBH I don’t see how input_booleans could support the binary_sensor device class.
But it is a request for consistency. Device classes should be a universal thing you can implement to any entity to change what that represents. That’s why it should not be limed to binary sensors, but also be usable with: switches, booleans or etz. They all can represent a door, a window, or a person.
No. Device classes are specific to domains.
IMO name/icon/(friendly_name?) should be removed from all integrations.
customize adds that and more to all entities allready
WHT?
That’s the complete opposite of what I asked for.
It’s customize that should not be required.
2 Likes
I know that, but at least in my opinion it does not make sense for all integrations to provide something that already are in place.
What have a whole customize utility at all?
It the integrations were defined correctly it would not be needed.
1 Like
as long as we wouldn’t need to set the options in a dedicated customize section that would be cool alright.
Just as we dont have to use _template any longer soon, for the system to recognize a template, we should be able to set all options customize offers, for all integrations, in that integrations config.
1 Like