To break this all down into something actionable, there’s two issues with two different causes:
- After telling Alexa to turn on/off a device or set its brightness/speed/etc, Alexa reports Device Malfunction until the device itself has completed updating. More on this below, screenshots and debug lines for testing if you’re interested.
- When using other apps such as the LIFX app, some devices can have their brightness set to 0 or 255, which causes Alexa to report Device doesn’t support requested value since the values are outside of the Hue API range of 1 - 254.
I added some debugging lines in hue_api.py (line numbers below reflect where they were inserted, in relation to the current version in Github) to see the requests made from Alexa to emulated Hue (both GET and PUT, as well as the immediate response sent back after a PUT) and tailed my log file to watch them:
223: _LOGGER.warn('[HueOneLightStateView] <<< GET %s', json_response)
224:
...
268: _LOGGER.warn('[HueOneLightChangeView] PUT >>> %s', request_json)
269:
...
422: _LOGGER.warn('- RES - %s', json_response)
423:
I colored the output a bit to make it easier to see GET, PUT, and the immediate response to the PUT, using sed to replace things with color tags - here’s what I added to my .bash_profile:
CYEL=$(printf "\e[93m")
CGRN=$(printf "\e[92m")
CBLU=$(printf "\e[96m")
CRES=$(printf "\e[0m")
alias tlog='tail -f /config/home-assistant.log | sed -r "s/(<<< GET)/${CYEL}\1${CRES}/g; s/(PUT >>>)/${CGRN}\1${CRES}/g; s/(- RES -)/${CBLU}\1${CRES}/g"'
After that, I just use the tlog command to watch and color my log. What you see in the logs is as follows:
What’s happening is:
- Alexa tells the light to turn on (
PUT >>>{'on': True}), and gets an immediate success reponse (- RES - [{'success': {'/lights/fan.bedroom_fan/state/on':True}}]). - Alexa checks the light’s status, but sees that the light isn’t turned on (
<<< GET {'state': {'on': False, ...). - Alexa displays Device malfunction if you’re using the app, or says That device appears to be malfunctioning if you’re using voice control.
- After the device updates and Alexa checks its status again (perhaps a few times, actually), she sees the device is finally turned on (
{'state': {'on': True, ...), the error goes away if you’re using the app, and everything looks good.
In the end, Alexa is reporting that there’s an error because as far as she can see the light isn’t responding successfully to her telling it to turn on. I don’t have a Hue bridge to test, but for some reason I have a feeling that they respond faster than our emulated Hue can respond. I don’t know a way to make this work and satisfy Alexa’s first immediate check, outside of emulated Hue “faking” the responses returned while also waiting for the entity to update before updating its own cached state. In the case of an eventual error, Alexa will first see that the device’s status was successfully changed, followed by our emulated Hue seeing a failure of some sort and updating its own internal cache/status, and Alexa later checking back in with emulated Hue and getting the updated (failed, but she doesn’t have to know that) state of the entity. At this point, Alexa will just display the device as turned off, no issue there.
Regarding the PRs submitted in an attempt to correct issues, neither of the two that I’ve seen (512759d and 3a34983) resolve the underlying issues discussed above, and both have additional shortcomings:
-
512759d does not strictly follow the Hue API, specifically regarding responses, although Home Assistant isn’t necessarily following the API either for the same reason.
- Brightness can only range from 1 to 254, never be 0 or 255. Both Home Assistant’s emulated Hue and this PR have code that both allow, and in fact also specifically set, brightness to either 0 or 255 in several places.
- This is possibly more of an issue with the Hue API itself, based on the principle that a byte ranges from 0 to 255 and arguably a brightness of 0 should constitute an OFF state, similar to how a value of 255 should constitute a fully-on state.
-
Both PRs currently incorporate code or style that does not follow Home Assistant’s conventions:
-
512759d typoed “HASS” as “HAS”, though this requires minimal effort to correct
-
512759d incorrectly defines Extended color light requirements. Hue API’s definition states:
On/off light (ZigBee Device ID: 0x0000), supports groups, scenes and on/off control
Dimmable light (ZigBee Device ID: 0x0100), which supports groups, scenes, on/off and dimming.
Color temperature light (ZigBee Device ID: 0x0220), which supports groups, scenes, on/off, dimming, and setting of a color temperature.
Color light (ZigBee Device ID: 0x0200), which supports groups, scenes, on/off, dimming and color control (hue/saturation, enhanced hue, color loop and XY)
Extended Color light (ZigBee Device ID: 0x0210), same as Color light, but which supports additional setting of color temperatureThe definition lacks the necessary
SUPPORT_COLORcheck and should read:613: if (entity_features & SUPPORT_BRIGHTNESS) and ( 614: entity_features & SUPPORT_COLOR) and ( 615: entity_features & SUPPORT_COLOR_TEMP 616: ): 617: retval["type"] = "Extended color light"
I think in general, the emulated Hue component needs a pretty hefty rework with more attention paid to following the Hue API documentation more strictly. That’s only half of the problem though, as there’s so many devices that “don’t play nicely” (as in the case of my LIFX bulbs, for example), but that’s not their fault, as we’re really adding devices to the Hue hub that shouldn’t be there. I believe the best solution to address that, at least for now, would be to more strongly adhere to the Hue API, as this seems to be the cause of at least part of the issue people are experiencing. However, doing so is not without consequence as other apps like the LIFX app (and probably others) don’t see lights as 100% when set to the Hue API max of 254, depending on how they perform their round/ceil/floor operations on the brightness to percentage conversion. This does resolve Alexa’s Device doesn’t support requested value error, which in my opinion is more problematic as Alexa will fail to update devices in this state. One such check I’ve tested (working with the aforementioned limitation) is this:
...
69: # Define min/max values for device properties
70: HUE_API_STATE_BRI_MIN = 1.0
71: HUE_API_STATE_BRI_MAX = 254.0
72: HUE_API_STATE_HUE_MIN = 0.0
73: HUE_API_STATE_HUE_MAX = 65535.0
74: HUE_API_STATE_SAT_MIN = 0.0
75: HUE_API_STATE_SAT_MAX = 254.0
...
572: # Clamp brightness, hue and saturation to valid values
573: if data[STATE_BRIGHTNESS] is not None:
574: data[STATE_BRIGHTNESS] = max(HUE_API_STATE_BRI_MIN, min(HUE_API_STATE_BRI_MAX, data[STATE_BRIGHTNESS]))
575: if data[STATE_HUE] is not None:
576: data[STATE_HUE] = max(HUE_API_STATE_HUE_MIN, min(HUE_API_STATE_HUE_MAX, data[STATE_HUE]))
577: if data[STATE_SATURATION] is not None:
578: data[STATE_SATURATION] = max(HUE_API_STATE_SAT_MIN, min(HUE_API_STATE_SAT_MAX, data[STATE_SATURATION]))
579:
This, despite needing line length breaks somewhere, has the effect of returning a clamped value between proper bounds when Alexa queries emulated Hue for a device’s brightness/hue/saturation. If LIFX or another app updates one of the entity’s supported values outside of that range, the value will not be modified; only the response sent to Alexa will be clamped. On the other side of things, if you use Alexa to change the device’s brightness/hue/saturation, the other app will see the clamped value. For example, setting a bulb to 100% with Alexa results in the LIFX app seeing the same bulb as 99% brightness as floor(254/255) = 0.996078... which rounds down to 99% in the LIFX app after calling the floor function and multiplying by 100 to get percentage.
I’d be willing to help out in any way I can, time permitted, and would love to see what others think and perhaps coordinate our efforts in one place. Currently we’ve got this topic on the community, issue #25047 on Github, at least two PRs (512759d and 3a34983) - neither of which fully resolve this problem, and likely other discussions about this. I’m fairly certain all of our collective brainpowers combined can come up with at least a mostly-functioning solution.
I’m currently working to re-write several bits to account for all of the problems the emulated Hue has to deal with, and I’ll be putting out a new pull request for others to grab my code and test it. I hate the state the emulated Hue is in, but the best I can do is fix the little things I’ve found and hopefully that’ll be good enough to work for everyone else.
- NobleKangaroo
