It will be great if we can implement this as a HA component.
2 Likes
I was starting on converting this to a Home Assistant component but will be unable to work on this as I’ve chosen to return my Amazon Echo for a refund.
It worked great for about two weeks then some software change on the Amazon side decided that if a device name sounds like a song name to treat it as if I’m asking for Prime Music to play something. So about 5 of my 23 devices exposed via the Hue API emulation via the Lighting API entries just stopped working over night even though the devices are being properly discovered.
At this point I’d recommend avoiding Echo in general as once the shiny wears off the really unpredictability responses to voice commands starts getting annoying fast.
Hopefully someone else in the community can use your starting point and convert to a component. Have a prepackaged Alexa component native to HA is like a media magnet. 
It looks like it has been, and will be part of 0.27 
https://github.com/home-assistant/home-assistant/pull/2942
1 Like
… which is out now. It’s super easy to configure, took me less than 5 minutes.
1 Like
Too bad it does not work for self-made AmazonEcho’s with something like AlexaPi, 
The upside is that AlexaPI is open source unlike an Echo. That means it could not only support Hue (and thus emulated Hue), but home-assistant more directly.
Well you would need to implement some sort of voice recognition software then. That would be a huge thing to do imho. And that really is the only thing I am using the Alexa service right now. I have a own device and a own skill.
Cheers
Noob question; why isnt this working with AlexaPi?
Isnt AlexaPi working the same as a “real” Echo when it comes to finding the hue hub?
I was so thrilled to test this with your version of AlexaPi @PhyberApex but now I read it wont work 
Problem is that the AlexaPi only sends data to the amazon Alexa service and reads the response from Alexa aloud. The discovery of the hue hub was not implemented in the AlexaPi code as it not part of the device API afaik. But you could implement it like technical pickle said.
Cheers
OK I understand the problem then, too bad. This seemed to be the fastest way to get Alexa up and running with HASS.
I will test your version and try to create some skills manually then.
@PhyberApex maybe slightly off-topic but Im having issues to install your version;
Pyaudio fails
Downloading/unpacking PyAudio==0.2.9
Running setup.py (path:/tmp/pip-build-epwWTU/PyAudio/setup.py) egg_info for package PyAudio
warning: no files found matching '*.c' under directory 'test'
Installing collected packages: PyAudio
Running setup.py install for PyAudio
building '_portaudio' extension
arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong $
src/_portaudiomodule.c: In function â_pyAudio_paDeviceInfo_get_hostApiâ:
src/_portaudiomodule.c:192:39: error: âPaDeviceInfoâ has no member named âhostApiâ
return PyLong_FromLong(self->devInfo->hostApi);
^
src/_portaudiomodule.c: In function â_pyAudio_paDeviceInfo_get_defaultLowInputLatencyâ:
src/_portaudiomodule.c:222:42: error: âPaDeviceInfoâ has no member named âdefaultLowInputLatencyâ
return PyFloat_FromDouble(self->devInfo->defaultLowInputLatency);
Also, is it possible to get your modifications into version 1.1 of AlexaPi?
EDIIT; did a fresh raspian install, same problem.
If I try to start it anyhow I get
`
pi@Alexa:~ $ sudo python /root/AlexaPi/main.py /root/Alexa.pmdl
Traceback (most recent call last):
File “/root/AlexaPi/main.py”, line 16, in
import snowboydecoder
ImportError: No module named snowboydecoder
Edit2. I will starta a new thread in Third party development to avoid hijacking this thread
`
Thanks
Is anyone still using this? I’m trying to get it running because I have reached a dead-end with the built-in “emulated hue” component (Echo will no longer find my devices). However, when I run:
python3 ./ha-local-echo.py
I get:
Fetching Home Assistant entities...
Traceback (most recent call last):
File "./ha-local-echo.py", line 183, in <module>
ha = HomeAssistant()
File "./ha-local-echo.py", line 36, in __init__
self.fetch_entities()
File "./ha-local-echo.py", line 52, in fetch_entities
if ('view' in state['attributes']) and (state['attributes']['view'] == True):
TypeError: string indices must be integers
I used Postman to hit the HA API call that the Python script is making, and it looks fine. I don’t know enough about how this script is working to figure out why it thinks on that line it’s working with a string rather than a JSON object. Any help would be appreciated.
EDIT: I got it running in a Python debugger and I can see the API response is “401 unauthorized”. I have checked all the config variables, including my HA API key, they are correct. When I reconstruct the API call in Postman, it works.
EDIT 2: Looks like a logic error in the ha-local-echo code. It calls self.fetch_entities, which depends on the headers being set properly, before the headers are ever set. Changed to set the headers before that method is called and it works. Will open a PR.
Ah sorry about not responding earlier.
I returned my Echo and am currently awaiting delivery of a Google Home so I’m not actively using this right now. I merged your PR as it’s an obvious bug. Thanks for figuring it out.
I’d be more curious about the troubles you’re having with HA’s built in “emulated hue” as I skimmed through the code for that when it was first merged. I didn’t see anything noticeably different about the HUE API side of things.
I got emulated hue working again. Not sure what I did, exactly. Originally I had it expose everything by default. At some point it stopped working entirely. In the midst of troubleshooting, and having gotten ha-local-echo working, I realized that maybe the problem was exposing everything by default (since with ha-local-echo you have to explicitly enable devices to work with Alexa). Sure enough, once I switched emulated_hue to NOT expose everything by default, Alexa was able to find my devices (that I explicitly enabled, of course).
I’m thinking there was something, somewhere, in my vast array of devices that was exposed, and is now not exposed, that was causing Alexa to break. There were never any errors, and the API output showed all the correct data, so I really don’t know why it wasn’t working.
If you have a lot of devices, you might have been running into the device cap (49, I believe). Unfortunately, emulated_hue fails silently if you have > 49 devices exposed. The echo/dot/whatever will just give up and report that it didn’t find anything. I got around this by just creating groups and scenes and exposed those, rather than having direct voice control over every individual bulb/switch/socket/etc.
1 Like
Ah, that must have been it! Because yes I have a lot of devices.
Holy cow, I wasted so many hours troubleshooting that. Would be nice if emulated_hue had some logging.
It may be that emulated_hue is doing it’s job just fine, and it’s the echo that is failing silently. I don’t mean to blame the component, I haven’t really dug through the code. I also lost a good number of hours to this. At the very least, the docs should have a warning. I just put one there, pending approval. Hopefully that will save someone else from this in the future.
1 Like
So does this work with Google Home as well?
Latest version of the HA Bridge (https://github.com/bwssytems/ha-bridge) works fine with Google Home