Problem changing light color in HomeKit since 0.81.

[timothybrown]

Home Assistant release with the issue: 0.81.x

Last working Home Assistant release (if known): 0.80.3

Operating environment (Hass.io/Docker/Windows/etc.): Raspberry Pi 3B, Raspbian 9, Python 3.5

Component/platform: https://www.home-assistant.io/components/homekit/

Description of problem: Since the upgrade, RGB lighting entities no longer function correctly in HomeKit. For example, I have an RGB bulb running ESPurna that connects to HA via the MQTT Light component and HA forwards that light to HomeKit. Since 0.81 I can no longer directly change the bulb’s color in HomeKit using the color wheel; however, the color temperature wheel does still work. The weird thing is, If I change the color temperature first, then I’m able to change the bulb’s color once. The color wheel shows up for the device in HomeKit, however the change is never actually applied by HA. Initially, HomeKit shows the device color as having changed, but if you back out of the light’s color settings and come back it shows the color didn’t actually change (as reflected in HA and by the light itself).

So: Change Color Temperature -> Change Color works. But: Change Color -> Change Color doesn’t work.

I’ve verified changing the bulb’s color multiple times directly in HA works fine. I’m also seeing the HomeKit requests in the HA log when trying to change color. After downgrading to 0.80.3 the problem goes away, so there seems to be an issue with either some of the HomeKit changes made in 0.81.x or problems with the new version of hap-python that 0.81.x is using.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

mqtt:
  broker: localhost
  username: hass
  password: !secret mqtt_password
  client_id: HASS-<MAC Address Removed>
  birth_message:
    topic: 'homeassistant/status'
    payload: 'online'
  will_message:
    topic: 'homeassistant/status'
    payload: 'offline'
  discovery: true
  discovery_prefix: homeassistant

# Apple Homekit Bridge
homekit:
  auto_start: false
  filter:
    include_entities:
      - light.ceiling_fan_light
      - light.bathroom_light
      - light.hallway_light
      - media_player.directv
      - switch.audio_stack
      - switch.desk_lamps
      - switch.soldering_iron
      - climate.thermostat77083b
      - sensor.bme680_temperature
      - sensor.bme680_humidity

Traceback (if applicable):

Additional information:

[cdce8p]

Does this error occur for all lights (even different platforms)? Can you test the demo light platform. I ran a quick test and didn't noticed anything unusual. It's probably not the HAP-python update, since that included mostly bugfixes.

[treetopsflyer]

Same Issue. Yeelight RGB bulb. HassIO 1.4.0

[timothybrown]

@cdce8p I meant to mention that, as a test, I included one of my LIFX bulb entities in the HomeKit bridge (or maybe it was a Flux LED bulb I had sitting around; I’ve done so much testing the last few days I can’t remember) and it had the same problem. And yes, all three MQTT lights had the same issue. I can see the HomeKit requests going across the network and HA logs having received the request, but it never seems to get through the HomeKit Bridge component and to the light entity.

I also determined that I could get the color change to work without first using the color temperature wheel. It seems that if you select values on the outside of the regular color wheel (that is, change the hue while staying at maximum saturation), the change doesn’t go through, if however you first select a lighter/more white shade of color (any hue value, below maximum saturation) it’ll let you select a color on the outside of the wheel again, but just once. The reason going to the color temperature wheel and back to the normal color wheel works is because all the colors on the temperature wheel have a non-maximum saturation value.

In fact, as long as the saturation value isn’t maxed, you can change to any hue you want as many times as you want. It’s only when the saturation is maxed that it doesn’t work.

This would indicate to me something is broken in a HSV to RGBW function, or a variable isn’t being updated properly somewhere. (Speculation, I haven’t looked at the code for the HomeKit bridge module yet, so I don’t know how it’s structured. I’m just assuming here based on some work I did with Homebridge awhile back and my knowledge of HomeKit.)

Later tonight I’ll make a seperate install of 0.81.x and test the Demo Light platform.

[treetopsflyer]

@timothybrown thank you for describing this issue as I am having the same problems and seeing the exact same symptoms . I am new to Home Assistant (2 weeks) and just got the Yeelight yesterday so wasn't sure if the mistake was on my end or not until I found your post.

I will say I have perfect control of the Yeelight both from Home Assistant as well as Amazon Alexa (exposed via Haaska, not linking it to Yeelight's cloud) so I concur the trouble is only while attempting control through HomeKit or Siri.

.... anxiously standing by to see what the experts find.

[cdce8p]

I believe I finally know what you're describing. To set a color in HA form HomeKit, HA needs a change in saturation and hue to happen. Until the latest update, this wasn't a problem since both where updated simultaneously. However with https://github.com/ikalchev/HAP-python/pull/162 I excluded calls with the same values which is the reason setting a different color (with the same saturation) doesn't work anymore.

I'll open a PR in HAP-python to revert this change.

---

Edit The workaround until the new version is released would be to select a color through the color wheel with a slightly different hue and saturation value.

[cdce8p]

This will be fixed with 0.81.3.

[timothybrown]

I just wanted to update this and confirm that the problem appears to be fixed since the 0.81.4 update. Thanks!