Playing around with Amazon Echo (technical interface discussion)

No support on this, but here’s the node code along with a slimmed down version of the smartapp I use. Untested since I hacked out a bunch of stuff unrelated to this and you’ll need to use curl or some other mojo to generated the bearer channel/oauth endpoint for the smart app, then put those values into the node code.

If it doesn’t make sense, stick with the Java version :smile:

2 Likes

Looking at the output, you can send a delete command via your http tool to delete devices

  1. In your browser, go to http://ip_address:8080/api/devices where ip is the ip of the pc running the java file
    2.Your devices will be listed. For each one you want to delete, send a http delete to http://ip_address:8080/api/devices/device_id
1 Like

Super appreciate this, John! The Java version is fun, but I’m more comfortable maintaining or enhancing Node, I think. I can set my Java sever to respawn or reboot after that out of memory problem until I explore your code.

I guess this is how someone learns a few languages at once!

My Echo came in on Friday and I was able to spend some time kicking the tires today. Thanks to your simple guide I was able to get everything integrated into ST fairly quickly. Thanks for making such a great writeup!

What I’ve also done with the amazon-echo-ha-bridge is to allow direct voice control of my Harmony Hub. ST integration with Harmony is broken for me right now, but I have setup amazon-echo-ha-bridge to issue requests to my EventGhost webserver which calls HarmonyHubControl to issue commands directly to the Harmony Hub (sidestepping ST altogether). Now I can say “Alexa turn on Netflix” or “Alexa turn on Plex” and it will send the commands to Harmony to launch everything. There’s no control once you’ve launched the activity unless you want to get goofy with it (make commands for “turn on the volume” and “turn off the volume” which will send vol+/vol- that you’d have to repeat a bunch of times), but for simple activity launch it’s working great.

3 Likes

The author of the amazon-echo-ha-bridge says here that a version supporting dimming is coming. We’d still need an endpoint capable of handling dimming for the ST end to work but the bridge end should be handled soon.

1 Like

Dimming utterance support will offer a great solution to this…

We’ll be able to map “Dim volume to 60%” to the specified audio level, as long as the API for your endpoints support it.

So we will have the binary commands on/off, and the range commands brighten/dim to %. Mapped however creatively we want.

@schettj, I know you said ‘no support’, but maybe someone else can help. ( @tgauchat ?) I’ve got nearly no hair left; this integrating ST and the Echo will be the death of me. I’ve been trying to use the java hue bridge emulator above, and the Echo discovers devices I’ve defined in it but can’t seem to control them; using your node.js code here, I can get the server running and passing commands along to ST via the smartapp, but I can’t get the Echo to discover the switches I’ve given access to in the smartapp.

Anyone provide assistance? (I used to think I was relatively smart before I started this integration…)

Thanks!

[quote=“terryhonn, post:149, topic:14887”]
I can get the server running and passing commands along to ST via the smartapp, but I can’t get the Echo to discover the switches I’ve given access to in the smartapp
[/quote]Is the Echo on the same subnet? Is there any odd firewall stuff happening. - UPNP ports need to be open, as does port 8281 (the port the node app “service” is running on.) This would be on whatever box is running node.

The node app should display some debugging as it sees the upnp requests coming in, and (unless I commented them out :slight_smile: )when handling echo requests against a “light”.

Edit: you can also try running some upnp discovery tools on another computer on your network to see if you can discover the “hue bridge” service - that would at least tell you the networking port/firewall stuff is working.

@schettj, John thank you very much for your response! I’m still where I was, but I figure with you looking in, surely we’ll figure out what I’m doing wrong.
I’ve been trying this on both a Pi and a Windows box, but we’ll focus on the PC for now. Both it and the Echo are on the same subnet. PC is 192.168.1.101, Echo is 192.168.1.103. Nothing special has been done regarding any ports on the PC, and I haven’t made any changes to those ports specifically on my uverse gateway.
Below is output from the node app from the startup, thru my telling the Echo to find my connected devices (there is one switch configured in the smartapp right now, for testing), and then I used a upnp scanner app on my Android phone (192.168.1.110) to scan the network. That app found my chromecasts and sonos1, but no ‘hue bridge’. Also, Alexa reported that she couldn’t find any connected home devices when discovery was complete. Here’s that output:

C:\node\echosmart>node echosmart.js UPnP discovery started lights fetched M-SEARCH Message received { address: '192.168.1.103', family: 'IPv4', port: 50000, size: 107 } M-SEARCH Message received { address: '192.168.1.103', family: 'IPv4', port: 50000, size: 107 } M-SEARCH Message received { address: '192.168.1.103', family: 'IPv4', port: 50000, size: 122 } M-SEARCH Message received { address: '192.168.1.103', family: 'IPv4', port: 50000, size: 122 } /description.xml /description.xml /description.xml /description.xml /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0 /api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0 M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 60901, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 57861, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 57861, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 1910, size: 126 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 57861, size: 94 } M-SEARCH Message received { address: '192.168.1.110', family: 'IPv4', port: 57861, size: 94 }

Let me know if that tells you anything new.
Thanks again!

Private Message me and we’ll find some time to Skype or something to try debugging, if you don’t get working before then. Let me know your timezone and usual free times. I will try the node version soon, but Java’s been ok.

That tells me the Echo found the node app, and asked it for lights, and probably didn’t get any.

So, did you install the webApp, and then go through whatever to generate the bearer # and access uri, and then edit the node app to use your bearer # and access uri? Because it seems like the node app isn’t able to access your SmartThings.

Thanks again for continuing to try to help me, @schettj …sincerely appreciated.

I’ve uninstalled the original instance of your webapi smartapp, installed again and got fresh client id and secret and generated a new access token. I selected only one switch device during the authorization. I put the new token and the new app id in your node code. I started the server and asked Alexa to discover devices, and she responds that she can’t find any connected home devices. I added a debug statement to your code so that I could ensure that node is able to talk to my Smartthings smartapp. You’ll see that in the log below:

C:\node\echosmart>node echosmart.js
UPnP discovery started
{“devices”:[{“id”:“24243966-1773-487d-b763-0412ff0fe564”,“name”:“Z-Wave Switch”,“label”:“Bar Light”,“capabilities”:[“switch”,“poll
ing”,“refresh”,“indicator”,“sensor”,“actuator”],“state”:{“time”:“2015-05-25T17:41:18Z”,“switch”:“off”,“indicatorStatus”:""}}]}
lights fetched
M-SEARCH Message received
{ address: ‘192.168.1.103’,
family: ‘IPv4’,
port: 50000,
size: 107 }
M-SEARCH Message received
{ address: ‘192.168.1.103’,
family: ‘IPv4’,
port: 50000,
size: 107 }
M-SEARCH Message received
{ address: ‘192.168.1.103’,
family: ‘IPv4’,
port: 50000,
size: 122 }
M-SEARCH Message received
{ address: ‘192.168.1.103’,
family: ‘IPv4’,
port: 50000,
size: 122 }
/description.xml
/description.xml
/description.xml
/description.xml
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/lights
{“devices”:[{“id”:“24243966-1773-487d-b763-0412ff0fe564”,“name”:“Z-Wave Switch”,“label”:“Bar Light”,“capabilities”:[“switch”,“poll
ing”,“refresh”,“indicator”,“sensor”,“actuator”],“state”:{“time”:“2015-05-25T17:41:32Z”,“switch”:“off”,“indicatorStatus”:""}}]}
{“devices”:[{“id”:“24243966-1773-487d-b763-0412ff0fe564”,“name”:“Z-Wave Switch”,“label”:“Bar Light”,“capabilities”:[“switch”,“poll
ing”,“refresh”,“indicator”,“sensor”,“actuator”],“state”:{“time”:“2015-05-25T17:41:32Z”,“switch”:“off”,“indicatorStatus”:""}}]}
{“devices”:[{“id”:“24243966-1773-487d-b763-0412ff0fe564”,“name”:“Z-Wave Switch”,“label”:“Bar Light”,“capabilities”:[“switch”,“poll
ing”,“refresh”,“indicator”,“sensor”,“actuator”],“state”:{“time”:“2015-05-25T17:41:32Z”,“switch”:“off”,“indicatorStatus”:""}}]}
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2
{“devices”:[{“id”:“24243966-1773-487d-b763-0412ff0fe564”,“name”:“Z-Wave Switch”,“label”:“Bar Light”,“capabilities”:[“switch”,“poll
ing”,“refresh”,“indicator”,“sensor”,“actuator”],“state”:{“time”:“2015-05-25T17:41:33Z”,“switch”:“off”,“indicatorStatus”:""}}]}
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0
/api/gLps2Bkmi504ez7miUw5x0CbxjV1CjLznhtPfjn2/groups/0

From that, it looks like the node server knows about my device(s), but isn’t reporting it to Alexa when she asks about them.

Again, REALLY appreciate your help…

Terry

You’re not understanding what’s needed for those two. The token and app id are used to request the oAuth grant, which then gives you a bearer ID and full url to the service. I didn’t provide a means to do the oAuth interaction - you can do it using curl, starting with the token and app id from when you install the app.

Using a web browser, start oauth interaction using client id and code from installed app

https://graph.api.smartthings.com/oauth/authorize?response_type=code&client_id=THE_ID&scope=app&redirect_uri=https%3A%2F%2Fwww.schettino.us:4567%2Foauth%2Fcallback

Log into smartthings, grant permissions, and click Authorize.

You will get an error page back - but the address at top is what you need - it should look like this:

https://www.schettino.us:4567/oauth/callback?code=XXXZZZ

That code is what you need to do step 2, open this page in your browser next

https://graph.api.smartthings.com/oauth/token?grant_type=authorization_code&client_id=THE_ID&client_secret=THE_SECRET&redirect_uri=https%3A%2F%2Fwww.schettino.us:4567%2Foauth%2Fcallback&scope=app&code=XXXYYY

You’ll see this:

{
“access_token”: “TOKEN HERE”,
“expires_in”: 1576799999,
“scope”: “app”,
“token_type”: “bearer”
}

You’re ALMOST THERE. Now you need the endpoint. This is where you need curl

curl --header “Authorization: Bearer TOKEN” https://graph.api.smartthings.com/api/smartapps/endpoints

That gives you the uri endpoint

[{“oauthClient”:{“clientId”:“CLIENID”,“authorizedGrantTypes”:“authorization_code”},“url”:“/api/smartapps/installations/THISISTHEUUID”}]

So, take the bearer token and the uuid at the end of that url in the last step, and put them in the node app.

So easy, a cave man could do it. Not. But its doable. Good luck Mr. Phelps. poof

1 Like

:slight_smile: Thanks, @schettj, for the smile. I had prveviously done all that you noted to do, albeit perhaps using different terms for the same things, and not using your redirect URI, obviously, but one of my own. I’ve actually developed a couple of other REST endpoint smartapps in the past, so have gone through the oauth process several times. I’m fairly confident that it’s not in the interaction with ST that my setup here is failing, which is why I included the console output above that shows your node server communicating with the ST Smartapp.

It seems to me that the point of failure is at the point that the node server is pretending to be a Hue bridge. No UPNP scanner is seeing the emulated bridge, and while it (the node server) sees the discovery request from the Echo, the Echo isn’t getting the response it’s expecting.

Is there anything in the bridgejson or bridgexml definitions that might need to be different with my setup?

Thanks,

Should not be, those are standard issue. If you are comfortable with PMing me the final access credentials for the webapi app (with one switch) I can check to see if it’s working - or you can with curl by doing

curl --header “Content-Type: application/json” --header “Authorization: Bearer BEARER” https://graph.api.smartthings.com/api/smartapps/installations/UUID/details/switch

(this is the request findlights() does in the node code)

You should get some json back - an array of switches you’ve granted access to in the webapp.

if you’re not getting anything back there, then the lights request from ECHO won’t find any lights.

I get the json back for the one light to which I’ve granted the smartapp access:

{
“devices”: [
{
“id”: “24243966-1773-487d-b763-0412ff0fe564”,
“name”: “Z-Wave Switch”,
“label”: “Bar Light”,
“capabilities”: [
“switch”,
“polling”,
“refresh”,
“indicator”,
“sensor”,
“actuator”
],
“state”: {
“time”: “2015-05-26T16:02:25Z”,
“switch”: “off”,
“indicatorStatus”: “”
}
}
]
}

So that confirms that the Smartapp is ok, and that echosmart.js is able to communicate with it. I can also manually build some on/off commands with the uuid and your smartapp endpoint mappings, and those control the light as I would expect.

That brings us back to the node server and why the Echo DOES NOT (nor any other UPNP browser) see it as a Hue bridge. You did say that any other UPNP sniffer/scanner should see the node server as a bridge, similarly to how the Echo would need to see it, correct?

Anxiously waiting your reply :smile:

Apologies if you have already mentioned this in a previous post, but has anything been discoverable yet by your Echo (Hue bridge, Wemo switch, or the Hue bridge emulator)? If not, it’s possible that it is an issue with your router settings, specifically SSDP and/or UPnP being enabled on your router.

Amazon Echo:Can’t Discover a Connected Home Device
http://www.amazon.com/gp/help/customer/display.html?nodeId=201751350

  • With your voice, say, “Discover my devices.” If you have a Philips Hue Bridge, press the button on the bridge so that your Amazon Echo can discover the device.
  • If you hear “Discovery is complete. I couldn’t find any devices,” make sure your Amazon Echo is connected to the same Wi-Fi network as your connected home device. If not, use the Amazon Echo App to update your current Wi-Fi network.

Note: The WeMo® Switch, Insight Switch, and Light Switch can only connect to 2.4Ghz Wi-Fi networks. If your Amazon Echo is connected to a 5Ghz Wi-Fi network, connect it to a 2.4Ghz network to discover the WeMo® device. If you’re using a dual-band router and don’t know the name of your 2.4Ghz Wi-Fi network, go to the router settings on your computer or contact your router manufacturer for assistance.

  • Disable SSDP or UPnP on your router. This requires you to access your router settings on your computer. If you’re not sure how to access your router settings, contact your router manufacturer for assistance.
  • If Amazon Echo discovers your connected home device(s), but it doesn’t process your request, check that the group name you’ve assigned to the device in the Amazon Echo App can easily be understood by Amazon Echo. For example, if the group name is “b3dr00m lights,” rename it to “Bedroom Lights.” If you named your device using the manufacturer’s companion app, you’ll want to open that app on your mobile device and rename it there.
  • Restart your Amazon Echo and connected home device. To restart your Amazon Echo, unplug the device and then plug it back in again. To restart your connected home device, refer to the user guide for your connected home device.

Hopefully this helps!

1 Like

Trying to figure out why the node app can’t get back switches. It’s getting back

{"error":"true", "type" : "Unauthorized","message" : "Full authentication is required to access this resource"}

I added a console log for the request and get

{ headers:
   { 'Content-Type': 'application/json',
     Authorization: 'VALID_ACCESS_TOKEN' },
  uri: 'https://graph.api.smartthings.com/api/smartapps/installations/VALID_APP_INSTALL_ID/details/switch' }

I validated the token and ID were correct by going to the URL below and getting the expected JSON device list

https://graph.api.smartthings.com/api/smartapps/installations/APP_INSTALL_ID/details/switch/?access_token=TOKEN

I’m still pretty new to node and not familiar with how it sends http requests

This is on a Raspberry Pi with the latest Raspian. I installed node and all the required libraries via NPM (based on running the js and getting the missing library errors)

amazon-echo-ha-bridge has been updated to support dimming. The “onUrl” and “offUrl” now support tokens for ${intensity.percent} (0-100 I think) or ${intensity.byte} (0-255). Does anyone have any idea how to setup an endpoint that would accept a dimmer value within the URL?

Yes!

It’s not very complicated and I actually want to do this code improvement myself for educational purposes.

I just can’t do it this week. Way too much on my plate.