WTH don't all integrations have a minimum set of standard options?


  • Name or friendly name (pick one, at the moment it is a confusing mix of both)
  • Icon


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.

Yes this and the same for: Input boolean

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


That’s the complete opposite of what I asked for.

It’s customize that should not be required.


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