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

Add support for the color mode attribute #1772

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

nickolas-deboom
Copy link
Contributor

@nickolas-deboom nickolas-deboom commented Nov 21, 2024

Type of Change

  • WWST Certification Request
    • If this is your first time contributing code:
      • I have reviewed the README.md file
      • I have reviewed the CODE_OF_CONDUCT.md file
      • I have signed the CLA
    • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
  • Bug fix
  • New feature
  • Refactor

Checklist

  • I have performed a self-review of my code
  • I have commented my code in hard-to-understand areas
  • I have verified my changes by testing with a device or have communicated a plan for testing
  • I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

CHAD-13851

In certain situations such as after a driver restart, the hue and saturation attributes of the colorControl capability may be overwritten by device attributes that are not currently controlling the color of the device. This change utilizes the ColorMode attribute to check the current color mode before emitting the colorControl capability to prevent this from happening.

Summary of Completed Tests

Tested using a Zemismart Smart Bulb. Without these changes, restarting hubcore results in the CurrentX and CurrentY attributes overriding the colorControl capability which results in the ST app displaying a different color than what the device shows. With the changes, the capability is only emitted after the CurrentHue and CurrentSaturation attributes are received, which results in the ST app matching the color of the device.

Copy link

Copy link

github-actions bot commented Nov 21, 2024

Test Results

   64 files    402 suites   0s ⏱️
2 002 tests 2 002 ✅ 0 💤 0 ❌
3 455 runs  3 455 ✅ 0 💤 0 ❌

Results for commit d59def6.

♻️ This comment has been updated with latest results.

Copy link

github-actions bot commented Nov 21, 2024

File Coverage
All files 93%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/aqara-cube/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/embedded-cluster-utils.lua 38%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua 95%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/eve-energy/init.lua 91%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against d59def6

…SmartThingsCommunity/SmartThingsEdgeDrivers into CHAD-13851-support-color-mode-attribute
device:emit_event_for_endpoint(ib.endpoint_id, capabilities.colorControl.hue(hue))
local current_color_mode = get_field_for_endpoint(device, COLOR_MODE, ib.endpoint_id)
-- don't send capability events if the color of the device is being determined by CurrentX and CurrentY (1) or ColorTemperatureMireds (2)
if current_color_mode == 1 or current_color_mode == 2 then
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be more clear just changing this to

Suggested change
if current_color_mode == 1 or current_color_mode == 2 then
if current_color_mode != 0 then

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did it this way in case a device doesn't implement the ColorMode attribute. In that case, COLOR_MODE will be nil in the driver, so doing the logic this way maintains the same behavior (we only want to prevent capabilities from being emitted if ColorMode is actually implemented)

device:emit_event_for_endpoint(ib.endpoint_id, capabilities.colorControl.saturation(s))
local current_color_mode = get_field_for_endpoint(device, COLOR_MODE, ib.endpoint_id)
-- don't send capability events if the color of the device is being determined by CurrentHue and CurrentSaturation (0) or ColorTemperatureMireds (2)
if current_color_mode == 0 or current_color_mode == 2 then
Copy link
Contributor

Choose a reason for hiding this comment

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

Same idea as above:

Suggested change
if current_color_mode == 0 or current_color_mode == 2 then
if current_color_mode != 1 then

device:set_field(RECEIVED_X, nil)
end
end

local function color_mode_attr_handler(driver, device, ib, response)
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we guaranteed to receive the color mode attribute update before the actually x/y or hue/sat attribute update if it is changed on the device? Do you see this attribute actually change on the device?

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 is a really good point, and no that is not guaranteed. The ColorMode attribute is always sent by the device if it changes however.

I added new logic to color_mode_attr_handler to account for ColorMode not necessarily being received first. When the attribute handlers for Hue, Sat, X, and Y run, they now store the computed Hue and Saturation values, and then emit the hue and sat capabilities depending on the ColorMode. The capabilities are not emitted if ColorMode is set to one of the other 3 possible values. In that case, either the ColorMode is currently set to one of those other values, or it was just changed to a new value but the ColorMode attribute handler hasn't run yet. In the latter case, the ColorMode attribute handler will emit the capabilities using the stored values.

@nickolas-deboom nickolas-deboom force-pushed the CHAD-13851-support-color-mode-attribute branch from 4bffb76 to a809cd9 Compare December 5, 2024 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants