Add Honeywell String Lights integration#168450
Conversation
Replace the placeholder garage-door example with adapted snippets from home-assistant/core#168450, which shows the real config-flow filtering by a sample command's frequency/modulation and the real send-command path via rf_protocols.get_codes.
ca80fe9 to
0b699dd
Compare
There was a problem hiding this comment.
Pull request overview
Adds a new honeywell_string_lights integration to control Honeywell RF string lights via the new radio_frequency entity abstraction, including config flow, light platform entity, and accompanying tests and metadata.
Changes:
- Introduces the
honeywell_string_lightsintegration (manifest, config flow, entity + light platform, translations, quality scale). - Adds a full test suite for config flow and light behavior.
- Updates generated registries/metadata (integrations/config_flows), requirements comments, brands, and CODEOWNERS.
Reviewed changes
Copilot reviewed 16 out of 18 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| homeassistant/components/honeywell_string_lights/init.py | Sets up/unloads the config entry and forwards the light platform. |
| homeassistant/components/honeywell_string_lights/config_flow.py | Implements a user config flow selecting a compatible RF transmitter entity. |
| homeassistant/components/honeywell_string_lights/const.py | Defines integration constants (domain + transmitter field). |
| homeassistant/components/honeywell_string_lights/entity.py | Base entity wiring to track transmitter availability. |
| homeassistant/components/honeywell_string_lights/light.py | Light entity that sends rf-protocols commands through radio_frequency. |
| homeassistant/components/honeywell_string_lights/manifest.json | Declares integration metadata, dependency on radio_frequency, and rf-protocols requirement. |
| homeassistant/components/honeywell_string_lights/quality_scale.yaml | Declares quality scale status for the new integration. |
| homeassistant/components/honeywell_string_lights/strings.json | Adds config-flow strings (form + abort reasons). |
| tests/components/honeywell_string_lights/init.py | Test package marker. |
| tests/components/honeywell_string_lights/conftest.py | Shared fixtures for RF transmitter + config entry setup. |
| tests/components/honeywell_string_lights/test_config_flow.py | Tests config flow success and abort cases. |
| tests/components/honeywell_string_lights/test_light.py | Tests on/off command sending, restore state, and unload behavior. |
| requirements_all.txt | Adds integration annotation comment for rf-protocols. |
| requirements_test_all.txt | Adds integration annotation comment for rf-protocols. |
| homeassistant/generated/integrations.json | Registers the new integration in generated integration metadata. |
| homeassistant/generated/config_flows.py | Adds the integration domain to generated config flow list. |
| homeassistant/brands/honeywell.json | Associates the new integration with the Honeywell brand. |
| CODEOWNERS | Adds code ownership entries for the new integration and tests. |
| "abort": { | ||
| "already_configured": "[%key:common::config_flow::abort::already_configured_device%]", | ||
| "no_compatible_transmitters": "No radio frequency transmitter supports 433.92 MHz OOK transmissions. Please add a compatible transmitter first.", | ||
| "no_transmitters": "No radio frequency transmitters are available. Please set up a transmitter first." |
There was a problem hiding this comment.
Hmm, I am wondering if there's something better describing what a transmitter is
| @pytest.fixture | ||
| def mock_config_entry( | ||
| hass: HomeAssistant, | ||
| mock_rf_entity: MockRadioFrequencyEntity, # noqa: F811 |
There was a problem hiding this comment.
I don't think ruff trips over this
There was a problem hiding this comment.
The fixture itself is not used, as we reference to the entity by entity ID. Marks like usefixture cannot be applied to other fixtures.
|
Oh and are there more honeywell lights that support this? Or just string lights? |
|
This is just their string lights as far as Keith and I could tell. |
Introduce a new Honeywell String Lights integration that drives the lights over the radio_frequency entity platform. The OOK turn on/off commands are provided by the rf-protocols library.
60b8550 to
f6ebc42
Compare
| command = mock_rf_entity.send_command_calls[0] | ||
| assert command.command is COMMANDS.load_command("turn_on") | ||
| assert command.context is context |
There was a problem hiding this comment.
Compare the expected RF command by value (or by key attributes) instead of using is, since a separate COMMANDS.load_command(...) call is not guaranteed to return the same object instance.
| command = mock_rf_entity.send_command_calls[1] | ||
| assert command.command is COMMANDS.load_command("turn_off") | ||
| assert command.context is context |
There was a problem hiding this comment.
Compare the expected RF command by value (or by key attributes) instead of using is, since a separate COMMANDS.load_command(...) call is not guaranteed to return the same object instance.
Breaking change
Proposed change
Add a new
honeywell_string_lightsintegration that drives a Honeywell String Lights set via theradio_frequencyentity platform. All protocol details (frequency, modulation, timings, repeat count) are provided by therf-protocolslibrary — this integration contains no hard-coded RF constants.This PR relies on #168447 — the
radio_frequencyentity platform. This PR is currently stacked on top of that branch.Opened as a draft until the parent PR lands.
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: