The Problem
LOTS of integrations support “filter” definition for fine-grained control of entities to export/expose, i.e. include_domains, include_entities, include_entity_globs, exclude... etc. A few off the top of my head are: HomeKit Bridge, Recorder, Logbook, InfluxDB, Prometheus, Alexa, Apache Kafka… surely more.
ALSO a ridiculous amount of documentation space is spent trying to explain filters over and over again for each integration, even though they are almost all the same, and this could be greatly simplified by linking to a single entity-filter doc page.
SOME Integrations (ahem, HomeKit Bridge) try to let you define these filters via the GUI “Add Integration” workflows, which just has a tendency to confuse people who aren’t familiar with how filters work. They often think they are down-selecting, but they are actually additive, plus they have no visual feedback and are difficult to go back and edit.
The Proposal
IDEALLY you could define a named entity filter in the UI, adding domains, areas, labels, globs, or individual entities, and the UI would explicitly show the definitive list of which entities are included as more are added (or excluded). After saving the filter, the filter/list name should be available for use in integration configs — for example, when adding a HomeKit Bridge you are presented to select from a list of your entity filters — or you could use them in YAML:
homekit:
filter:
- my_homekit_entity_filter
entity_config:
- foo
...
MAYBE you could also define named entity filters in YAML for the die-hard fans of text configs, but having something in the GUI would be the ultimate goal. Existing filter syntax rules apply, just a new section definition:
entity_filter:
- name: my_homekit_entity_filter
include:
include_domains:
- sensor
include_entity_globs:
- binary_sensor.*alarm
exclude:
exclude_entities:
- binary_sensor.smoke_alarm
MAYBE this expansion of entity filter definitions could bring in the possibility of including areas and labels as well as the traditional filter includes (a concept which has appeared in multiple disparate feature requests). I’ve attached a VERY ROUGH concept below to convey the idea, but a split-pane that auto-refreshes the “exposed” entities would be better.
MAYBE once this concept is complete it can also be applied to the Voice Assistants section which have a similar concept but completely different implementation of “exposed” filter definition — unless there is some reason for it to be different than entity filters used by other integrations.
FINALLY, having this capability “baked in” to core would facilitate moving quite a few “YAML-only” integration configs over to the GUI, as they would not each have to replicate the filter feature in different/inconsistent ways.