I set up emulated hue in Home Assistant and Alexa successfully discovers exposed devices and can turn on devices but Alexa speaks too much when doing this 
She says “Light isn’t responding. Please check its network and power supply.” although she just turned the very same light on split second ago.
Any solutions?
Wild guess: Some implementation problem on HA side - probably does not respond with something in format expected by Alexa.
P.S. Does not speak when turning lights off.
I am getting the exact same thing. Hopefully someone can help us.
i’m still have this bug any news? someone who had solved?
Same problem here, all switches.
Same issue here since upgrading with an input Boolean exposed to alexa that has worked perfectly for almost 2 years
Same problem here. Lights switch on and off OK, but Alexa complains the the ‘device is not responding’ when turning off, even though it does switch it off.
Had been working fine for a couple of years.
Deleted emulated_hue_ids.json and let it recreate, same problem.
mine also works fine turning on but when turning off says no responding but turns it off anyway
This should be fixed in an upcoming version
change the code in hue_api.py:
def entity_to_json(config, entity, state):
"""Convert an entity to its Hue bridge JSON representation."""
entity_features = entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain == script.DOMAIN:
return {
'state':
{
HUE_API_STATE_ON: state[STATE_ON],
HUE_API_STATE_BRI: state[STATE_BRIGHTNESS],
HUE_API_STATE_HUE: state[STATE_HUE],
HUE_API_STATE_SAT: state[STATE_SATURATION],
'reachable': True
},
'type': 'Dimmable light',
'name': config.get_entity_name(entity),
'modelid': 'HASS123',
'uniqueid': entity.entity_id,
'swversion': '123'
}
elif entity.domain == light.DOMAIN:
return {
"state": {HUE_API_STATE_ON: state[STATE_ON], "reachable": True},
"type": "On/off light",
"name": config.get_entity_name(entity),
"modelid": "HASS321",
"uniqueid": entity.entity_id,
"swversion": "123",
}
else:
return {
"state": {HUE_API_STATE_ON: state[STATE_ON], "reachable": True},
"type": "On/Off plug-in unit",
"name": config.get_entity_name(entity),
"modelid": "HASS4321",
"uniqueid": entity.entity_id,
"swversion": "123",
}
The changes in 0.98 broke a template light for me (it showed up as “HASS321” in api/pi/lights and Alexa wouldn’t see it ). Adding “set_level:” to my template light (Even with no action) made it show up as “HASS123” and it worked with Alexa… does this correct the changes just with 0.98? It looks like you added an additional model id?
Before, all devices were dimmable color lights. Now it is checked if the device is dimmable:
if (entity_features & SUPPORT_BRIGHTNESS)
I added a new model for plugs/switches.
I also changed
if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain != light.DOMAIN:
to
if (entity_features & SUPPORT_BRIGHTNESS) or entity.domain == script.DOMAIN:
Hi, I’ve the same problem in version 0.99. Alexa finds the lights specs offered by emulated_hue, but does not turn them on or off and says that “the device isn’t responding”. /api/pi/lights returns the list of devices, some are “HASS321” and others are “HASS123”. None of the work.
When alexa calls switching, HA receives a call to
GET /description.xml HTTP/1.1
Content-Type: application/json
User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEOBC Build/LVY48F)
Host: 10.0.0.4:8300
Connection: Keep-Alive
Accept-Encoding: gzip
and responds with
010.000.000.004.08300-010.000.000.020.44628: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 732
Date: Fri, 20 Sep 2019 17:31:58 GMT
Server: Python/3.7 aiohttp/3.5.4
010.000.000.004.08300-010.000.000.020.44628: <?xml version="1.0" encoding="UTF-8" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://10.0.0.4:8300/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>HASS Bridge (10.0.0.4)</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2015</modelName>
<modelNumber>BSB002</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>1234</serialNumber>
<UDN>uuid:2f402f80-da50-11e1-9b23-001788255acc</UDN>
</device>
</root>
Nothing works! Everything worked fine before upgrading to 0.99 (I use to be on 0.79 or so)
Any help?
I opened issue #26425 in the HA project for this. It has apparently been fixed for 15 days, but just has been part of a recent release
Thanks for the pointer to this. I’m having the same problem here too. It looks like the fix in question made it into the 0.98 release. However, I have some RF sockets which are configured as switches rather than lights, and the problem did not go away with the new release.
I was able to get it to show up as a non dimable light by using a Light Switch entry for my switch:
light:
- platform: switch
name: Light 1
entity_id: switch.rf_sw1
After that, I could see in http://<server-ip>/api/pi/lights that it was showing up as an on/off light.
Like others, I was having the same problem. I deleted all my Alexa devices, deleted the emulated_hue_ids.json file and tried to have the Alexa app rediscover devices. It finds nothing. Sniffing UDP packets, I can see that the Echos are making the UPNP requests, but not finding anything. I haven’t done a discover in awhile, so I’m not sure when something changed. I have 2 Echo Dots (2nd gen), 1 Echo (1st gen) and a 3rd gen dot.
Anyone have clues on how I can troubleshoot this? I’m thinking that the UPNP in the emulated_hue isn’t responding (it does appear to be listening on port 1900), but can’t prove it.
http://ha/api/pi/lights returns the devices.
http://ha/description.xml returns the description.
So I know that part of the emulated_hue is working.
I’m running hass.io on HassOS on a VM if that makes a difference.
Thanks!
You say that http://ha/description.xml is working, so that would say to me that your instance is responding to requests on port 80 properly - that is the most likely thing to go wrong. The other thing I would check is whether your host_ip / advertise_ip are set properly. host_ip tells it which interface to listen on, and advertise_ip is the IP address that the UPNP responder sends in its responses.
Also, check you are getting debug messages for at least these components:
logger:
logs:
homeassistant.components.http.view: debug
homeassistant.components.emulated_hue: debug
HI Chris,
Thanks for the reply! I should have replied to my own post with my “solution”. Since my post, I moved my Home Assistant install to a mini PC (Core i3 fanless XCY mini PC) running HassOS (hass.io on top of it). I then discovered devices from the Alexa app and everything started working again. I suspect that the VM (VMWare Fusion on Mac OS 10.15) had trouble listening on the UDP multicast port. Since the mini PC doesn’t have an extra networking layer between Home Assistant and the hardware (yes, I know it has hass.io managing the docker containers), I think that is the root cause.
In any case, thanks for taking the time to respond!
I scrapped the hue component fed up with the intermittent issues. Now on interface with IFTTT that seems to be working well, just a little more set up and with the commands from IFTTT be sure to check the speech marks are straight and not slanted, it stops it working! Once one applet is in you can copy and its easy to add entities.
There’s a big update gone into the upcoming version 103, due to be released next week. It should fix most of the problems that people have been reporting.