Unable to change between RGB and CCT modes

[llamafilm]

Issue

I have a Gledopto RGB+CCT strip which presents as a single device with both color and white options. It's connected to Homebridge with deCONZ. I created two scenes with Eve. The night scene sets brightness = 50% and color = red. The day scene sets brightness = 100% and color temperature in white mode. When I switch between these two scenes, the brightness changes but the color stays the same.

It's curious that every time I set a scene, the log shows two state changes.

It looks like we need a way to change the colormode between xy and ct. Is this possible? I don't see this exposed in Eve, but I figure it should happen automatically. Eve shows two separate parameters for Color and Color Temperature. Inside the Color are two tabs to choose color or white. This seems redundant, but nevertheless I have tried making the day scene both ways and I get the same result.

Log Messages

Setting day scene:

[11/7/2020, 7:10:39 PM] [Hue] Cabinets: state changed event: {"bri":254,"colormode":"ct","ct":210,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}
[11/7/2020, 7:10:41 PM] [Hue] Cabinets: state changed event: {"bri":255,"colormode":"ct","ct":210,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}

Setting night scene:

[11/7/2020, 7:10:45 PM] [Hue] Cabinets: state changed event: {"bri":127,"colormode":"ct","ct":210,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}
[11/7/2020, 7:10:47 PM] [Hue] Cabinets: state changed event: {"bri":126,"colormode":"ct","ct":210,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}

Debug Files

homebridge-hue.json.gz homebridge.log.gz

[ebaauw]

From the log, you're only setting Brightness from HomeKit. If you did recall the HomeKit scenes while capturing they log, the don't include colour (temperature). Otherwise, please capture a debug log, while recalling the scenes.

colormode is read-only; it reports xy after setting state.xy and ct after setting state.ct. Homebridge Hue sets xy when you change Hue and/or Saturation, and ct when you change Color Temperature. The Home app only sets Hue and Saturation (even if you use the Temperature wheel; in Eve you can set Color Temperature.

[llamafilm]

The debug log I attached shows the attempt to switch between these two scenes. I do see that it's only changing brightness, and that's precisely the problem here. If I make another scene that sets a different color (e.g. green), then I can switch between green and red scenes just fine. Similarly, I can switch between warm and cool white scenes fine. I just can't switch between color and white. Do you think Eve app is doing something wrong here? This is how I have made the two scenes:

[ebaauw]

I just can't switch between color and white. Do you think Eve app is doing something wrong here?

Ah, that makes sense: the HomeKit runtime sees the scenes would set the Color Temperature (or Hue/Saturation) to their current values, and excludes them from the command sent to the accessory (i.c. Homebridge).

Damn, no matter what I try, colour temperature continues to cause issues, see #121, #353, #571, #708. HomeKit doesn't cater for RGB+CCT lights, supporting both colour and colour temperature, wrongly thinking that colour temperature can be translated to Hue and Saturation always. When exposing the standard Color Temperature characteristic in addition to Hue/Saturation, the Color and Temperature wheels in Apple's Home app behave strangely. That's why I reverted to the custom Color Temperature, previously used by Hue. Unfortunately, HomeKit has no equivalent of colormode and doesn't understand the relationship between Hue/Saturation and the custom Color Temperature.

I probably need to "invalidate" the Hue and Saturation values when setting Color Temperature and vice versa. And that without breaking HomeKit compliance, so they still need to have valid values. But then again, the Color wheel is likely to "jump" when setting the Temperature wheel in the Home app.

I understand that the Eve lightstrip, now supporting adaptive lighting, actually exposes both Hue/Saturation and Color Temperature. Maybe Apple changed the HAP spec for the benefit of adaptive lighting, maybe Eve found a better workaround than I did, maybe the Home app behaves just as erraticly. I don't own that device, so I have to wait until Hue brings out adaptive lighting and see how they expose it, and how they invalidate the other attributes.

[ebaauw]

I probably need to "invalidate" the Hue and Saturation values when setting Color Temperature and vice versa

Strike that. This issue is (at least in part) caused by the GLEDOPTO firmware, for not updating ct when setting xy and v.v. Hue lights do this, which Homebridge Hue translates back to HomeKit, so the colour more or less reflects the colour temperature. And reading back my conversation with @Supereg, the Eve lightstrip does the same, at least when adaptive lighting is enabled.

[llamafilm]

I sent a message to Eve app support as well, maybe they can shed some light on this. According to the HAP specification release R2, it sounds like including RGB and CCT in the same light is not compliant. Am I reading this correctly?

9.21 Color Temperature

If this characteristic is included in the ”8.23 Light Bulb” (page 147), ”9.44 Hue” (page 179) and ”9.82 Saturation” (page 197) must not be included as optional characteristics in ”8.23 Light Bulb” (page 147). This characteristic must not be used for lamps which support color.

How can the Gledopto controller help here? I thought it is receiving only bri parameter.

[Supereg]

Although the spec states differently ColorTemperature characteristic in combination with Hue/Saturation was kind of supported. If both three where added ColorTemperature was used to write when you select a Temperature in the Home App. The accessory would need to correctly translate that temperature to the correct Hue/Saturation value as those two values are always used to display the current "color". This is what my understanding previously was. Latest Eve Light Strip firmware release (which added the ColorTemperature characteristic as of AmbientLightning support) does it the same way, so I assume my understanding is still somewhat correct.

One thing I noticed is that the Home app will always open the "color" color picker regardless what "type of color" was set previously (like Hue/Saturation vs ColorTemperature). That also applies to the Eve Light strip. I can't remember exactly, but I think that wasn't always the case.

Edit: Would be really interesting and helpful to get hands on the latest spec 🙃

[llamafilm]

From the command-line these commands are working as expected, so I believe the controller is fine. What's not clear to me, is the problem with Eve or with the plugin? Is there some way to get debug logs from HomeKit itself to see what Eve is sending?

ph put /lights/6/state '{"bri":128, "xy": [0.7006,0.2993]}'
ph put /lights/6/state '{"bri":255, "ct": 210}'

[llamafilm]

I think there is some confusion here because there are two different ways of getting a white light. One way is by mixing R,G,B diodes. The other way is by using separate cool and warm white diodes. This allows a nicer quality of light without any weirdness from the color mixing. This is what the Gledopto does and it's the reason I bought it. So the light strip actually has 5 diodes - R,G,B, warm white, and cool white. With this method, I don't think it makes sense to translate x,y color values into mireds.

[ebaauw]

What's not clear to me, is the problem with Eve or with the plugin?

Neither. The problem is a combination of the HAP specification and the GLEDOPTO firmware. Homebridge Hue is already working around the HAP spec issues, but currently is expecting RGB+CCT lights to behave like Hue lights that do the xy to ct translation in firmware. I.e. they report back the corresponding xy values when setting ct and vice versa.

With this method, I don't think it makes sense to translate x,y color values into mireds.

Correct. Unfortunately, both HomeKit and the Zigbee standard (regarding scenes) fail to understand this.

[llamafilm]

I see, that makes sense. Gledopto makes another version of these controllers that presents color and white as two separate lights. I guess that would have been more compatible with the current HAP spec. As a workaround, is it possible to make a special case for these controllers in the plugin? Maybe compare the current state with the desired values and see which one changed.

[ebaauw]

No can do. That’s what HomeKit is doing already, deciding it doesn’t need to send the desired state, so Homebridge Hue never gets to see the desired state (see the Homebridge log).

Is there some way to get debug logs from HomeKit itself to see what Eve is sending?

Eve only talks to the HomeKit runtime, using the HomeKit API. The HomeKit runtime talks to accessories (incl. Homebridge) over the HAP protocol. I wouldn’t know how to monitor the HomeKit API; I suppose the HomeKit app would need to provide something for that. To see the HAP messages, run DEBUG=* homebridge -D. Study the HAP spec to understand what you see, and use the IdentifierCache.json file in the persist directory to map the aid and iid values to accessories, services, and characteristics.

I would need to compute and set the corresponding Hue/Saturation values when the controller is in ct mode and Color Temperature when in xy mode. I’ve seen some algorithms for that on the web, but the involved math is beyond me. I would need to test by comparing the computed values against those reported by Hue lights.

[llamafilm]

Actually I think you have already done the necessary calculations. Here's the log with DEBUG=HAP-NodeJS:Accessory. From observation, I think the IID numbers are like this: 10 = On 15 = Saturation 11 = Brightness 13 = Color Temperature 14 = Hue

When I set the white scene, HAP tries to set color temperature to 195 (mireds, I think). When I set the red scene, HAP tries to set hue to 360. So HAP-NodeJS is sending the right commands matching what I have set in Eve. I believe the plugin compares this with the current state, and decides not to set hue / ct because it's the same. So all we need to do is send the command coming from HAP even if it seems redundant, translating hue/sat into x,y coordinates which your plugin can do already.

White scene:

2020-11-09T14:04:21.629Z HAP-NodeJS:Accessory [Homebridge 399A] Processing characteristic set: [{"aid":13,"iid":10,"value":1},{"aid":13,"iid":15,"value":100},{"aid":13,"iid":11,"value":100},{"aid":13,"iid":13,"value":195}]
2020-11-09T14:04:21.630Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "On" to value 1
2020-11-09T14:04:21.631Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Saturation" to value 100
2020-11-09T14:04:21.632Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Brightness" to value 100
[11/9/2020, 9:04:21 AM] [Hue] Cabinets: homekit brightness changed from 50% to 100%
2020-11-09T14:04:21.634Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Color Temperature" to value 195
[11/9/2020, 9:04:21 AM] [Hue] Phoscon-GW: gateway request 26: put /lights/6/state {"bri":254}
[11/9/2020, 9:04:21 AM] [Hue] Phoscon-GW: gateway request 26: ok
[11/9/2020, 9:04:21 AM] [Hue] Cabinets: state changed event: {"bri":254,"colormode":"ct","ct":195,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}

Red scene

2020-11-09T14:03:02.281Z HAP-NodeJS:Accessory [Homebridge 399A] Processing characteristic set: [{"aid":13,"iid":10,"value":1},{"aid":13,"iid":15,"value":100},{"aid":13,"iid":11,"value":50},{"aid":13,"iid":14,"value":360}]
2020-11-09T14:03:02.281Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "On" to value 1
2020-11-09T14:03:02.282Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Saturation" to value 100
2020-11-09T14:03:02.283Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Brightness" to value 50
[11/9/2020, 9:03:02 AM] [Hue] Cabinets: homekit brightness changed from 100% to 50%
2020-11-09T14:03:02.286Z HAP-NodeJS:Accessory [Homebridge 399A] Setting Characteristic "Hue" to value 360
[11/9/2020, 9:03:02 AM] [Hue] Phoscon-GW: gateway request 9: put /lights/6/state {"bri":127}
[11/9/2020, 9:03:02 AM] [Hue] Phoscon-GW: gateway request 9: ok
[11/9/2020, 9:03:02 AM] [Hue] Cabinets: state changed event: {"bri":127,"colormode":"ct","ct":195,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}

P.S. Why do you need to translate hue/sat to x,y ? It seems like the light can accept either one?

[ebaauw]

Why do you need to translate hue/sat to x,y ? It seems like the light can accept either one?

Zigbee uses the CIE 1931 colour space; HomeKit uses the RGB colour space. The translation of Hue and Saturation to xy is converting the colour from RGB to CIE 1931. Different models of Zigbee lights display different colours with the same (Zigbee) hue and sat values, effectively rendering them utterly useless. See https://developers.meethue.com/develop/get-started-2/core-concepts/.

[ebaauw]

I think the IID numbers are like this:

Just to be sure, could you list the relevant part (aid 13) of IdentifierCache.json?

I believe the plugin compares this with the current state, and decides not to set hue / ct because it's the same.

Indeed that's right - I stand corrected. So it's not the HomeKit runtime, but Homebridge Hue that discards the unchanged values.

Still, assuming your iid mapping is correct, the White scene contains both Color Temperature and Saturation ?! If I were to disable the check for changed values in Homebridge Hue, it would result in an API call setting both xy (from Saturation and ct (from Color Temperature). The API ignores ct in favour of xy, so that still wouldn't work. Can you double-check the White scene? I need to drop xy when ct has been specified.

Could you try v0.12.1-0? Install through Homebridge Config UI X, or sudo npm -g homebridge-hue@beta. Please capture a debug log file recalling both scenes two times, or so.

[ebaauw]

the White scene contains both Color Temperature and Saturation

Courtesy of Eve. It adds Brightness and Saturation to the scene for free. I could remove it by selecting and then de-selecting Color while editing the scene.

[llamafilm]

I'm on 0.12.0 and the config UI doesn't show any updates. Is there a setting to use the beta branch instead?

Here is the section of IdentifierCache, although I don't really know how to read this:

        "07ee018d-dc9e-4979-9af8-7d48b061c00d": 13,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000014-0000-1000-8000-0026BB765291": 2,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000020-0000-1000-8000-0026BB765291": 3,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000021-0000-1000-8000-0026BB765291": 4,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000023-0000-1000-8000-0026BB765291": 5,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000030-0000-1000-8000-0026BB765291": 6,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|0000003E-0000-1000-8000-0026BB765291|00000052-0000-1000-8000-0026BB765291": 7,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b": 8,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000008-0000-1000-8000-0026BB765291": 11,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000013-0000-1000-8000-0026BB765291": 14,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000021-0000-1000-8000-656261617577": 18,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000023-0000-1000-8000-0026BB765291": 9,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000025-0000-1000-8000-0026BB765291": 10,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|0000002F-0000-1000-8000-0026BB765291": 15,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000057-0000-1000-8000-656261617577": 12,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000059-0000-1000-8000-656261617577": 16,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000060-0000-1000-8000-656261617577": 19,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000061-0000-1000-8000-656261617577": 20,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|00000077-0000-1000-8000-0026BB765291": 17,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|000000E3-0000-1000-8000-0026BB765291": 21,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|00000043-0000-1000-8000-0026BB765291|0b|E887EF67-509A-552D-A138-3DA215050F46": 13,
        "07ee018d-dc9e-4979-9af8-7d48b061c00d|nextIID": 22,

I do believe the white scene is setting both saturation and color temp. This doesn't really make sense, but I guess saturation should be ignored in this case.

[llamafilm]

I updated to 0.12.1 via command-line and now this is working! Thank you very much. One other question: Why does the log sometimes show two state changes at once? Like this:

[11/9/2020, 1:43:24 PM] [Hue] Phoscon-GW: gateway request 36: put /lights/6/state {"xy":[0.7006,0.2993],"bri":127}
[11/9/2020, 1:43:24 PM] [Hue] Phoscon-GW: gateway request 36: ok
[11/9/2020, 1:43:24 PM] [Hue] Cabinets: state changed event: {"bri":127,"colormode":"xy","ct":195,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}
[11/9/2020, 1:43:25 PM] [Hue] Cabinets: state changed event: {"bri":126,"colormode":"xy","ct":195,"effect":"none","hue":1792,"on":true,"reachable":true,"sat":255,"xy":[0.7006,0.2993]}
[11/9/2020, 1:43:25 PM] [Hue] Cabinets: light bri changed from 127 to 126

Debug log attached for your reference.

homebridge.log

[ebaauw]

Is there a setting to use the beta branch instead?

Install previous version from the Plugins panel.

Here is the section of IdentifierCache

Thanks. Your mapping is correct.

I don't really know how to read this

• UUID of the accessory: aid;
• UUID of the accessory | UUID of the service | optional subtype: iid.
• UUID of the accessory | UUID of the service | optional subtype | UUID of the characteristic: iid.

iid 1 is for the Accessory Information service, which isn't listed.

The UUIDs 00000xxx-0000-1000-8000-0026BB76529 are defined by Apple in HAP, see https://github.com/homebridge/HAP-NodeJS/blob/master/src/lib/gen/HomeKit.ts and other files in that directory.

The UUIDs 00000xxx-0000-1000-8000-656261617577 are my own defined custom UUIDs, see https://github.com/ebaauw/homebridge-lib/blob/master/lib/MyHomeKitTypes.js.

E887EF67-509A-552D-A138-3DA215050F46 is the custom Color Temperature that Hue used to use, but is still recognised by Eve, see https://github.com/ebaauw/homebridge-lib/blob/master/lib/EveHomeKitTypes.js.

[ebaauw]

Why does the log sometimes show two state changes at once? Like this:

Not at once (look at the timestamp). The first is when the API updates its cached based on the command received (and sent over Zigbee to the light). The second is when the API cache is update when the light is next polled (or when the sends an attribute report, for lights that support that). Set /config/websocketnotifyall to false to have deCONZ only report the changed attributes in the event.

[llamafilm]

Cool! This is quite a complex project with layers - plugins, homebridge, and HAP itself. I appreciate all the work you and the other devs have done.

One thing I notice now when switching between these two scenes: The hue / ct changes immediately, while the brightness fades for about 1 second. I think the fade time is built into the Gledopto controller because it always does this when controlled by the RF remote. So if I switch between my green and red scenes it does a fade. I don't think this is a problem at all, just an interesting note.

[llamafilm]

So does it mean this particular light just doesn't support brightness value of 127, so when you send that command, it changes itself to either 126 or 128?

[ebaauw]

now this is working

That's good news. I think I prefer this approach over computing the ct values from xy or v.v. I just hope this doesn't brake anything for some other weird light...

Note how on (and bri, but not visible in the log file) are still excluded when their value hasn't changed.

I think the fade time is built into the Gledopto controller because it always does this when controlled by the RF remote. So if I switch between my green and red scenes it does a fade. I don't think this is a problem at all, just an interesting note.

Homebridge Hue doesn't specify a transitiontime, leaving it up to the light to apply its default (for Hue that's 0.4s). You can include TransitionTime in the scene (in the bridge/gateway accessory) and see if that makes a different. Not sure if the GLEDOPTO is capable of transitioning the switch from RGB to CCT or v.v., or only the change within these channels.

So does it mean this particular light just doesn't support brightness value of 127, so when you send that command, it changes itself to either 126 or 128?

Probably. You can check in the deCONZ GUI to be sure. I don't think GLEDOPTO does attribute reporting? Otherwise it could also be that you receive a report from before the transition has finished.

[llamafilm]

You can include TransitionTime in the scene (in the bridge/gateway accessory) and see if that makes a different. Not sure if the GLEDOPTO is capable of transitioning the switch from RGB to CCT or v.v., or only the change within these channels.

Cool! I didn't know about this feature. If I use a transition time of 10 seconds and this works between green and red. But the transition between red and white is still instant, while the brightness fades over 10 seconds. I think this is fine for my needs now, but some people might have a problem in this scenario:

1. Start with green scene
2. Set white scene (color changes instantly, brightness fades slowly)
3. Set red scene (color changes instantly to green, then brightness and color both fade to green slowly)

I guess the workaround is to set transitiontime to zero in that case. Or is there a way to make a "chain" of actions, for example fade brightness to zero, then change the color, then fade brightness back up?

Eve sets transition time with a slider up to 3600 seconds so it's hard to set a precise value. Can this be done with ph command-line?

[ebaauw]

Or is there a way to make a "chain" of actions, for example fade brightness to zero, then change the color, then fade brightness back up?

You'd have to time the change of the colour to be issues right after the transition of the brightness fading has finished. You could do this from a series of gateway rules (using ddx operator to time the next command, and probably a CLIPGenericState sensor to keep track of where you are in the sequence). I'm doing something like this for my wakeup scene (turn on the lights at minimum brightness, and the music; then to turn up the light brightness to full in 10 minutes, and then open the curtains and the downstairs radiator valves, so the bedroom and bathroom heat up first). I expose the status sensor to HomeKit, and use HomeKit automations for the non-Zigbee devices (Sonos), but the logic resides in deCONZ.

Eve sets transition time with a slider up to 3600 seconds so it's hard to set a precise value.

Home doesn't support custom characteristics (like TransitionTime), Eve shows a slider, not providing precise control, unless you only use a small range. This is where I use Home+. I've fantasised about exposing multiple characteristics, for 0.1s, for 1s, for 10s, for 1m, for 10m, but that feels too geeky. Maybe using a validValues could cause Eve to display a list of values instead of a slider? Doesn't look like Eve supports validValues :-(

Can this be done with ph command-line?

Sure, specify something like ph put /lights/xx '{"ct": 500, "transitiontime": 100}'. You could use a simple bash script with a couple of ph and sleep commands. And then use a Homebridge plugin to start the script from HomeKit.

[mortonpd]

I have this "issue" with a Home(kit) -> Philips Hue -> Giderwel 1ID RGBCCT LED controller -> GIDERWEL RGBWW LED Strip Lights. The Philips Hue app switches between RBG or CT (not both at the same time) as if it was 2 separates lights. Indeed if I was to use the 2ID controller they would show up as 2 separate lights.

What I was wondering, as a workaround for this combination of products, could homebridge-hue virtually split the RGB and CT lights so that they appear as 2 separate lights within Home(kit)? (i.e. 1 RGB lights, and a separate CT light that sends values to the same controller?)

[llamafilm]

@mortonpd did you try the beta version 0.12.1 just published today? That solved it for me.

[mortonpd]

@mortonpd did you try the beta version 0.12.1 just published today? That solved it for me.

Yes, I did try the update but no, it did not work. I traced the cause to the wrong ColorTemperature characteristic being set. It was being set to the EveHomeKit UUID instead of the HomeKit one of 000000CE-0000-1000-8000-0026BB765291.(NOTE: I do not have Eve anywhere in my setup)

Tested a simple change in the code of setting this.colorTemperatureCharacteristic = Characteristic.ColorTemperature instead of

this.colorTemperatureCharacteristic = this.config.xy
        ? eve.Characteristics.ColorTemperature
        : Characteristic.ColorTemperature

and it started to work correctly for me.

However, I now have a different issue where the color selected on the Temperature wheel is showing the Color selection instead of the Temperature value after updating the lights.

[llamafilm]

That sounds like a bug or limitation in Apple's Home app. That app does not have very good support for RGB+W lights. I suggest using Eve or some other app.

[ebaauw]

This issue has become outdated with iOS 14.2 (or earlier iOS 14?) that handles colour temperature differently, since the introduction of Adaptive Lighting. See #814.