Allow extracting non-primary entities in websocket command#168860
Conversation
|
Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
This PR adds a new primary_entities_only flag to target extraction so callers (notably websocket clients) can optionally include non-primary (config/diagnostic) entities when expanding targets.
Changes:
- Extend
homeassistant.helpers.target.async_extract_referenced_entity_idswith a kw-onlyprimary_entities_onlyparameter and thread it through target tracking. - Add
primary_entities_onlyto theextract_from_targetwebsocket command schema and pass it through to target extraction. - Add tests covering the new flag in both helper- and websocket-level test suites.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
homeassistant/helpers/target.py |
Adds primary_entities_only option and uses it to control entity-category filtering during indirect expansion. |
homeassistant/components/websocket_api/commands.py |
Exposes primary_entities_only on the extract_from_target websocket command and forwards it into extraction. |
tests/helpers/test_target.py |
Adds unit coverage asserting indirect expansion changes when toggling primary_entities_only. |
tests/components/websocket_api/test_commands.py |
Adds websocket-level coverage verifying extract_from_target includes/excludes config/diagnostic entities based on the flag. |
|
|
||
| def _include_entry(entry: er.RegistryEntry) -> bool: | ||
| """Return True if the entry should be included in indirect expansion.""" | ||
| if entry.hidden_by is not None: |
There was a problem hiding this comment.
Side note: I think it's weird that we let "hidden" influence the target selection. "hidden" is used to hide entities from a dashboard. That should not matter for how the entity is used in automations.
I had to change this setting to allow me to create working automations which was confusing and disappointing.
There was a problem hiding this comment.
Yeah, I know. I think the decision to use it like that was wrong.
It's another case where we tied more than a single feature, and the features are semantically distinct, to the same API. That always backfires.
| target_selection: TargetSelection, | ||
| expand_group: bool = True, | ||
| *, | ||
| primary_entities_only: bool = True, |
There was a problem hiding this comment.
I think long term I'd invert this setting. I think it's an edge case where we don't want to include all entities.
The only case I can think of is when controlling area ambient lights and you have some other light setting on a device in the area.
All entities with a device class you would want to include by default in the selection that targets that device class.
There was a problem hiding this comment.
For now we only have 1 trigger/condition where we need it, which means that the majority of them don't.
I am not saying that we should not make the default target all, though, but for now lets keep it backwards compatible since that would be a bigger change.
There was a problem hiding this comment.
Yeah, we can't change this easily, but I think we should long term. We have created a default rule for the edge case instead of the other way around.
|
Waiting for linked frontend PR. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Can be merged when frontend PR is approved. |

Proposed change
Add a new
primary_entities_onlyattribute to theextract_from_targetAPI to allow extracting non-primary entities.This is required for triggers that need to target non-primary entities. Frontend gets the info from the trigger description, as show in https://github.com/home-assistant/core/pull/168857/changes#diff-59d5f644bc2db2d5c73c9c6e802e8d3e0f24b4d8cde68c8931b029658eeb2d9cR36
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: