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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZHA: Support light flashing #32234

Merged
merged 1 commit into from Feb 29, 2020
Merged

Conversation

@chmielowiec
Copy link
Contributor

chmielowiec commented Feb 26, 2020

Proposed change

Allow flashing the lights with ZHA. This is continuation of zigpy/zigpy#298.
Currently it needs dev branch of https://github.com/zigpy/zigpy @Adminiuga can you release next version with zigpy/zigpy#298?

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 automation
action:
  service: light.turn_on
  entity_id: >-
    light.ikea_of_sweden_tradfri_bulb_e14_ws_opal_400lm_xxxxxxxx_level_light_color_on_off
  flash: short

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:

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
@probot-home-assistant

This comment has been minimized.

Copy link

probot-home-assistant bot commented Feb 26, 2020

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as its been labeled with a integration (zha) you are listed as a codeowner for? Thanks!

@project-bot project-bot bot added this to Needs review in Dev Feb 26, 2020
@chmielowiec chmielowiec changed the title ZHA: Support light flashing WIP: ZHA: Support light flashing Feb 26, 2020
@@ -242,6 +254,8 @@ def add_all_channels(self) -> None:
# on power configuration channel per device
continue
self._channels.power_configuration_ch = channel
elif channel.name == const.CHANNEL_IDENTIFY:
self._channels.identify_ch = channel

This comment has been minimized.

Copy link
@Adminiuga

Adminiuga Feb 26, 2020

Contributor

I haven't checked if there're devices with multiple "identify" clusters, but in case of multiple endpoints and identify clusters, this would keep only the last identify cluster. Is it the intended behavior?

This comment has been minimized.

Copy link
@Adminiuga

Adminiuga Feb 26, 2020

Contributor

what device you've been testing with? Does it have identify cluster on the same endpoint is "on_off" cluster?

This comment has been minimized.

Copy link
@chmielowiec

chmielowiec Feb 27, 2020

Author Contributor

I haven't checked if there're devices with multiple "identify" clusters, but in case of multiple endpoints and identify clusters, this would keep only the last identify cluster. Is it the intended behavior?

It should keep first cluster because of setter guard here: https://github.com/home-assistant/home-assistant/pull/32234/files#diff-accbacd0a97d6988089b194a418cdff5R72. Similar to power config channel.
There are devices like device_no=5 in zha_devices_list.py with multiple identify clusters, but I didn't find any light.

what device you've been testing with? Does it have identify cluster on the same endpoint is "on_off" cluster?

Yes, I have Tradfri bulb similar to device_no=17

This comment has been minimized.

Copy link
@Adminiuga

Adminiuga Feb 29, 2020

Contributor

I think we should use the identify cluster from the same endpoint as the on_off cluster. There are multi-gang wall light switches, that control multiple lights and each endpoint has its own identify cluster. Take a look at device_no: 92 or device_no: 41 -- aqara multi channel relay.
Just add CHANNEL_IDENTIFY to the aux_channels and and use it for commands. Would make it work with two more additional devices ;)

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 26, 2020

this is a clever way to abuse "identify" cluster 馃憤

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 27, 2020

this is a clever way to abuse "identify" cluster 馃憤

It was working for me on zigbee2mqtt, so I implemented same behavior in ZHA.
You can check zigbee2mqtt command here: https://github.com/Koenkk/zigbee-herdsman-converters/blob/63020eab01c272de95dd57a40bd24568891c7537/converters/toZigbee.js#L587.
They use variant 0x01, I will stay with default 0x00, my bulb is ignoring trigger effect variant.

image

@Adminiuga Adminiuga mentioned this pull request Feb 28, 2020
9 of 20 tasks complete
@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

@chmielowiec new zigpy is in. Rebase against latest dev, so it could pass the tests.

@chmielowiec chmielowiec force-pushed the chmielowiec:zha_light_flashing branch from 67c097f to 8407eec Feb 29, 2020
@chmielowiec chmielowiec force-pushed the chmielowiec:zha_light_flashing branch from 8407eec to 8334409 Feb 29, 2020
@chmielowiec chmielowiec requested a review from Adminiuga Feb 29, 2020
@chmielowiec chmielowiec changed the title WIP: ZHA: Support light flashing ZHA: Support light flashing Feb 29, 2020
@codecov

This comment has been minimized.

Copy link

codecov bot commented Feb 29, 2020

Codecov Report

Merging #32234 into dev will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##              dev   #32234   +/-   ##
=======================================
  Coverage   94.75%   94.75%           
=======================================
  Files         775      775           
  Lines       56154    56154           
=======================================
  Hits        53209    53209           
  Misses       2945     2945

Continue to review full report at Codecov.

Legend - Click here to learn more
螖 = absolute <relative> (impact), 酶 = not affected, ? = missing data
Powered by Codecov. Last update e9a7b66...8334409. Read the comment docs.

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 29, 2020

Shouldn't these files removed from omit list in .coveragerc file?
coverage:
homeassistant/components/zha/entity.py 86%
homeassistant/components/zha/light.py 76%
homeassistant/components/zha/sensor.py 89%

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

Shouldn't these files removed from omit list in .coveragerc file?

Funny you ask, same thought crossed my mind a few days ago. Need to confirm the coverage requirements. if not mistaken overall project coverage should be 95%.
We do need to add some tests for lights and sensors to have it better covered and can remove then from coverage ignore.

@@ -242,6 +254,8 @@ def add_all_channels(self) -> None:
# on power configuration channel per device
continue
self._channels.power_configuration_ch = channel
elif channel.name == const.CHANNEL_IDENTIFY:
self._channels.identify_ch = channel

This comment has been minimized.

Copy link
@Adminiuga

Adminiuga Feb 29, 2020

Contributor

I think we should use the identify cluster from the same endpoint as the on_off cluster. There are multi-gang wall light switches, that control multiple lights and each endpoint has its own identify cluster. Take a look at device_no: 92 or device_no: 41 -- aqara multi channel relay.
Just add CHANNEL_IDENTIFY to the aux_channels and and use it for commands. Would make it work with two more additional devices ;)

Dev automation moved this from Needs review to Review in progress Feb 29, 2020
@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

but other than that it looks good.

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 29, 2020

Just add CHANNEL_IDENTIFY to the aux_channels and and use it for commands. Would make it work with two more additional devices ;)

@Adminiuga Yes, I tried this way. It will break entity_id generation, because of name change.

light.ikea_of_sweden_tradfri_bulb_e14_ws_opal_400lm_xxxxxxxx_level_light_color_on_off

will be

light.ikea_of_sweden_tradfri_bulb_e14_ws_opal_400lm_xxxxxxxx_identify_level_light_color_on_off

I don't think identify cluster deserve it. ;-)

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

It is not going to break it for existing lights. But newly joined lights are going to have that new identity which I think is ok.

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

Just would need to update a bunch of test signatures in the dev list.

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 29, 2020

I think we should use the identify cluster from the same endpoint as the on_off cluster. There are multi-gang wall light switches, that control multiple lights and each endpoint has its own identify cluster. Take a look at device_no: 92 or device_no: 41 -- aqara multi channel relay.

None of these devices have multiple identify clusters (cluster_id=0x03)

It is not going to break it for existing lights. But newly joined lights are going to have that new identity which I think is ok.

Ok, it will simplify things. I will change it.

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 29, 2020

It is not going to break it for existing lights. But newly joined lights are going to have that new identity which I think is ok.

Would people need to reconfigure their lights due to supported_features change? Will reconfiguring change entity_id?

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

None of these devices have multiple identify clusters (cluster_id=0x03)

Doh. you're right. I was looking on cluster_id=5 -- Scenes cluster. Disregard the changes then

@chmielowiec

This comment has been minimized.

Copy link
Contributor Author

chmielowiec commented Feb 29, 2020

I found device_id=29 and 30 with light entity and 2 identify clusters, so you were right

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

yeah, I have those, but they don't have "on_off" server cluster on the same endpoint with identify cluster.

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

There was a centrlite motion/occupancy sensor with "identify" cluster in input_clusters on both endpoints, but it really doesn't apply to our case here.

@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

I'm fine with how it is right now, if we get a light device with identify cluster on multiple endpoints then we can revisit.

Copy link
Contributor

Adminiuga left a comment

lgtm

Dev automation moved this from Review in progress to Reviewer approved Feb 29, 2020
@Adminiuga Adminiuga merged commit 8e3492d into home-assistant:dev Feb 29, 2020
10 checks passed
10 checks passed
CI Build #20200229.18 succeeded
Details
CI (FullCheck Mypy) FullCheck Mypy succeeded
Details
CI (FullCheck Pylint) FullCheck Pylint succeeded
Details
CI (Overview CheckFormat) Overview CheckFormat succeeded
Details
CI (Overview Lint) Overview Lint succeeded
Details
CI (Overview Validate) Overview Validate succeeded
Details
CI (Tests PyTest Python37) Tests PyTest Python37 succeeded
Details
cla-bot Everyone involved has signed the CLA
codecov/patch Coverage not affected when comparing e9a7b66...8334409
Details
codecov/project 94.75% remains the same compared to e9a7b66
Details
Dev automation moved this from Reviewer approved to Done Feb 29, 2020
@Adminiuga

This comment has been minimized.

Copy link
Contributor

Adminiuga commented Feb 29, 2020

Thanks for your contribution.

@lock lock bot locked and limited conversation to collaborators Mar 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Dev
  
Done
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can鈥檛 perform that action at this time.