Emulated Hue: Device Unresponsive

[jbrody17-zz]

Home Assistant release with the issue: 0.98.2

Last working Home Assistant release (if known): 0.97.2

Operating environment (Hass.io/Docker/Windows/etc.): Hass.io

Component/platform: /components/emulated_hue/

Description of problem: My Alexa devices have been having trouble connecting/controlling the exposed lights and scripts in my Home Assistant instance. I suspect that this has to do with the latest Alexa update (iOS version 2.2.291375.0), since I that was right around when the issues started occurring.

I have checked to make sure that the integration is loaded and responded by navigating to http://HA-IP-Address:8300/api/pi/lights and seeing the correct list of devices.

I have deleted and re-added all of the devices 4 or 5 times and each time I see the same issue. After using the app to turn on the light, I see the message "Waiting for Royal Phillips Electronics", then the light turns on and then the app gives one of 2 messages: "Device malfunction" or "Device is unresponsive". After that I only ever see the error messages and the lights will not change.

Related to this could be the the new setting on the Alexa app. For all the device I've added (switch, script, etc.) there is a color setting with the ability to set a color. I'm not sure if the app is trying to set a color and being unsuccessful. When I go into the settings (on the Alexa app) for the entity I see the following information:

• Connected via: [Echo Device]
• Description: Royal Phillips Electronics smart device
• Type: Light
• Color Capabilities: Color
• Enabled: True

For reference, the devices being exposed are 2 scripts and 3 GE smart light switches with dimming capabilities. They were working perfectly up until about a week ago.

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

emulated_hue:
  host_ip: !secret hass_ip
  listen_port: 8300
  expose_by_default: false
  entities:
    light.ge_14295_in_wall_smart_toggle_dimmer_level:
      name: "Living Room"
      hidden: false
    light.ge_14295_in_wall_smart_toggle_dimmer_level_2:
      name: "Kitchen"
      hidden: false
    light.ge_14295_in_wall_smart_toggle_dimmer_level_3:
      name: "John's Room"
      hidden: false
    switch.monitors:
      name: "Monitors"
    script.tv_up:
      name: "Volume Up"
      hidden: false
    script.tv_down:
      name: "Volume Down"
      hidden: false

Traceback (if applicable):

Additional information:

[DNKROZ]

Hello.

I have the same issue, last version working was 0.97.2, after that one there were some apparently non-breaking changes since I didn't notice them on version details, but those broke my setup with this component and my lights.

My lights were reported like this before (just an example of the json object):

"9":{ "modelid":"HASS123", "name":"Lightname", "state":{ "bri":0, "hue":0, "on":false, "reachable":true, "sat":0 }, "swversion":"123", "type":"Dimmable light", "uniqueid":"entity_id" }

And now those lights are like this:

"9":{ "modelid":"HASS321", "name":"Lightname", "state":{ "on":false, "reachable":true }, "swversion":"123", "type":"On/off light", "uniqueid":"entity_id" }

Alexa reports the light as "non responsive", if I try to delete it and add it again it does not get added (not detected), once I revert back to the 0.97.2 version it gets detected again.

The issue is present in all 0.98.x versions.

Best regards.

[jbrody17-zz]

Interesting... I haven't seen a change in JSON object (since I never checked it before trying to debug it), but this is what mine looks like for one of the lights:

"9": {"modelid": "HASS123", "name": "Kitchen", "state": {"bri": 0, "hue": 0, "on": false, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "entity_id"}

[croghostrider]

@jbrody17 Which Alexa do you have? can you please try to reset your Alexa? How to reset after that try to re-discovering the light and check if you see the light with the model HASS321 in the app.

[jbrody17-zz]

@croghostrider I have 2 Alexa Echos (2nd gen) and 1 Alexa Dot (2nd gen). I will try to reset all of them.

[jamesw4]

Having same issue also. As above it now seems that emulated hue is reporting all lights with a hue and sat value which is making alexa think everything is a colored bulb...

[MJP-76]

Same on mine. I have a ifan02 with tasmota and can still control the fan but not the light by Alexa

Odd thing I have noticed in the iOS app is that to turn a light on of off you have to hit on and almost right away hit it off and to turn it off hit off them instantly on

[jamesw4]

Maybe I’m missing something here but the if statement to determine what attributes are returned doesn’t look right to me?

if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain != light.DOMAIN

That looks like it says, if the entity supports brightness OR is not in the light domain. If this is matched, state, brightness, hue , and sat are returned. Otherwise only state is returned. Shouldn’t it be if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain == light.DOMAIN?

[aneisch]

Commenting to affirm I'm facing the same.

[dpeet]

Also struggling with this!

[jonathansaenz]

+1

[jbrody17-zz]

@croghostrider Any update on when this will be fixed? Restarting all of the Alexa devices did not address the issue. Is #26541 going to be part of the 0.99.0 release?

Definitely want my Alexa devices to go back to being useful :)

[eracknaphobia]

Same issue here. I've rediscovered devices multiple times with same "Unable to respond" result. I even went back to 97.2 and rediscovered devices. Seems like something has changed on amazons side. Devices use to be listed as "Dimmable Light" now they are all listed as "Royal Phillips Electronics smart device"

[lk3de]

What port is your Emulated Hue Bridge running on? After reading some comments here, it could be Amazon's fault to communicate only on port 80. However, I didn't check by myself yet.

[eracknaphobia]

Thanks for the info. Mine is set to the default port 8300. I decided to try out nabu casa for now.

[jbrody17-zz]

@lk3de I had been using the default 8300 for a while and tried using 80 with the same results. No luck

[mattfreeman1701]

I've been doing some digging in to this. and have sniffed the network traffic between HA and Alexa to try and work out what is going on.

The issue appears to be with alexa 'checking' the bri: value after turning on the light. If the value is still '0' then it makes another request to set the brightness, which doesnt work properly and then reports "That value is out or range for device ____"

The exact symptoms I have is that emulated hue works perfectly for any device which has a (genuine) brightness component, but reports "value out of range" for anything which does not (i.e. switches).

For completeness here is (the important part of) my config.yaml:

switch:
  - platform: mqtt
    name: Aquarium
    command_topic: '/RF_Bridge/cmd'    
    payload_on: 'RC,on=41'
    payload_off: 'RC,off=41'  

emulated_hue:
  listen_port: 80
  expose_by_default: false

  entities:
    light.livingrm_side:
      name: "test"
      hidden: false
    switch.aquarium:
      name: "fish tank"
      hidden: false

Light.Livingrm_side is a dimmable TRADFRI bulb Switch.aquarium is an mqtt controlled RF smart plug

A Summary of the network traffic seen when attempting to control switch.aquarium: "Alexa turn on fish tank"

Alexa -> HA:    PUT request with JSON {"on":true}
HA -> Alexa:    200 'OK' with JSON {"success": {"/lights/switch.aquarium/state/on": true}}
Alexa -> HA:   GET
HA -> Alexa:    {"modelid": "HASS123", "name": "fish tank", "state": {"bri": 0, "hue": null, "on": true, "reachable": true, "sat": null}, "swversion": "123", "type": "Dimmable light", "uniqueid": "switch.aquarium"}
Alexa -> HA:   PUT {"bri":254}
HA -> Alexa:   200 'OK' with JSON {"success": {"/lights/switch.aquarium/state/on": false}}, {"success": {"/lights/switch.aquarium/state/bri": 254}}
Alexa -> HA:   GET
HA -> Alexa:   {"modelid": "HASS123", "name": "fish tank", "state": {"bri": 0, "hue": 0, "on": false, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "switch.aquarium"}

It appears Alexa requests to turn the switch on (PUT), which is successful. Then checks on it (GET) and is not happy that the brightness value is zero, so makes a second request (PUT) to set the brightness to 254. This 'works' but has the result of HA turning the light off again.

That's all I've got for now...I'll see if I can make any sense of the emulated hue code as to why this happens when I have time!

[mattfreeman1701]

Minor update: By changing the definition of the device from mqtt switch to mqtt light, the device now works correctly with Alexa. Importantly, it is now advertised in /api/pi/lights as: type: "On/off light" it was previously advertised as: type: "Dimmable light"

This clearly changes how Alexa attempts to interact with it.

[novitibo]

same problem at my setup: ha 0.99, alexa fw 644580520 alexa can't discover anything from HA hue emulated since alexa fw update :( http://my_ha_ip:8300/api/pi/lights show correctly exposed entities

[jbrody17-zz]

@mattfreeman1701 that sounds promising, but unfortunately all of my devices (none of them work) have a (genuine) brightness component. I will however note that after initially adding them, they adjust to requested brightness the very first time and then error after that.

[Kanga-Who]

Can confirm the same "value is out of range for device X response".

Updated to 0.99.0 yesterday, and have changed to port 80 from 8300, the problem still persists.

[ajuan2005]

Yes I have very similar situation here happened since about 1 week or 10 days ago. I'm in China at first I thought it was because my VPN was down and I thought it will be recover soon automatically. But recently noticed alexa is still saying my device is not responding even if my VPN is working. So it's nothing else but from Alexa itself i guess the firmware has been upgrade recently and it's no longer well supporting virtual Philips Hue bridge as it used to be?

[ltpitt]

Fresh install of hassbian yesterday, same setup as Kanga-Who, same error.

Items are switched on and then immediately off.

[Petro31]

The potential fix hasn't been merged yet. Check out the title and click the PR for details.

[novitibo]

do Paulus knows about this issue? do HA guys doing anything to get out of this Aexa-Hue-HA mistery?

[Petro31]

I dropped emulated hue because it constantly breaks because there's about 5 different developers making their own 'enhancements' over the past 5 months. Then the latest amazon port change sealed the deal.

All of this coupled with the fact that Phillips hue could drop support for hue bridge gen 1's at any moment. Meaning Amazon could follow suit.

[aneisch]

Best alternative at this point is to switch to the Alexa Smart Home Skill. Takes 30 minutes or less to set up with AWS Lambda. That or pay $5/month for Nabu Casa.

[novitibo]

It is possible that this is intention of this issue? Money rules the world, really?

[eracknaphobia]

@Petro31 Hue has already announced they're dropping the v1 hub next April.

[Petro31]

@eracknaphobia that's funny because I thought they would at some point.

@novitibo did you read the response? You seemed to gloss over the setup that doesn't cost money and focus on the $5 Nabu Casa portion.

Best alternative at this point is to switch to the Alexa Smart Home Skill.

[jbrody17-zz]

Thanks for the advice @aneisch and @Petro31 Just finished setting up the Alexa Smart Home Skill. Only took 15-20 minutes mainly because of all the account creation. Works like a charm!

[seamus65]

@mattfreeman1701 How did you change the description of your devices?

[Bart56]

I'm a bit confused over where the problem may be. I'm on Hassio 98.5 and I initially had a file in config/emulated_hue_ids.json which contain my two virtual lights. (These worked fine under Hassio 88.4 but my SD card died about the same time as all these Hue problems started and now this is more difficult to pin down.)

After rebuilding my Pi using version 2.12 - Hassio 98.5, I did not have an emulated_hue folder in my custom components folder (but I did have the emulated_hue_ids.json file in config.)

So while trying to figure out why my emulated hue virtual bulbs were returning the wrong brightness valuse at the low end (1%-4%), I noticed the Alexa app's "device is unresponsive" and "does not support requested value" error messages.

After much reading, I found that I needed to change to port 80, so I did, I also found that I did not have the custom_components/emulated_hue folder and files - yet still was getting some traffic between Alexa and emulated hue bulbs although it was incorrect and error filled.

I added the custom_component/emulated_hue/hue_api.py script and hard booted the pi. No change in behavior.

I could see my two devices on port 80 as:

{"1": {"modelid": "HASS123", "name": "security check", "state": {"bri": 0, "hue": 0, "on": false, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.security_check"}, "2": {"modelid": "HASS123", "name": "Alexa Virtual Light", "state": {"bri": 0, "hue": 0, "on": false, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.alexa_virtual"}}

which seems to look correct but when I try to access them using the Alexa app, I see:

{"1": {"modelid": "HASS123", "name": "security check", "state": {"bri": 0, "hue": 0, "on": false, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.security_check"}, "2": {"modelid": "HASS123", "name": "Alexa Virtual Light", "state": {"bri": 36, "hue": null, "on": true, "reachable": true, "sat": null}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.alexa_virtual"}}

which has some null returns. As part f my troubleshooting, I changed the modelId and swVersion in the hue_api.py to 133 and hard booted the pi again. But as you can see, it is returning 123 anyway. However, when I access the port 80 api/pi/lights to see the above json returns, I also find a correlating error in the log: `Error handling request Traceback (most recent call last):

File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start resp = await task File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle resp = await handler(request) File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl return await handler(request) File "/usr/src/homeassistant/homeassistant/components/http/real_ip.py", line 40, in real_ip_middleware return await handler(request) File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 125, in handle result = handler(request, **request.match_info) File "/usr/src/homeassistant/homeassistant/components/emulated_hue/hue_api.py", line 201, in get entity = hass.states.get(entity_id) File "/usr/src/homeassistant/homeassistant/core.py", line 886, in get return self._states.get(entity_id.lower()) AttributeError: 'NoneType' object has no attribute 'lower'

where line 201 is not part of get_entity. It's the second lin in:

async def put(self, request, username, entity_number): """Process a request to set the state of an individual light.""" if not is_local(request[KEY_REAL_IP]): return self.json_message('only local IPs allowed', HTTP_BAD_REQUEST)

It's almost telling me that my custom_components/emulated_hue/hue_api.py is not being used but some other one is and I don't know where it is.

So a few questions arise: 1) How was my HA Hassio implementation interfacing with emulated hue after only adding the emulated_hue: devices in configuration.yaml? 2) Why does it return null values after an interaction with Alexa? 3) Why doesn't the custom_components api folder have no effect?

While the Alexa app shows error states as I pointed out, I can interact with it almost successfully except for the wrong brightness vales at 1% - 4%. I hope this is clear enough to help the efforts of those working on the problem. Cheers, Bart (Edited for typos and clarity)

[duhow]

Should be fixed by #28317 .

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.