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
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.
[size=14pt][b]IF YOU ARE JUST STARTING YOUR JOURNEY IN THIS 136+ PAGE THREAD PLEASE READ BELOW AND THEN START FROM THE END![/size]
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 Releases · armzilla/amazon-echo-ha-bridge · GitHub (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 Releases · armzilla/amazon-echo-ha-bridge · GitHub (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
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.
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.
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.
- YouTube 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)
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules