tonesto7 / homebridge-smartthings

SmartThings Homebridge Plugin
384 stars 770 forks source link

(BUG) Homebridge-smartthings cannot setHue to 0 (Red) successfully. But every other color works. #369

Open AlleyGator opened 3 years ago

AlleyGator commented 3 years ago

Verify the following before opening an trouble issue

Go over all the following points, and put an x in all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!


About Your Setup

Expected Behavior

Tell us what you think should be happening

Given that: My homebridge-smartthings hub is successfully handling voice commands for almost every color I can name,

Then: when I issue the siri command "Set cooking lights to red", I should see the following log entries. The lights should turn on, change saturation, and change hue to match these values.

NOTICE: Sending Device Command: on | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setHue | Value: {"value1":0} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setSaturation | Value: {"value1":100} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false)

Current Behavior

What happens instead of the expected behavior? With siri command "Set cooking lights to red", I do see the expected log entries. But the hue of the lights does not change. My suspicion is that the hue of zero is not being stored or sent appropriately to the bridge, causing a null pointer error somewhere in the mix.

NOTICE: Sending Device Command: on | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setHue | Value: {"value1":0} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setSaturation | Value: {"value1":100} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false)

If the lights are off, these commands will:

If I try a different command, "Set cooking lights to red orange", I get hue:1 and saturation:71. Now the following commands are sent, and the hue does change. (The saturation of 71% is unintended but that's how Siri interprets it.)

NOTICE: Sending Device Command: on | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setHue | Value: {"value1":1} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) NOTICE: Sending Device Command: setSaturation | Value: {"value1":71} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false)

A follow-up command, "Set cooking lights to red." or "Set cooking lights saturation to 100%" will fix the saturation (because "red" is hue:0, saturation:100) but the lights will remain set with their hue:1.

Steps to Reproduce (for bugs)

Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include code to reproduce, if relevant

  1. Ask siri to change color of lights to "red" and observe that the lights can turn on, change saturation, but not change hue.
  2. For some reason, asking siri to change color of lights to "red orange" first, and then "red" leaves the lights almost in the correct state. The hue value of "red orange" is interpreted as 1, and the saturation value of "red" is 100.

Context

How has this issue affected you? What are you trying to accomplish? Providing context helps us come up with a solution that is most useful in the real world**

Halloween is coming up, and it would be helpful if people can set their lights to dark red easily.


Please include a copy of any relevant log output to assist in tracking down the bug

AlleyGator commented 3 years ago

Oh, I suppose I should add other commands that have the same problem. In testing this, I found some other combinations that produce the same results:

"Set cooking lights to white" (hue:0, saturation:0) - Neither hue nor saturation change. "Set cooking lights saturation to zero" (saturation:0) - Saturation does not change. "Set cooking lights saturation to one" (saturation:1) - Saturation changes.

"Set cooking lights brightness to zero" - This one is weird and deserves some special mention. The lights do turn off. But then they turn back on again, as if the command was sent to the hub and then rolled back because it thought it failed.

NOTICE: Sending Device Command: setLevel | Value: {"value1":0} | Name: (Cooking 1) | DeviceID: () | SendToLocalHub: (false) INFO: [Device Event]: (Cooking 1) [SWITCH] is off INFO: [Device Event]: (Cooking 1) [SWITCH] is on