Bridge Amazon Echo to Vera, on github!

Howdy Folks,
Wanted to give you guys a sneak preview of my Amazon Echo to vera bridge. It basically emulates a Phillips Hue gateway using UPNP and a subset of the Hue Api. It runs on a R PI!

Arm

What is the command flow?
I’m thinking it would be something like this?

Echo uploads voice sample.
Amazon processes voice or sends to Nuance.
Amazon issues Hue command. (Transmitted command or file stored on Amazon servers?)
RPi reads command from Amazon. (API or todo list hack?)
RPi sends HTTP Get to Vera.

[b]IF YOU ARE JUST STARTING YOUR JOURNEY IN THIS 136+ PAGE THREAD PLEASE READ BELOW AND THEN START FROM THE END!

Alot has changed since this thread has started. Arm and his Armzilla version kicked this thread off and it was then pushed even further buy Crush157 and his crush version. It has added a great web UI with easy to use settings, Harmony Hub, Nest support, Dimming and much much more.

There has been many updates and the changes. The change log and versions can be found through out the thread with the latest ones towards the end. They can also be found here.

Altho Arm hasn’t been around in the last several months, thanks for kicking this off and also a big thanks to Crush for his updates and continued support.

[quote=“Z-Waver, post:2, topic:187039”]What is the command flow?
I’m thinking it would be something like this?

Echo uploads voice sample.
Amazon processes voice or sends to Nuance.
Amazon issues Hue command. (Transmitted command or file stored on Amazon servers?)
RPi reads command from Amazon. (API or todo list hack?)
RPi sends HTTP Get to Vera.[/quote]

Since the Echo already supports wemo and the Philips Hue I simply wrote something to a fake a Hue gateway.
The Echo does the following to turn on a Wemo device or a Hue bulb:

[ol][li]Echo sends out a UPNP discovery request over multicast[/li]
[li]The Wemo/Hue responds back with a URL for the service descriptor[/li]
[li]Echo reads the service descriptor and stores that on device[/li]
[li]When the Echo detects the keyword "Alexa, turn on my " it looks up the discovered device and changes it state[/li][/ol]

I initially reverse engineered a Wemo device (went to homedepot and bought ONE), however that could not emulate multiple devices like a Philips Hue Bridge could. Eventually i settled on emulating a Philips Hue and whenever i would receive a state change request i would turn around and make a luup request.

I am in the process of improving the vera device registration on my bridge app as right now it is a face only an api mother could love.

e.g. inserting a device with a vera id of 41

POST http://host:8080/api/devices
{
“name” : “bedroom light”,
“deviceType” : “switch”,
“onUrl” : “http://192.168.1.201:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1&DeviceNum=41”,
“offUrl” : “http://192.168.1.201:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0&DeviceNum=41
}

let me know if anyone is curious to try

video soon

cheers,
arm

What do we need to begin testing?
ECHO… Check
Vera… Check

Apple, peach or Rasberry Pie… checked the fridge nothing?

Any recommendations/requirements for this project? Is it non API pro friendly?

EDIT: Pi2 work or only the original Pi?

[quote=“integlikewhoa, post:5, topic:187039”]What do we need to begin testing?
ECHO… Check
Vera… Check

Apple, peach or Rasberry Pie… checked the fridge nothing?

Any recommendations/requirements for this project? Is it non API pro friendly?

EDIT: Pi2 work or only the original Pi?[/quote]

I have it running on a raspberry pi 2, however since it is java you can run it on anything!
You can fetch the current runnable jar from https://github.com/armzilla/amazon-echo-ha-bridge/releases (currently requires java8). The github page has some instructions to get you started.

[quote=“arm, post:6, topic:187039”][quote=“integlikewhoa, post:5, topic:187039”]What do we need to begin testing?
ECHO… Check
Vera… Check

Apple, peach or Rasberry Pie… checked the fridge nothing?

Any recommendations/requirements for this project? Is it non API pro friendly?

EDIT: Pi2 work or only the original Pi?[/quote]

I have it running on a raspberry pi 2, however since it is java you can run it on anything!
You can fetch the current runnable jar from https://github.com/armzilla/amazon-echo-ha-bridge/releases (currently requires java8). The github page has some instructions to get you started.[/quote]

How could I run this on a windows 8.1 Sever (using it for Blueiris and PLEX media servers right now always on) with Java 8 update 40 on it. IP 192.168.1.100

[quote=“arm, post:4, topic:187039”]Since the Echo already supports wemo and the Philips Hue I simply wrote something to a fake a Hue gateway.
The Echo does the following to turn on a Wemo device or a Hue bulb:

[ol][li]Echo sends out a UPNP discovery request over multicast[/li]
[li]The Wemo/Hue responds back with a URL for the service descriptor[/li]
[li]Echo reads the service descriptor and stores that on device[/li]
[li]When the Echo detects the keyword "Alexa, turn on my " it looks up the discovered device and changes it state[/li][/ol][/quote]
This more than implies that this is entirely local and that there isn’t a plethora of traffic and processing between Echo and Amazon. While that is certainly my desire, I very much doubt that this is the case with Echo, or ever will be.

Can you confirm that this is all local and internet free, or did you simply choose to ‘pay no attention to the man behind the curtain’?

[quote=“Z-Waver, post:8, topic:187039”][quote=“arm, post:4, topic:187039”]Since the Echo already supports wemo and the Philips Hue I simply wrote something to a fake a Hue gateway.
The Echo does the following to turn on a Wemo device or a Hue bulb:

[ol][li]Echo sends out a UPNP discovery request over multicast[/li]
[li]The Wemo/Hue responds back with a URL for the service descriptor[/li]
[li]Echo reads the service descriptor and stores that on device[/li]
[li]When the Echo detects the keyword "Alexa, turn on my " it looks up the discovered device and changes it state[/li][/ol][/quote]
This more than implies that this is entirely local and that there isn’t a plethora of traffic and processing between Echo and Amazon. While that is certainly my desire, I very much doubt that this is the case with Echo, or ever will be.

Can you confirm that this is all local and internet free, or did you simply choose to ‘pay no attention to the man behind the curtain’?[/quote]
Did some leg work for you. Captured traffic at the router to see the Echo’s communication to the outside world. Please poke any holes you see with my test methodology.

ok I have it working now and was even able to upload info for my kitchen light but Alexa says she is unable to discover any connected devices. Here is the command line I use to start this on a Windows box:

java -jar -Djava.net.preferIPv4Stack=true amazon-echo-bridge-0.1.0.jar --upnp.config.address=192.168.0.14

No host firewall turned on. I can get to the web page for it from other machines on my network just fine. When I browse to http://192.168.0.14:8080/api/devices it shows me:

[{"content":[{"id":"401e39c9-4bac-48f9-99e7-82145ba30c85","name":"kitchen light","deviceType":"switch","offUrl":"http://192.168.0.70:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0&DeviceNum=126","onUrl":"http://192.168.0.70:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1&DeviceNum=126"}],"facets":[],"totalElements":1,"totalPages":1,"size":1,"number":0,"last":true,"sort":null,"numberOfElements":1,"first":true}]

This is on a wired machine. Tried again with the Jar on a wireless laptop; same issue. Alexa can’t discover it.

[quote=“Ramias, post:10, topic:187039”]ok I have it working now and was even able to upload info for my kitchen light but Alexa says she is unable to discover any connected devices. Here is the command line I use to start this on a Windows box:

java -jar -Djava.net.preferIPv4Stack=true amazon-echo-bridge-0.1.0.jar --upnp.config.address=192.168.0.14

No host firewall turned on. I can get to the web page for it from other machines on my network just fine. When I browse to http://192.168.0.14:8080/api/devices it shows me:

[{"content":[{"id":"401e39c9-4bac-48f9-99e7-82145ba30c85","name":"kitchen light","deviceType":"switch","offUrl":"http://192.168.0.70:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0&DeviceNum=126","onUrl":"http://192.168.0.70:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1&DeviceNum=126"}],"facets":[],"totalElements":1,"totalPages":1,"size":1,"number":0,"last":true,"sort":null,"numberOfElements":1,"first":true}]

This is on a wired machine. Tried again with the Jar on a wireless laptop; same issue. Alexa can’t discover it.[/quote]

can you post (or PM) the logs generated when you ran the device discovery?
I am looking for something like

upnp device settings requested:
hue lights list requested:

What logs? Just the output to the console when I execute Java?

I dumped that to a text file but did not see the strings you posted.

What ports other than 8080 do/does this need on my host machine?

I had to stop the SSDP Discovery Service on Windows to free up 1900 UDP (that Java then took when I relaunched it) but I suspect there are more.

[quote=“Ramias, post:12, topic:187039”]What logs? Just the output to the console when I execute Java?

I dumped that to a text file but did not see the strings you posted.

What ports other than 8080 do/does this need on my host machine?

I had to stop the SSDP Discovery Service on Windows to free up 1900 UDP (that Java then took when I relaunched it) but I suspect there are more.[/quote]

There is a unicast/udp port that the app binds to to respond back to the SSDP discovery, default is 50000. You can override using the parameter --upnp.response.port=PORT however i dont think this is the case because the app should have bailed if there were any port conflicts.

Can we try adding the following parameters to see if we are getting ssdp discovery packets?
–logging.level.com.armzilla.ha.upnp=DEBUG --logging.file=ha.log

AWESOME

Ok, I decided to try this on my Mac. Had to first install Java then the actual JDK to launch this from the Mac terminal command line.

Added my one device like I always do.

IT WORKS. I can turn on and off the kitchen lights with voice from my Echo.

I also see the upnp device settings requested and hue lights list requested in the console logs.

So… there’s an issue with this running on Windows. I suspect it is a port issue with a standard Windows service taking up the port.

But that also means I may have an issue running this on the same Windows Server I run Plex on if I have DLNA enabled with Plex.

[quote=“Ramias, post:14, topic:187039”]AWESOME

Ok, I decided to try this on my Mac. Had to first install Java then the actual JDK to launch this from the Mac terminal command line.

Added my one device like I always do.

IT WORKS. I can turn on and off the kitchen lights with voice from my Echo.

I also see the upnp device settings requested and hue lights list requested in the console logs.

So… there’s an issue with this running on Windows. I suspect it is a port issue with a standard Windows service taking up the port.

But that also means I may have an issue running this on the same Windows Server I run Plex on if I have DLNA enabled with Plex.[/quote]

awesome!, let me spin up a vm to test the windows scenario.

Arm

[quote=“arm, post:13, topic:187039”][quote=“Ramias, post:12, topic:187039”]What logs? Just the output to the console when I execute Java?

I dumped that to a text file but did not see the strings you posted.

What ports other than 8080 do/does this need on my host machine?

I had to stop the SSDP Discovery Service on Windows to free up 1900 UDP (that Java then took when I relaunched it) but I suspect there are more.[/quote]

There is a unicast/udp port that the app binds to to respond back to the SSDP discovery, default is 50000. You can override using the parameter --upnp.response.port=PORT however i dont think this is the case because the app should have bailed if there were any port conflicts.

Can we try adding the following parameters to see if we are getting ssdp discovery packets?
–logging.level.com.armzilla.ha.upnp=DEBUG --logging.file=ha.log[/quote]

Looks like we were posting at the same time.

Here are my two logs from my Windows machine. I was not able to PM attachments.

Not sure what changed. It this works on windows now. Ports 1900 and 50000 UDP and 8080 TCP.

Just turned the kitchen lights on and off.

Now… How to build the syntax to populate my other lights and devices (and I assume scenes) to get voice control there :slight_smile:

This is great work.

I figured I’d post something for those who want to test this out. This is just a collection of the steps I did to get this to work in my Windows environment. Many thanks to Arm for sharing this with us.

  1. Download the JAR file. https://github.com/armzilla/amazon-echo-ha-bridge/releases
  2. Of course, make sure your machine is ready for this. In my case, Windows and make sure it has the correct Java version installed.
  3. (Optional) You can do some advanced troubleshooting on Windows. From a CMD prompt, run netstat -ano | find “8080”, netstat -ano | find “1900”, netstat -ano | find “50000”. You want the response to come up blank. If it comes up with something else, the number in the last column is the process ID of whatever has that port. You can use Tasklist to try to find it and shut that service down. SSDP Discovery could be one of them.
  4. From a CMD Prompt, start the program with this (obviously with your own server’s IP address):
java -jar -Djava.net.preferIPv4Stack=true amazon-echo-bridge-0.1.0.jar --logging.level.com.armzilla.ha.upnp=DEBUG --logging.file=ha.log --upnp.config.address=192.168.0.X >log.txt

the --logging and the >log.txt are optional and just pump out some log files.

  1. Make sure you don’t have any firewall issues blocking these ports. Troubleshooting that is outside of this scope.
  2. Make sure things are running by trying to browse to http://192.168.0.X:8080/api/devices. You should just get some text as a response (but not an error message).
  3. Then, you need to upload your instructions for your Vera devices. I found this tool here to help with that: http://www.swensensoftware.com/im-only-resting
    In that tool, the URL field is just http://192.168.0.X:8080/api/devices and Method is post.
    I found I had to populate the header box so I just put in this:

X-Application-Context: application:8080 Transfer-Encoding: chunked Date: Sat, 25 Apr 2015 21:14:21 GMT Server: Apache-Coyote/1.1 Content-Type: application/json; charset=UTF-8

Then in the Body, I put this (you will need your Vera IP, a name you use for the device on the Echo, and the device number (found on the Advanced tab of the device in Vera):

{ "name" : "kitchen light", "deviceType" : "switch", "onUrl" : "http://Vera_IP:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1&DeviceNum=126", "offUrl" : "http://192.168.0.70:3480/data_request?id=action&output_format=json&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0&DeviceNum=126" }
8. Once you’ve done this and it was submitted correctly, then “Alexa, discover my devices” and then you can say “Alexa turn off kitchen light”.
9. You can use the Vera app on your phone to trigger discovery, or forget previously discovered devices if you have a collision.

[quote=“arm, post:9, topic:187039”][quote=“Z-Waver, post:8, topic:187039”][quote=“arm, post:4, topic:187039”]Since the Echo already supports wemo and the Philips Hue I simply wrote something to a fake a Hue gateway.
The Echo does the following to turn on a Wemo device or a Hue bulb:

[ol][li]Echo sends out a UPNP discovery request over multicast[/li]
[li]The Wemo/Hue responds back with a URL for the service descriptor[/li]
[li]Echo reads the service descriptor and stores that on device[/li]
[li]When the Echo detects the keyword "Alexa, turn on my " it looks up the discovered device and changes it state[/li][/ol][/quote]
This more than implies that this is entirely local and that there isn’t a plethora of traffic and processing between Echo and Amazon. While that is certainly my desire, I very much doubt that this is the case with Echo, or ever will be.

Can you confirm that this is all local and internet free, or did you simply choose to ‘pay no attention to the man behind the curtain’?[/quote]
Did some leg work for you. Captured traffic at the router to see the Echo’s communication to the outside world. Please poke any holes you see with my test methodology.

https://youtu.be/CFz15cIvoB0[/quote]Thanks for this. It definitely appears to be the case that voice translation and command issuance is completely local without cloudy intervention.

I’m very surprised, impressed, and pleased.

Hey guys, trying to get this running on my Synology NAS…but this is a bit over my head.

Here is the error I got:

SERVE-E> java -jar -Djava.net.preferIPv4Stack=true amazon-echo-bridge-0.1.0.jar --logging.level.com.a
rmzilla.ha.upnp=DEBUG --logging.file=ha.log --upnp.config.address=192.168.0.X >log.txt
Exception in thread “main” java.lang.UnsupportedClassVersionError: com/armzilla/ha/SpringbootEntry : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at org.springframework.boot.loader.LaunchedURLClassLoader.doLoadClass(LaunchedURLClassLoader.java:163)
at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:136)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:46)
at java.lang.Thread.run(Thread.java:745)