Skip to content

Conversation

@nickolas-deboom
Copy link
Contributor

@nickolas-deboom nickolas-deboom commented Feb 11, 2026

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

Incrementing or decrementing the color temp by a small amount can lead to the driver sending the Hue bridge the same value in mireds as the device is already set to, and the bridge not responding, which in turn leads to a spinning wheel in the app and eventually the value being reset to its previous value. This change emits the capability with the updated value without waiting for a response from the bridge if the new mireds value would be the same as the previous.

Summary of Completed Tests

Incrementing or decrementing the color temp by 1 can lead to the driver
sending the Hue bridge the same value in mireds as the device is already
set to, and the bridge not responding, which in turn leads to a spinning
wheel in the app and eventually the value being reset to its previous
value. This change emits the capability with the updated value without
waiting for a response from the bridge.
@nickolas-deboom nickolas-deboom marked this pull request as draft February 11, 2026 22:03
@nickolas-deboom nickolas-deboom marked this pull request as ready for review February 11, 2026 22:03
@github-actions
Copy link

@nickolas-deboom nickolas-deboom marked this pull request as draft February 11, 2026 22:04
@github-actions
Copy link

Test Results

   72 files    485 suites   0s ⏱️
2 518 tests 2 518 ✅ 0 💤 0 ❌
4 333 runs  4 333 ✅ 0 💤 0 ❌

Results for commit a493b40.

@github-actions
Copy link

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against a493b40

@nickolas-deboom nickolas-deboom changed the title Hue: fix issue with color temp increment of 1 kelvin Hue: fix issue with small color temp increments Feb 11, 2026
if current_mirek == mirek then
log.debug(string.format("Color temp change from %dK to %dK results in same mirek value (%d), emitting event directly", current_color_temp, clamped_kelvin, mirek))
device:emit_event(capabilities.colorTemperature.colorTemperature(clamped_kelvin))
return
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should still send the command to the bridge and not return early here. It might be possible that the user changed the temp in the hue app and we never emitted an event for the change so we might actually be changing it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah good point!

for _, device in ipairs(group.devices) do
device:emit_event(capabilities.colorTemperature.colorTemperature(clamped_kelvin))
end
return
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar reasoning as above for not returning early here.

end
end

if all_same_mirek and #group.devices > 0 then
Copy link
Contributor

Choose a reason for hiding this comment

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

Rather then checking if they are all the same mirek, I wonder if we want to track all the devices that have the same mirek and then emit the event for all of those devices. I'm not sure how this interaction works with the grouped lighting but it seems like if only one device had the same mirek then the bridge might not send anything for that specific 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.

Yeah good call. When I was testing it I had all my bulbs at the same color temp value and neglected to think of the case where they are at different values initially.

---@param bridge_device HueBridgeDevice
---@param group table
---@param args table
---@param aux table auxilary data needed for the command that the devices all had in common
Copy link
Contributor

Choose a reason for hiding this comment

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

at least I am a consistent bad speller 🥲

@nickolas-deboom nickolas-deboom marked this pull request as ready for review February 12, 2026 21:37
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