Add Squeezebox binary sensors for player alarm status #154491
Conversation
|
Hey there @rajlaud, @pssc, @peteS-UK, 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 binary sensors to the Squeezebox integration to track player alarm statuses. It introduces three new binary sensors for each player that indicate if an alarm is upcoming within 24 hours, currently active, or in snooze mode.
Key changes:
- Adds three new player-specific binary sensors for alarm states (upcoming, active, snoozed)
- Extends the binary sensor platform to support both server and player entities
- Updates test coverage for the new binary sensor functionality
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| homeassistant/components/squeezebox/binary_sensor.py | Implements new player alarm binary sensors and refactors to support both server and player entities |
| homeassistant/components/squeezebox/const.py | Adds constants for the three new alarm sensor types |
| homeassistant/components/squeezebox/strings.json | Adds localization strings for the new alarm sensors |
| tests/components/squeezebox/test_binary_sensor.py | Adds comprehensive test coverage for player alarm binary sensors |
| tests/components/squeezebox/conftest.py | Updates mock player fixture with default alarm state properties |
| tests/components/squeezebox/test_switch.py | Fixes docstring comment that was incorrectly referring to media_player platform |
Co-authored-by: Copilot <[email protected]>
|
Reviewers: let me know if this is something that would generally be functionality that makes sense in your opinion, if so I'll prepare the second PR for the alarm time sensor and the docs PRs. |
| "homeassistant.components.squeezebox.Server.async_query", | ||
| return_value=deepcopy(FAKE_QUERY_RESPONSE), | ||
| ), | ||
| with patch( |
There was a problem hiding this comment.
Could this not be a fixture?
|
|
||
|
|
||
| @pytest.fixture | ||
| async def mock_player( |
There was a problem hiding this comment.
Maybe move to conftest?
|
As a general comment on the testing, I have a PR at #153032 to rewrite a number of the common patches as fixtures, including mock_async_query, which might be useful here once that PR has been merged (as part of the quality scale work we're doing with joostlek). We've also rewritten all of test_config_flow to use these fixtures in that PR and moved to paramaterise the testing for reference. |
I don't use alarms a great deal, so not sure of the general usage, but extending the platform in this way doesn't seem a problem to me. @rajlaud might have a view on the alarm usage. |
So I would either rework these tests if #153032 is merged first or otherwise open a separate PR to fix them if this one goes first. |
I don't know, just adding the first part without adding the binary sensors would have added basically unused code (imagine the second part never being merged), I did not like that idea. |
Can see your point, in a way. But there are 2 different features IMO |
I also see what you mean. The dicovery by itself is a "code feature", both things together make an actual HA feature. |
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
|
We don't want to add dead code. Since the discovery is needed to add the new entities the discovery should be in this PR. |
Co-authored-by: Martin Hjelmare <[email protected]>
|
Please merge dev branch into your feature branch and solve the merge conflict. We recently added required sorting 🔡 of all translation strings in |
Breaking change
Proposed change
Squeezebox players have multiple information on their alarm status: if an alarm is upcoming within the next 24 hours, if an alarm is currently active or if an alarm is currently in snooze status. This PR adds a binary sensor to players for each of these, which can be useful in automations. There is also information about the time of the next alarm, but in order to keep PRs minimal and this will be a change to the sensor platform, I'll create a separate PR for that.
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: