Add room priority select entity to Lyric integration#167942
Conversation
Adds a select entity per LCC thermostat that has room sensors, allowing users to choose which room's temperature reading the thermostat should prioritize. Options are dynamically built from the thermostat's linked rooms. Supported priority modes: - Follow Me: auto-switch based on motion detection - <Room Name>: use a specific room sensor (PickARoom) Depends on: - aiolyric storing LyricPriority in priorities_dict (library PR pending) - aiolyric PR home-assistant#134 (fix update_priority POST->PUT)
![home-assistant[bot]](https://avatars.githubusercontent.com/in/97978?s=60&v=4){kind=small}
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
|
Hey there @timmo001, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
TestingTested on a live setup with 4 T9/T10 thermostats and 5 RCHTSENSOR room sensors on HA 2026.4.1. All 4 LCC thermostats with room sensors got a select entity. Each correctly reads the current The write path has not been tested yet — it depends on timmo001/aiolyric#134. |
The coordinator now fetches priority data directly from the Honeywell API if the aiolyric library doesn't expose priorities_dict. This allows the select entity to work with the current aiolyric 2.0.2 without requiring a library upgrade for the read path.
home-assistant
Bot
added
cla-recheck
cla-signed
and removed
cla-recheck
cla-needed
labels
|
Pushed a fix for the two ruff failures:
The coordinator now only reads This is the cleaner approach — no workarounds in HA code for missing library functionality. |
|
The codecov/patch failure is expected — this integration doesn't have entity tests for any platform (climate, sensor, or now select). The required codecov checks pass. Adding select-only tests would require building out the full coordinator mock infrastructure (OAuth flow, Lyric client, location/device/room fixtures) since none of that exists yet. Happy to do that as a separate PR if preferred, but didn't want to mix test scaffolding into a feature PR. |
| if hasattr(self.lyric, "priorities_dict"): | ||
| self.priorities_dict = self.lyric.priorities_dict |
There was a problem hiding this comment.
the Lyric object never has priorities_dict as attribute, what's going on?
There was a problem hiding this comment.
That property is added in timmo001/aiolyric#138. The hasattr check was meant as a forward-compatibility guard so the coordinator doesn't break on the current library version, but I agree it reads as confusing without context. I'll remove the guard and add the priorities_dict access unconditionally once the aiolyric bump lands.
|
Let's keep it in draft until that dependency update has been fixed |
|
Removed the Will update and mark ready for review once the upstream dependencies are merged and the aiolyric version is bumped. |
https://github.com/timmo001/aiolyric/releases/tag/2.1.0 released 👍 |
The upstream release includes priorities_dict property and update_priority fix needed for the room priority select entity.
|
Bumped aiolyric to 2.1.0 in manifest and requirements. Marked ready for review. |
| "iot_class": "cloud_polling", | ||
| "loggers": ["aiolyric"], | ||
| "requirements": ["aiolyric==2.0.2"] | ||
| "requirements": ["aiolyric==2.1.0"] |
There was a problem hiding this comment.
Ack, moved the version bump out. I'll submit it as a separate PR.
| and device.device_id.startswith("LCC") | ||
| ) | ||
| ) | ||
| self.priorities_dict = self.lyric.priorities_dict |
There was a problem hiding this comment.
why do we store this as a variable on the coordinator? coordinator.data, which is the return value of _async_update_data is seen as the state of the coordinator. the data in this case is self.lyric, so I think it's more correct to get the priorities from coordinator.data...
There was a problem hiding this comment.
Good point. Removed the extra attribute — the select entity now reads directly from coordinator.data.priorities_dict since that's where the authoritative state lives.
….data - Revert aiolyric version bump (will be a separate PR) - Remove priorities_dict attribute from coordinator - Read priorities directly from coordinator.data.priorities_dict
joostlek
left a comment
joostlek
left a comment
There was a problem hiding this comment.
The CI is failing, can you take a look?
- Remove `from __future__ import annotations` (banned, Python 3.14+) - Raise HomeAssistantError instead of swallowing exception in async_select_option
3 participants
Breaking change
Proposed change
Honeywell T9/T10 thermostats support room priority — the ability to pick which wireless room sensor the thermostat uses for its temperature reading. The `aiolyric` library already fetches this data via the `/priority` API endpoint and has an `update_priority` method, but the HA integration doesn't expose it.
This adds a select entity per LCC thermostat that has room sensors, letting users pick which room has priority or switch to "Follow Me" (motion-based). Options are built from the rooms the API returns for each thermostat.
The coordinator reads priority state from `aiolyric`'s `priorities_dict` property when available. The write path uses the existing `update_priority` method.
Type of change
Additional information
Upstream dependencies
This PR requires changes in `aiolyric` before it can be merged:
Once both are merged and released, `manifest.json` will need a version bump in a follow-up PR.
Checklist
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`.
Updated by running `python3 -m script.gen_requirements_all`.
No manifest or dependency changes in this PR. The `select` platform uses the existing `aiolyric` dependency. The manifest and requirements files will be updated in a follow-up PR when the aiolyric version is bumped.
To help with the load of incoming pull requests: