Skip to content
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

Introduce wiz_light integration for WiZ bulbs #44522

Closed
wants to merge 24 commits into from
Closed

Introduce wiz_light integration for WiZ bulbs #44522

wants to merge 24 commits into from

Conversation

sbidy
Copy link
Contributor

@sbidy sbidy commented Dec 25, 2020

Proposed change

A HA integration for WiZ Light bulbs (Phillips, SLV and more). The integration extents HA to communicate directly with this WiFi connected lights via async UDP calls. There is no Cloud or Web API needed for interaction with this lights.

The integration is designed async, including the UDP calls via pywizlight extension.

Supported Features:

  • Brightness
  • Color (RGB)
  • White Color Temperature
  • On/Off, Toggle
  • Effects
  • Bulb feature detection. Mapping up to 16 different bulb feature sets.

wiz_light GitHub // pywizlight

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml
light:
  - platform: wiz_light
    name: Name_Bulb_1
    host: 127.0.0.1
  - platform: wiz_light
    name: Name_Bulb_2
    host: 127.0.0.2

ConfigFlow is also available.

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • [] No score or internal
  • 🥈 Silver
  • 🥇 Gold
  • 🏆 Platinum

def read_bulblib():
"""Read the library of bulbs from YAML."""
# fetch the location of the lib yaml
__location__ = os.path.realpath(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this roundabout way of getting the path necessary? I haven't tried it myself within HA's environment but __file__ is absolute in my command line experiments and the Python issue tracker indicates this should always be the case.

{
"domain": "wiz_light",
"name": "WiZ Light Integration",
"documentation": "https://github.com/sbidy/wiz_light",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation should point at HA's official docs since this is being integrated.

@@ -0,0 +1,22 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your translation file has more/different values than the base strings.json file.

Copy link
Contributor Author

@sbidy sbidy Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know. Is it possible to generate these?

from homeassistant.const import CONF_IP_ADDRESS, CONF_NAME
from homeassistant.data_entry_flow import AbortFlow

from .const import DEFAULT_NAME, DOMAIN # pylint: disable=unused-import
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both of these imports are used. Why does pylint need to be disabled?

Copy link
Contributor Author

@sbidy sbidy Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why this pups up in the test stack. In my devcontainer pylint doesn't shows me an error.
Seems to be a false positive.

return self.async_create_entry(
title=user_input[CONF_NAME], data=user_input
)
return self.async_abort(reason="no_IP")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be more typical for a config flow to return the async_show_form with errors[CONF_IP_ADDRESS] = "no_IP" to allow the user to correct the problem.

@@ -0,0 +1 @@
"""Tests for the WiZ Light integration integration."""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will be surprised if The Powers That Be approve this PR without any unit tests for the integration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct but there are almost no documentation how and what to test.
I will start to dig in the pytesing of HASS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use our scaffold script to generate example code including tests for the config flow using best practices patterns.

Copy link
Contributor Author

@sbidy sbidy Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already used the script to generate the pattern. But overall there will no "test" generated.
The only docs for the testing I have found are here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does generate test code. Please try again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it doesn't in the current dev branch via devcontainer. I also tried it with an "clean" demo integration. It also doesn't create a test. Only the init will be created.

I'll try to reproduce and create a test manually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I run this on dev branch (and answer the questions):

python -m script.scaffold integration

I get this output:

Integration code has been generated

Added the following files:
- homeassistant/components/wiz_light/manifest.json
- homeassistant/components/wiz_light/config_flow.py
- homeassistant/components/wiz_light/__init__.py
- homeassistant/components/wiz_light/const.py

Added the following tests:
- tests/components/wiz_light/test_config_flow.py

The next step is to look at the files and deal with all areas marked as TODO.

scaffold_wiz_light

@craigcabrey
Copy link

Testing this locally, I get the following error:

2020-12-26 18:45:11 ERROR (MainThread) [homeassistant.setup] Error during setup of component wiz_light
Traceback (most recent call last):
  File "/home/craigcabrey/Documents/core/homeassistant/setup.py", line 200, in _async_setup_component
    task = component.async_setup(hass, processed_config)  # type: ignore
TypeError: async_setup() takes 1 positional argument but 2 were given

It also seems to only allow adding one light at a time. Ideally, we should be able to add a bunch of lights at once (since otherwise it'll require adding a new integration each time).

@caesar1987sk
Copy link

caesar1987sk commented Dec 27, 2020

It also seems to only allow adding one light at a time. Ideally, we should be able to add a bunch of lights at once (since otherwise it'll require adding a new integration each time).

It is possible to add multiple of them, I have integrated 2 wiz lights with this integration.

Edit: they are added using yaml not ui, maybe you mean this, not sure.

@sbidy
Copy link
Contributor Author

sbidy commented Dec 30, 2020

It also seems to only allow adding one light at a time. Ideally, we should be able to add a bunch of lights at once (since otherwise it'll require adding a new integration each time).

It is possible to add multiple of them, I have integrated 2 wiz lights with this integration.

Edit: they are added using yaml not ui, maybe you mean this, not sure.

Yes, via config.yaml it is possible. But it should also be possible to add more than one per intergration.

@craigcabrey please run it and delete the test "Wiz Light" integration via web interface. This was added for testing from my side.

@sbidy sbidy requested a review from MartinHjelmare December 30, 2020 22:16
@MartinHjelmare
Copy link
Member

Please make sure the build passes. Run hassfest and translations develop scripts and check the CI build error output. And add tests for the config flow. That's the minimum tests required.

@sbidy
Copy link
Contributor Author

sbidy commented Dec 31, 2020

Close because of missing tests and issues with the branch. Reopen and create reference.

@sbidy sbidy closed this Dec 31, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Jan 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants