[LLM-generated] Improve HOME_KEY handling, and add Duo Roller support.#33
Open
Flameeyes wants to merge 9 commits into
Open
[LLM-generated] Improve HOME_KEY handling, and add Duo Roller support.#33Flameeyes wants to merge 9 commits into
Flameeyes wants to merge 9 commits into
Conversation
The home_key was previously hardcoded in const.py as a bytes literal, which meant it was lost on every HACS/integration update. This was a known limitation documented in the README. Changes: - Store home_key as a hex string in HA config entry data (entry.data) where it persists across integration updates like any credential - Add home_key input field to both bluetooth_confirm and manual user config flow steps, with hex validation (32 chars = 16 bytes) - Add options flow so users can update/set the key after initial setup via Settings > Devices > PowerView > Configure - Add v1→v2 config entry migration that adds an empty home_key to existing entries and logs guidance to set it via options flow - Remove hardcoded HOME_KEY bytes constant from const.py, replace with CONF_HOME_KEY string constant for the config entry key name - Coordinator reads home_key from entry.data instead of importing const - Accept flexible hex input: strips spaces, colons, dashes before validating - Added UI strings and English translations for all new fields The key is optional (left blank for unencrypted shades) and validated on input. Separators in hex strings (spaces, colons, dashes) are stripped automatically for convenience.
Since HA 2024.11, OptionsFlow provides self.config_entry as a built-in property. Remove the deprecated pattern of passing config_entry into the constructor and storing as self._config_entry. The async_get_options_flow now returns PVOptionsFlow() with no args.
The method returns a mix of int, float, and bool values, not just float. Updated type annotation from list[tuple[str, float]] to list[tuple[str, int | float | bool]].
- pyproject.toml: requires-python >= 3.14.0 (HA 2026.5+ needs 3.14.2) - hacs.json: homeassistant min bumped to 2025.2.0 (for OptionsFlow config_entry property, runtime_data, and other patterns used) - manifest.json: version bumped to 0.24
Replace bare ConfigEntry imports in cover.py and button.py with the typed ConfigEntryType alias (ConfigEntry[PVCoordinator]) defined in __init__.py. This provides proper type-safe access to runtime_data.
The integration uses PassiveBluetoothDataUpdateCoordinator which receives BLE advertisement data passively (push). The iot_class should reflect this as local_push, not local_polling.
Duette/Applause shades (types 6, 8, 9, 10, 33) support a secondary position (pos2) that controls the vanes for privacy mode. This is exposed in the PowerView app as 'Vanes'. New PowerViewCoverDuette class maps pos2 to HA's tilt control, giving a second slider in the cover card. Also routes Venetian types (51, 62) to the existing PowerViewCoverTilt class which was previously unreachable.
Type 103 is a Duo Roller (not Duette) shade not present in the upstream type table. Without this, shades with model_id 103 fall through to the basic PowerViewCover class and get no vanes/tilt control.
…ssing shade types - Remove stale warning about HOME_KEY being lost on updates (now persisted in config entry) - Update installation and encryption key sections to reference the config flow instead of manually editing const.py - Add Duo Roller (103) and other missing shade types to the supported devices table (types 8, 9, 33, 47, 51, 62) - Mark tilt/vanes support as complete in the Outlook section
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I used your Blind Emulation to extract the home key, but I didn't want to worry about replacing it in the sources every time.
So instead I had an LLM add support for the config_entry, and use the more recent Home Assistant APIs to avoid deprecation notices & the like.
Plus I added support for the Duo Roller which otherwise was missing. Let me know if this is of use!