Thank you very much everyone. I changed to Alexa smart home skill. Works pretty well for me.
Was it possible for you to delete the emulated hue entities from the alexa app without unplugging the 2. Gen Echo?
if you are using hassio. If you aren’t (home assistant in a venv, hassbian, etc), you can apply the method mentioned in the thread above.
Ok, what a pain. Ive been having the same problems that are described here. Tried everything but getting nothing but device ranges out of range etc etc.
So, i went and tested ha-bridge. I used that with Domoticz many moons ago. Took around 5 mins to set up and bingo! Everything works as it did. My set up is simple enough, only lights and plugs with on-off.
If anyone wants any more info just ask.
Cheers
3 Likes
I found that I had to delete the old emulated_hue devices individually in the Amazon Alexa app or web portal, rather than using the delete all button. FWIW. Maybe phase of the moon or something, but that’s what did the trick for me.
1 Like
Ok will try that.
They don’t reappear when you search for new devices?
No, after I deleted them individually, they did not return when I discovered new devices.
2 Likes
This worked for me too. Thanks for sharing.
Yes that also worked for me,
Thanks
There is a fix out there that resolved this for me, pull request pending.
1 Like
Oof, that change won’t make it through the devs. He didn’t follow any code procedures and the code can be optimized.
What? Sorry I don’t see any step in order to fix it 
You convert all your code from ha to this system?
OK so do I understand this correct that the fix (if you do not want to wait for official fix) is to edit hue_api.py?
Replace line:
if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain != light.DOMAIN:
to
if (entity_features & SUPPORT_BRIGHTNESS) or (entity.domain == climate.DOMAIN or entity.domain == fan.DOMAIN or entity.domain == media_player.DOMAIN or entity.domain == cover.DOMAIN):
The code does not pass the CI tests because of the format. And nested or’s like that can be optimized.
ex:
this mess:
entity.domain == climate.DOMAIN or entity.domain == fan.DOMAIN or entity.domain == media_player.DOMAIN or entity.domain == cover.DOMAIN
is the same as this, but optimized:
entity.domain in [climate.DOMAIN, fan.DOMAIN, media_player.DOMAIN, cover.DOMAIN]
So to test this I edited hue_api.py (using the dev port 22222), replaced line 574 to:
if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain in [climate.DOMAIN, fan.DOMAIN, media_player.DOMAIN, cover.DOMAIN]: ,
Restarted HA and reimported all devices from alexa.amazon.com. Looking at http://HAIP/api/pi/lights, my switches (z-wave) devices shows up as ex:
"10": {"modelid": "HASS321", "name": "Bedside", "state": {"on": false, "reachable": true}, "swversion": "123", "type": "On/off light", "uniqueid": "switch.bedroom_bedside_switch"}
So looks OK and it works to switch then on/off but sometimes Alexa says that “Bedside appears to malfunctioning” when I turn it off (even though alexa manage to turn the switch off) so something seems still be still not quite right.
Feels like turning on a light with haaska takes longer than with emulator hue.
I know that it was local before and now it’s cloud based.
To those who also switched to haaska:
Do you also feel a little bit more delay than before?
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
5 Likes
It’s happening with many other home automation programs besides HA. Delays in responses from Alexa and error responses from Alexa when lights are responding seems to be a common feature since the latest round of Alexa firmware updates.
I don’t think Amazon are finished with their firmware updates either so Hue seems like its going to be an ongoing battle until everything settles down.