-
-
Notifications
You must be signed in to change notification settings - Fork 36.3k
Add occupancy binary sensor triggers #157631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
|
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlpouffier Please check the text and also the trigger keys (binary_sensor.started_detecting_presence, binary_sensor.stopped_detecting_presence) are as you expect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the cover one, we used that convention: cover.shutter_opened
So let's try to use the same... meaning binary_sensor.presence_something_something
When it comes to the something something 😅 we can either be generic or find something that suits each device class best.
I would vote for the latter, and in that case, I would do
binary_sensor.presence_detectedbinary_sensor.presence_cleared
It's both past tense, so it fits our model, and it's simpler to understand.
When it comes to the strings, I would align all of them to this.
Title: Presence Detected
Description: Triggers after one or several presence sensors start detecting presence
Title: Presence Cleared
Description: Triggers after one or several presence sensors stop detecting presence
(I struggled a bit to write something with the word "Cleared".
I think it's fine to have a different wording in the description than the title).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlpouffier can you check again please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds experimental presence detection triggers for binary sensors, enabling automations to fire when presence sensors start or stop detecting presence. The feature is gated behind the "New triggers and conditions" experimental flag.
Key changes:
- Adds two new binary sensor triggers:
started_detecting_presenceandstopped_detecting_presence - Implements trigger filtering by presence device class
- Provides comprehensive test coverage for trigger behaviors (any, first, last)
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| homeassistant/components/binary_sensor/trigger.py | Implements the presence binary sensor triggers with state change detection (has bugs: missing entity_filter override and incorrect docstrings) |
| homeassistant/components/binary_sensor/triggers.yaml | Defines trigger configuration with behavior field and device_class filtering |
| homeassistant/components/binary_sensor/strings.json | Adds user-facing translations for trigger names, descriptions, and behavior options |
| homeassistant/components/binary_sensor/icons.json | Defines icons for the triggers (icons appear to be reversed) |
| homeassistant/components/automation/init.py | Registers binary_sensor as an experimental trigger platform |
| tests/components/binary_sensor/test_trigger.py | Provides comprehensive test coverage for trigger behaviors (missing device class filtering tests) |
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
| "title": "Binary sensor", | ||
| "triggers": { | ||
| "started_detecting_presence": { | ||
| "description": "Triggers after one ore more presence sensors start detecting presence.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the change from "Triggers when …" to "Triggers after …" intentional here?
It's making these inconsistent with all existing triggers and the "When" headline in the automation editor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We currently use "Occupancy" for these sensors, for example in the Activity.
"Presence" is for people or device trackers with regard to zones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We currently use "Occupancy" for these sensors, for example in the Activity.
Can you clarify what activity you refer to?
Anyhow, I think you're right that the trigger should be for device class BinarySensorDeviceClass.OCCUPANCY instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, for the so-called "presence sensors" the device class in HA is BinarySensorDeviceClass.OCCUPANCY
MartinHjelmare
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good. There are some open conversations above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to change those two from "Presence" to "Occupancy" as well.
Otherwise this is highly inconsistent and will be indistinguishable from "Presence detected / cleared" for that other device class.
If we want to keep "presence sensors" in the wording, then this could be in the description using:
"Triggers after one ore more presence sensors start detecting occupancy."
| }, | ||
| "excluded": { | ||
| "state": state[0], | ||
| "attributes": state[1], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There doesn't seem to be much difference between included and excluded states. It's not clear to me why we need the separation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The excluded state in the binary_sensor case don't have the wanted device class. For other domains it will be states without some capability attribute etc. The purpose is to check the filtering of entities which are not supported by the trigger is working.
| "name": "Occupancy cleared" | ||
| }, | ||
| "occupancy_detected": { | ||
| "description": "Triggers after one ore more occupancy sensors start detecting occupancy.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We missed the typo "ore" instead of "or".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing that in #157791
Proposed change
Add occupancy binary sensor triggers
Tagged for 2025.12.0 to have a binary sensor show case in the December 2025 release
Note: Language is aligned with the changes in #157643
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: