Tint Color Lights doesn't switch colors

[bierkules]

Hi,

I bought Zigbee 3 candles from tint with RGB support and paired them with my hue bridge just fine. I use homebridge-hue 0.11.2. Switching the lights on and off using homekit works just fine, also dimming seems to work. But if I try to change colors nothing happens and the light is shown as not responding. Although it is in fact responding and I can turn it off for example. Switching color using the Hue App oder Alex works.

My homebridge log constnatly repeats the following message:

[2019-1-28 09:14:37] [Hue] Flur 1: set homekit hue from NaN˚ to NaN˚ [2019-1-28 09:14:37] [Hue] Flur 1: set homekit saturation from NaN% to NaN% [2019-1-28 09:14:37] [Hue] Flur 2: set homekit hue from NaN˚ to NaN˚ [2019-1-28 09:14:37] [Hue] Flur 2: set homekit saturation from NaN% to NaN% [2019-1-28 09:14:37] [Hue] Flur 3: set homekit hue from NaN˚ to NaN˚ [2019-1-28 09:14:37] [Hue] Flur 3: set homekit saturation from NaN% to NaN% [2019-1-28 09:14:37] [Hue] Flur 4: set homekit hue from NaN˚ to NaN˚ [2019-1-28 09:14:37] [Hue] Flur 4: set homekit saturation from NaN% to NaN%

My config.json for the homebridge-hue plugin looks as follows: "platform": "Hue", "host": "", "users": { "001788FFFE729A9A": "y5Ue3lTl0uU9epCSsPqi1J6Es8oXUSRqUwiGPgoc" }, "hueMotionTemperatureHistory":true, "sensors": false, "lights": true, "nativeHomeKitSensors": true, "excludeSensorTypes": [], "lowBattery": 25, "nativeHomeKitLights": true, "wallSwitch": true, "groups": false, "group0": false, "rooms": false, "schedules": true, "rules": true, "heartrate": 5, "timeout": 10, "resource": true, "parallelRequests": 10, "waitTimeResend": 300, "waitTimeUpdate": 20 },

Any idea what I'm doing wrong? Any help is much appreciated.

Thank You!

[ebaauw]

The NaNs are not good. The conversion from state.xy to HomeKit’s Hue and Saturation seems to fail. Homebridge-hue is now on v0.11.12, but I don’t think I changed anything in this area since v0.11.2. Could you please attach the debug log file and the debug dump file? See https://github.com/ebaauw/homebridge-hue#debug-log-file and https://github.com/ebaauw/homebridge-hue#debug-dump-file. Please change the light colour from the Hue app and from HomeKit while capturing the debug log file.

[bierkules]

Hi, sorry about the typo I have Homebridge-hue v0.11.12.

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

Thank you for your help and please let me know, if you need anything else.

[ebaauw]

The Hue bridge reports the light having colour gamut red: [0, 0], green: [0, 0], blue: [0, 0]. Probably because that's what the light reports. This breaks the Hue/Saturation to/from state.xy conversion. I was naive enough to think it would be a good idea to read the gamut for unknown lights from the Hue bridge, rather than using the default gamut...

Could you run ph -H 192.168.1.67 probe -v /lights/11 from the terminal/command line? Hopefully that finds out what colour range the light supports, so I can whitelist it. If you haven't run ph before, you need to create a username (API key) first.

Note to self: do a sanity check on gamut values reported by the Hue bridge.

[bierkules]

Just ran ph -H 192.168.1.67 probe -v /lights/11 and here ist the output:

ph probe: /lights/11: cool ... done ph probe: /lights/11: warm ... done ph probe: /lights/11: red ....... done ph probe: /lights/11: green ...... done ph probe: /lights/11: blue ..... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } }

[ebaauw]

Could you try v0.11.13-0? Install by sudo npm -g i homebridge-hue@beta. I cannot test myself, because I don't have an MLI light. Could you please create and attach another debug log file, so I can check whether it works as intended?

[bierkules]

Hi, thx for the effort! Except for red the color it does look good now! Red is more pink. Here comes the debug files where I changed color using siri: homebridge.log.gz

and here I changed the color using the Hue App: homebridge.log.gz

[ebaauw]

Thanks. As far as I can see, homebridge-hue does what it's supposed to do.

Except for red the color it does look good now! Red is more pink.

The red point, [0.5245, 0.2337] as discovered by ph probe, is rather pink-ish. When setting a colour from HomeKit, homebridge-hue forces it to fall within the triangle formed by the R, G, B points.

The Hue app doesn't take this into account, so it sets a colour closer to the right of the colour space.

[2019-1-31 05:53:11] [Hue] Flur 1: light xy changed from [0.3881,0.3289] to [0.6822,0.3045]

I cannot see from the log if the light actually supports this colour (you changed the light to blue before the REST API would reflect the (actual?) colour reported by the light. But I understand from your comment, that it's more red when the colour is set from the Hue app? Was it also more red while running ph probe?

Could you expose group 8 to HomeKit (set "groups": true in config.json) and set the colour of the lights through that group (it will appear as a light in HomeKit). homebridge-hue ignores the gamut when the colour is changed through the group. I'm curious if the light is more red when set through the group, in which case we better ignore the values found by ph probe.

[ebaauw]

Released v0.11.13 and unpublished the beta.

[bierkules]

Sorry for my delayed response I was pretty busy the last days...I changed the setting "groups": true in config.json but here is no light that reflects that particular group. I honestly couldn't find any additional light after changing this setting. Did I miss anything?

Thanks a lot!

[ebaauw]

Did you restart homebridge after changing config.json?

[bierkules]

Yes I did restart homebridge...I also tried starting homebridge -D You can see below, that groups is set to true. I have to say that I have no standard room anymore, I deletetd it sometime ago. Could that be an issue? I would normalyy expect he group to appear in the same room where my homebridge is, but I'm not sure.

config.json: {"platform":"Hue","host":"","users":{"001788FFFE729A9A":"***1"},"hueMotionTemperatureHistory":true,"sensors":false,"lights":true,"nativeHomeKitSensors":true,"excludeSensorTypes":[],"lowBattery":25,"nativeHomeKitLights":true,"wallSwitch":true,"groups":true,"rooms":false,"schedules":true,"rules":true,"heartrate":5,"timeout":10,"resource":true,"parallelRequests":10,"waitTimeResend":300,"waitTimeUpdate":20}

[bierkules]

Okay I set rooms to true an now I have a light reflecting the four bulbs...if I set that to red it is really red but it ends up not responding while the 4 single bulbs in homekit are still responding

[ebaauw]

Just to be sure, could you re-run ph probe making sure that nothing changes the light state, while it's running. If it yields the same results, I'll just ignore these and use the default gamut.

[bierkules]

Good morning I made sure no one was changing lights at home and ran ph -H 192.168.1.67 probe -v /lights/11 again...the output seems to differ for r: ph probe: /lights/11: cool ... done ph probe: /lights/11: warm ... done ph probe: /lights/11: red ... done ph probe: /lights/11: green ..... done ph probe: /lights/11: blue ..... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5308, 0.2769 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } }

EDIT:

I ran the same command again like two minutes later and the output is now: ph -H 192.168.1.67 probe -v /lights/11 ph probe: /lights/11: cool ... done ph probe: /lights/11: warm ... done ph probe: /lights/11: red ................ done ph probe: /lights/11: green ..... done ph probe: /lights/11: blue ............. done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } }

[ebaauw]

While ph probe is trying red, does the light look red or pink-ish?

[bierkules]

It looked pinkish in my second try in my first try it looked more like red.

[ebaauw]

That’s odd. Could I ask you to probe the other MLI lights?

[bierkules]

Absolutely! Whatever it takes :-) All four bulbs looked pinkish this time. Another note from my side: I tried to change color using Alexa which is working accurate as well.

I attached for screenshots from my iPhone for you. I set the color to red in homekit as you can see here: The result is a pinkish and the color in homekit automaticcally goes to: This is also what homekit displays if I switch the color to red with the Hue App where the bulbs are indeed red and not pinkish.

In this way I found out, that I have similar issue with blue. That's what I set in Homekit:

This is what happens to the color automatically when I recheck it:

Green seems to be okay as far as I can see.

ph probe: /lights/11: cool ... done ph probe: /lights/11: warm ... done ph probe: /lights/11: red ... done ph probe: /lights/11: green ..... done ph probe: /lights/11: blue ..... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } } ph probe: /lights/12: cool ... done ph probe: /lights/12: warm ... done ph probe: /lights/12: red ..... done ph probe: /lights/12: green ......... done ph probe: /lights/12: blue ..... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } } ph probe: /lights/13: cool ... done ph probe: /lights/13: warm ... done ph probe: /lights/13: red ..... done ph probe: /lights/13: green ..... done ph probe: /lights/13: blue ...... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } } ph probe: /lights/14: cool ... done ph probe: /lights/14: warm ... done ph probe: /lights/14: red ....... done ph probe: /lights/14: green ..... done ph probe: /lights/14: blue ..... done { "manufacturername": "MLI", "modelid": "ZBT-ExtendedColor", "type": "Extended color light", "bri": true, "ct": { "min": 153, "max": 555 }, "xy": { "r": [ 0.5245, 0.2337 ], "g": [ 0.1112, 0.7717 ], "b": [ 0.1277, 0.1277 ] } }

[ebaauw]

All four bulbs looked pinkish this time.

Do you mean: the colour shown in HomeKit, or the actual colour of the bulb?

Different types of lights support different ranges of colours, depending on what LEDs they use for red, green, and blue. They can only show colours that can be created from mixing their LEDs. When setting a light to a colour that it doesn't support, it should switch to the supported colour that most closely matches the requested colour. Typically, the light reports back the actual (supported) colour.

This leads to weird behaviour in apps: you set the colour to dark blue (which the light doesn't support); the app reflects dark blue, but the light is light blue. The next time time the Hue bridge polls the light, the app reflects the light blue, so in the app the colour seems to change spontaneously, but the light colour does not change.

To overcome this weirdness, apps (like homebridge-hue) try to predict what colour the light will display, by taking into account the colours the light supports. Then the app reflects the actual colour immediately. This still seems a bit weird: you request dark blue but get light blue, but at least the app and the light are sync'ed. There's no way in HomeKit to limit the selectable colours to only those that the light supports.
This prediction only works for lights, not for groups (that could contain different types of lights).

There's something weird with the MLI lights: setting xy to [0.9996, 0.0001] doesn't set it to red, but some pink-ish colour [0.5245, 0.2337]. When setting the light to red in the Hue app, it reports [0.6822, 0.3045] (from your log). Clearly, the light's red point is not [0.5245, 0.2337].

I'm not sure which values the Hue app generates. Could you try ph put /lights/11/state '{"on": true, "xy": [0.8, 0.2]} and then continuously ph get /lights/11/state, until the xy values change (basically doing the same ph probe does, but now with different input values). Wait like a minute or so, and double check that xy hasn't changed.
After that, maybe also try setting xy to [0.8, 0.4] to see if that results in different values.

[bierkules]

All four bulbs looked pinkish this time. Do you mean: the colour shown in HomeKit, or the actual colour of the bulb?

Sorry for the confusion I meant all bulbs were pinkish while I was running ph probe. So the acutal bulbs where pinkish didn't check the home app at this point of time.

`ph -H 192.168.1.67 put /lights/11/state '{"on": true, "xy": [0.8, 0.2]}'

pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.5799, 0.2609 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.5799, 0.2609 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.5799, 0.2609 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.5799, 0.2609 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } ` Result: The bulb's light is pinkish

ph -H 192.168.1.67 put /lights/11/state '{"on": true, "xy": [0.8, 0.4]}' pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.6109, 0.3718 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } pi@raspberrypi:~ $ ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.6109, 0.3718 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true } If I set the bulb to red through the Hue app and query the state I get:

ph -H 192.168.1.67 get /lights/11/state { "on": true, "bri": 254, "hue": 0, "sat": 254, "effect": "none", "xy": [ 0.6724, 0.3245 ], "ct": 555, "alert": "select", "colormode": "xy", "mode": "homeautomation", "reachable": true }

[ebaauw]

v0.11.14 uses the default colour gamut for the MLI lights.

[Bluesmoke82]

Hey there, i am afraid that there is a new issue in version 14. I have 12 tint color lights and they worked fine with version 13. After upgrading to 14 yesterday I had the issue that changing the color was only possible with the native ios hue app. If I wanted to change the color with homekit or eve, the color changed to blue and it wasn't possible to change it. I had to use the hue app to change it.

I downgraded to version 13 and now everything works fine again..

Best Regards Thorsten

[ebaauw]

@Bluesmoke82 could you please attach the debug dump file of and the debug log file v0.11.14, when the lights turn blue? What colour did you try to change the lights to, or does this happen with any colour?

@bierkules do you see the same in v0.11.14?

[Bluesmoke82]

how can I get the debug log file for the version 14? isn't it deleted with the unistalling? It didn't matter which color, every change changed it to blue.

[ebaauw]

See https://github.com/ebaauw/homebridge-hue#debug-log-file. I'm afraid you have to re-install .14 to generate it. I'm sorry, but I need to see what's happening. The only change I made (for lights) between .13 and .14 is removing the specific colour gamut for the MLI lights. I don't understand how that change could cause this, especially since using the group from HomeKit seemed to work.

[Bluesmoke82]

Of course I understand that, I will try to get it done at the weekend.

[tankcom]

Hi,

i have the same exact issue as Bluesmoke82 with the tint lights (Only with E14 sockets). They change to blue every time I try to change the color settings in the home app. The Tint E27 socket lights and the Tint lightstrips work fine in the current version of homebridge(0.11.42).

After Downgrading to 0.11.13 I can change the colors via the home app, but some colours which are achievable via the Philips Hue app are not possible to reach inside the home app (eg. strong yellow, it just results in a very whiteish yellow). When on 0.11.13, the Tint E27 and Tint Lightstrips also get these weak colors, while as I said before they can achieve better colors on 0.11.42.

[ebaauw]

My best guess is that the E14 has different firmware and/or supports a different colour gamut. It defaults to blue (xy = [0, 0]) for unsupported colours. You should be able to get colours out of the Home app, by selecting a more white-ish colour more towards the middle of the wheel.

Can you list the resource created by the Hue bridge and run ph probe -v on the light? Please re-install latest homebridge-hue before running ph.

[tankcom]

For the E14:

ph -H 192.168.2.119 probe -v /lights/29
ph probe: /lights/29: cool ... done
ph probe: /lights/29: warm ... done
ph probe: /lights/29: red ... done
ph probe: /lights/29: green ................ done
ph probe: /lights/29: blue ............ done
{
  "manufacturername": "MLI",
  "modelid": "ZBT-ExtendedColor",
  "type": "Extended color light",
  "bri": true,
  "ct": {
    "min": 153,
    "max": 555
  },
  "xy": {
    "r": [
      0.5245,
      0.2337
    ],
    "g": [
      0.1112,
      0.7717
    ],
    "b": [
      0.1277,
      0.1277
    ]
  }
}

For the E27 (which is working fine):

ph -H 192.168.2.119 probe -v /lights/27
ph probe: /lights/27: cool ... done
ph probe: /lights/27: warm ... done
ph probe: /lights/27: red ................ done
ph probe: /lights/27: green .............. done
ph probe: /lights/27: blue ................... done
{
  "manufacturername": "MLI",
  "modelid": "ZBT-ExtendedColor",
  "type": "Extended color light",
  "bri": true,
  "ct": {
    "min": 153,
    "max": 556
  },
  "xy": {
    "r": [
      0.5245,
      0.2337
    ],
    "g": [
      0.1112,
      0.7717
    ],
    "b": [
      0.1277,
      0.1277
    ]
  }
}

It is always switching back to blue, even if I repeatedly try to hit the middle (white). I can set different white temperatures from the white wheel, however.

The Homebridge log shows the following:

0|homebridge  | [2019-11-18 22:14:36] [Hue] Extended color light 1: homekit hue changed from 209˚ to 132˚
0|homebridge  | [2019-11-18 22:14:38] [Hue] Extended color light 1: set homekit hue from 132˚ to 209˚

No matter where I set it to, a few seconds later it gets reset to 209°, I do not know where the resetting command is coming from

[tankcom]

And one afterthought:

When I move the color picker in the home app, it switches immediately after I stop touching it to the temperature picker while showing a blue dot

and for reference the ph probe output of the tint lightstrip (timeouts?):

ph -H 192.168.2.119 probe -v /lights/28
ph probe: /lights/28: cool ... done
ph probe: /lights/28: warm ... done
ph probe: /lights/28: red ............................................................... timeout
ph probe: /lights/28: green ............................................................... timeout
ph probe: /lights/28: blue ............................................................... timeout
{
  "manufacturername": "MLI",
  "modelid": "RGBW Lighting",
  "type": "Extended color light",
  "bri": true,
  "ct": {
    "min": 155,
    "max": 550
  },
  "xy": {
    "r": [
      0.9961,
      0.0001
    ],
    "g": [
      0.0001,
      0.9961
    ],
    "b": [
      0.0001,
      0.0001
    ]
  }
}

[ebaauw]

I do not know where the resetting command is coming from

Probably from reading back the state from the Hue bridge. Could you capture a debug logfile (running homebridge -D), see https://github.com/ebaauw/homebridge-hue#debug-log-file. This also logs the interaction with the Hue bridge.

Could you also attach the debug dump file, see https://github.com/ebaauw/homebridge-hue#debug-dump-file?

[tankcom]

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

[ebaauw]

Sorry, had a busy week and couldn't analyse the files earlier.

Debug log file:

• You didn't try and set the colour while the collecting the log.
• You're running a pretty old version of NodeJS. I don't think it causing these issues, though.
• Seems like there's a new version of the Hue bridge firmware I hadn't seen yet. Again, probably not causing these issues.

Debug dump file:

• The E27, /lights/27, and the E14, /lights/29, look the same from a ZigBee perspective (same manufacturername and modelid, except for the firmware version (swversion). The E14 seems to have newer firmware. The RGBW strip, /lights/28, seems to have a different firmware altogether.
• The E27 has a Jennic mac address; the E14 and RGBW strip have a Silicon Labs mac address. I'm curious as to what Manufacturer Code they report (in the Node Info panel in the GUI). I expect the E27 and E14 to report the same; and maybe the RGBW strip to report a different one.
• The E14 seems to report a valid gamut; the E27 reports rubbish (that's why homebridge-hue uses the default gamut for MSI lights, see https://github.com/ebaauw/homebridge-hue/commit/a9bb76ad40e95b3cb1b48d0dd952bab29d74b33d). The RGBW strip reports no gamut at all.
• The E27 and E14 report back the actual (?) colour, where the RGBW reports back the last colour set (hence the timeouts in ph probe).
• Oddly, ph probe seems to find the same gamut for the E27 and the E14. This could be an issue with ph probe and/or the MSI firmware. I set xy to [1, 0] to discover red, expecting/hoping the light will display the closest supported colour, which should be the lower right corner of the triangle (see https://github.com/ebaauw/homebridge-hue/issues/439#issuecomment-459483394). However, it would seem the light displays a colour somewhere on the bottom line, hence the pinkish colour instead of red.

When I move the color picker in the home app

The Home app doesn't like a light with both Hue/Saturation and Color Temperature characteristics. Have you tried the Eve app?

Could you please try the following (while running homebridge -D, capturing the debug logfile):

$ ph put /lights/29/state '{"on": true, "bri": 254}'
$ ph put /lights/29/state '{"xy": [0.68, 0.31]}'
# Observe light colour - should be red, not pinkish
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"xy": [0.11, 0.82]}'
# Observe light colour - should be green
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"xy": [0.13, 0.04]}'
# Observe light colour - should be blue
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"on": false}'

Then repeat for /lights/27.

After that (still capturing the debug log file), play around some in the Hue app, setting both the E27 and the E14 to red, green, and blue, waiting a couple of minutes before changing it again.

[tankcom]

Sorry for the late response, I was on a business trip.

homebridge241119-1.log.gz

The E27 has a Jennic mac address; the E14 and RGBW strip have a Silicon Labs mac address. I'm curious as to what Manufacturer Code they report (in the Node Info panel in the GUI).

Which GUI do you mean?

The Home app doesn't like a light with both Hue/Saturation and Color Temperature characteristics. Have you tried the Eve app?

Tried it, same behaviour as in the Home App

[ebaauw]

Setting the lights using ph seems to work as intended. Did the lights show proper red, green, and blue colours?

I think you tried to change the lights from HomeKit after that? Looks like you grouped the two lights in HomeKit? That didn't work at first, since the lights don't accept any state changes while off. After a while, you turned the lights and tried again.

It seems like homebridge-hue picked up the E27's advertised gamut. The HomeKit app sends a couple of updates while selecting red in the colour wheel, but eventually, homebridge-hue sets xy to [0.68, 0.31], the advertised red point:

[2019-11-24 13:01:11] [Hue] Schreibtisch rechts 2: homekit saturation changed from 100% to 7%
[2019-11-24 13:01:11] [Hue] Schreibtisch rechts 2: homekit hue changed from 232˚ to 344˚
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 987: put /lights/27/state {"xy":[0.3392,0.3226]}
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 987: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit saturation changed from 7% to 81%
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit hue changed from 344˚ to 355˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 989: put /lights/27/state {"xy":[0.6513,0.2959]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 989: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit saturation changed from 81% to 100%
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 991: put /lights/27/state {"xy":[0.68,0.31]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 991: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit hue changed from 355˚ to 352˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 993: put /lights/27/state {"xy":[0.68,0.31]}

When reading back the values from the bridge, the HomeKit Hue and Saturation get adjusted somewhat, but I guess this is to be expected from the RGB to CIEE 1931 back to RGB colour space transformations.

[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: get /lights
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: set homekit hue from 352˚ to 7˚
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: set homekit saturation from 100% to 92%

The E14 advertises a bogus gamut (all colour points at [0, 0]), but homebridge-hue applies it anyways, setting xy to [0, 0.0001], which, indeed, is blue! I never set y to 0, since this would cause a divide by zero error converting the colour back to RGB. I found some light firmwares also crash, presumably because of this.

[2019-11-24 13:01:11] [Hue] Extended color light 1: homekit saturation changed from 100% to 7%
[2019-11-24 13:01:11] [Hue] Extended color light 1: homekit hue changed from 209˚ to 344˚
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 986: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 986: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit saturation changed from 7% to 81%
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit hue changed from 344˚ to 355˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 988: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 988: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit saturation changed from 81% to 100%
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 990: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 990: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit hue changed from 355˚ to 352˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 992: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 992: ok

When reading the value back, the Hue jumps to blue:

[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: get /lights
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: set homekit hue from 352˚ to 209˚

On the next poll, the light has adjusted the requested xy values to the actual values:

[2019-11-24 13:01:14] [Hue] Jessi: bridge request 997: get /lights
[2019-11-24 13:01:14] [Hue] Jessi: bridge request 997: ok
[2019-11-24 13:01:14] [Hue] Extended color light 1: light xy changed from [0,0.0001] to [0.1277,0.1278]

Double-checking the logic in homebridge-hue to determine the gamut:

• Check if the model is whitelisted for a specific gamut;
• Check if the manufacturer is whitelisted for a manufacturer default gamut;
• Check if the bridge reports capabilities.control.colorgamut, without actually checking for all [0, 0];
• Apply the default gamut of {"r": [0.9961, 0.0001], "g": [0, 0.9961], "b": [0, 0.0001]}.

As the MLI is no longer whitelisted, homebridge-hue takes the advertised gamut. So I need to whitelist the MLI with the correct gamut, as advertised by the E27. I'm not sure if the same gamut also applies to the RGBW strip. Does that show a pinkish colour when setting it to red?

[ebaauw]

Could you please try homebridge-hue@0.11.44-0? Install by:

$ sudo npm -g i homebridge-hue@beta

It applies the gamut as advertised by the E27 to all MLI lights. This should work for the E27 and the E14, but I'm not sure about the RGBW strip. Could you see if that produces decent colours when set from HomeKit?

[tankcom]

Setting the lights using ph seems to work as intended. Did the lights show proper red, green, and blue colours?

Yes

I'm not sure if the same gamut also applies to the RGBW strip. Does that show a pinkish colour when setting it to red?

The Lightstrip shows the correct colors in the old and new(beta) Version. Both the E27 and E14 now work in the beta Version.

I really appreciate your quick help, thank you.