blakeblackshear / frigate-hass-integration

Frigate integration for Home Assistant
MIT License
771 stars 122 forks source link

Hide some entities by default #256

Open felipecrs opened 2 years ago

felipecrs commented 2 years ago

Is your feature request related to a problem? Please describe.

The Frigate integration provides lots of entities, so that we can automate everything we want. But, I noticed that some entities aren't exactly "user friendly" (not sure if it's the right way to call it or not), but instead only "automation friendly".

Some examples are:

And the problem that arises because of it is:

Describe the solution you'd like

This is exactly what HA 2022.4 tried to solve by bringing the Hidden entities feature:

they are no longer shown on auto-generated Dashboards; they are automatically hidden from HomeKit, Alexa & Google Assistant and aren’t called when a service call targets their area.

I believe everything but the main cameras (this is debatable of course) could be hidden by default.

Describe alternatives you've considered

To hide them all myself. It's very hard though (in my installation, Frigate integration provides 339 entities).

Additional context

I would be happy to hear opinions about it.

dermotduffy commented 2 years ago

This seems like a good idea to me. A blunter instrument would be to disable them (some of the new entities were added disabled by default in this same spirit).

A principled stance would be best, i.e. lets take the entities per camera and break them into 3 categories (enabled by default, hidden by default, disabled by default) -- and agree on those 3 categories first, then implement it in 1 go.

NickM-27 commented 2 years ago

Yeah I am a fan of the principled stance, either way might be good to create a doc explaining the reasoning between the different categories and where the entity goes so future contributors have an idea and we have something to reference as well.

dermotduffy commented 2 years ago

Enabled by default

Principle

Anything required for usecases of the integration or card to provide an excellent "out of the box" experience when that usecase is likely applicable to the majority (>50%) of users of the TAM [Total Addressable Market] for the integration, or the card, individually.

Experience the user will have

Attribute Enabled
Entity is active in the HA state machine (e.g. can be used in the card, automations, templates) :heavy_check_mark:
Entity state is recorded :heavy_check_mark:
Entity shows up on automatically generated dashboards :heavy_check_mark:
Entity is included in 'area' targeted service calls. :heavy_check_mark:
Entity is exposed to Homekit, Google Assistant & Alexa :heavy_check_mark:

Hidden by default

Principle

Anything required for more niche/expert usecases for either the integration or card when that usecase is likely applicable to at least (25%) of the users of the TAM for the integration, or the card, individually.

Experience the user will have

Attribute Enabled
Entity is active in the HA state machine (e.g. can be used in the card, automations, templates) :heavy_check_mark:
Entity state is recorded :heavy_check_mark:
Entity shows up on automatically generated dashboards :heavy_multiplication_x:
Entity is included in 'area' targeted service calls. :heavy_multiplication_x:
Entity is exposed to Homekit, Google Assistant & Alexa :heavy_multiplication_x:

Disabled by default

Principle

Anything where the likely usage is < 25% of the TAM for either the integration or card. All disabled entities will also be hidden (so once manually enabled, will fall into the hidden category above).

Experience the user will have

Attribute Enabled
Entity is active in the HA state machine (e.g. can be used in the card, automations, templates) :heavy_multiplication_x:
Entity state is recorded :heavy_multiplication_x:
Entity shows up on automatically generated dashboards :heavy_multiplication_x:
Entity is included in 'area' targeted service calls. :heavy_multiplication_x:
Entity is exposed to Homekit, Google Assistant & Alexa :heavy_multiplication_x:

Example assignment of entities to categories

Summary

Category Icon Count today Count with below proposal
Enabled :heavy_check_mark: 11 5
Hidden :eye: 0 7
Disabled :heavy_multiplication_x: 4 5
Entity unique_id suffix Description Note Current Category Proposed Category
camera:[camera] The main Frigate camera stream :heavy_check_mark: :heavy_check_mark:
camera_snapshots:[camera]_[object] The object specific camera snapshot :heavy_check_mark: :eye:
motion_sensor:[camera]_motion The motion detection for the camera Used via websocket for the default card configuration when no object is specified :heavy_multiplication_x: :heavy_check_mark:
occupancy_sensor:[camera/zone]_[object] The occupancy sensor for the object within the camera/zone :heavy_check_mark: :heavy_check_mark:
occupancy_sensor:[camera/zone]_all The occupancy sensor for all objects within the camera/zone Used via websocket by the default card configuration when no object is specified :heavy_multiplication_x: :eye:
sensor_detector_speed:[detector] The detector speed for CPU/coral :heavy_check_mark: :heavy_multiplication_x:
sensor_fps:[camera/detection/process/skipped] FPS diagnostic sensors :heavy_check_mark: :heavy_multiplication_x:
sensor_fps:detection Overall Frigate detection speed :heavy_check_mark: :heavy_multiplication_x:
sensor_object_count:[camera]_[object] Object count for that object :heavy_check_mark: :eye:
sensor_object_count:[camera]_all Object count for all objects :heavy_multiplication_x: :eye:
switch:[camera]_detect Camera detect setting :heavy_check_mark: :eye:
switch:[camera]_motion Camera motion setting :heavy_multiplication_x: :eye:
switch:[camera]_recordings Camera recording setting :heavy_check_mark: :heavy_check_mark:
switch:[camera]_snapshots Camera snapshots setting :heavy_check_mark: :heavy_check_mark:
switch:[camera]_improve_contrast Camera improve contrast setting :heavy_multiplication_x: :heavy_multiplication_x:
update:frigate_server Whether there's a Frigate update available :heavy_check_mark: :eye:

Caveats

Above heavily based on my own usecases. Adding some integration/card contributors for feedback on how the above matches their usecases: @NickM-27 , @felipecrs , @blakeblackshear , @peledzius , @drinfernoo

NickM-27 commented 2 years ago

Wow that's very comprehensive! Overall I agree, seems reasonable to me 👍

felipecrs commented 2 years ago

Impressive summary!

I believe I would hide the following entities as well:

NickM-27 commented 2 years ago

Impressive summary!

I believe I would hide the following entities as well:

  • motion_sensor:[camera]_motion
  • occupancy_sensor:[camera/zone]_[object]
  • sensor_object_count:[camera]_[object]
  • switch:[camera]_recordings
  • switch:[camera]_snapshots

Personally, I feel like over 25% of users would use most of these. sensor_object_count:[camera]_[object] I can see probably less likely and makes sense to hide.

But with all those hidden the only thing not hidden by default is the camera view itself which to me makes less sense / too much the other way compared to what it is now, just my 2c though.

dermotduffy commented 2 years ago

Agree with Nick, suspect most of these are >25%. Moved sensor_object_count:[camera]_[object] to hidden, as perhaps that's the weakest one.

dermotduffy commented 2 years ago

Going to leave this open, as I temporarily avoided the use of hidden entities pending resolution of a Home Assistant frontend bug. More details in the PR: https://github.com/blakeblackshear/frigate-hass-integration/pull/273

Leaving this bug open for now.

Mincka commented 2 years ago

Hi, Just leaving a quick feedback about the default inclusion of all_occupancy binary sensors (per camera and, per zone) I just disabled all of them because it creates lots a redundant logs with [object]_occupancy. I think they are not very relevant by default since my guess is the users usually want to target a specific kind of occupancy. Is a person there? Is a car there? The case of mixing objects seem less relevant. Are the dog or a person in the living room ?... Is the front camera detecting a person or a car?... Ok maybe but I would explictely look for each object count in that case.

dermotduffy commented 2 years ago

@Mincka Background: The all_occupancy is default enabled mostly so that the card has a default way of getting "an occupancy sensor" without the user need to explicitly configure anything (if all_occupancy was disabled, the card would require the user to tell it which object to pay attention to the occupancy for). It wouldn't be terrible, but it would be slightly less 'magic' than if we can mostly count on the all_occupancy sensor being enabled...

Mincka commented 2 years ago

Thanks for the explanation. I understand your point even it's a choice for the integration based on the card that people may not use at all. Anyway, it's only a matter of a few seconds to disable them. Also, disabling them by default makes them more difficult to discover in HA.

felipecrs commented 2 years ago

One may claim the all_ should be hidden, though. Which I have no opinion on.

NickM-27 commented 2 years ago

I think we'd love to have it hidden, too bad HA frontend behavior / bug means hidden is not an option currently

felipecrs commented 2 years ago

Oh yeah, I forgot it.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

felipecrs commented 1 year ago

Can this issue be reopened while we wait for https://github.com/home-assistant/frontend/issues/12887?

charlesomer commented 3 months ago

The Home Assistant fix appears to be merged now 😄