Status of Echo/Alexa fix for multiple Smartthings locations?


(Sean) #1

I recently tried to integrate a second Smartthings Hub at “location 2” but ran into a problem where my Echo can only see the devices from “location 1”. A forum user indicated this was a problem with Oauth of some kind. I also see on this FAQ that a fix for this is coming:

Anyone know the status of this work? I really, really don’t want to have to create a whole separate account and redo all my IDE work to get this working.


PSA: If two locations/hubs both have Alexa + Smartthings integration - Alexa will only be able to control devices from one of them
#2

Tagging @slagle


(Scott Alexander) #3

Interested to hear if Tim has any updates. But you might check out this thread for some background.

@MichaelS Alexa Helper is probably the best current work around that I’m aware of that doesn’t involve splitting each location off onto its own account.


(Sean) #4

Thanks for the link to that discussion, I didn’t find it in my search. How are you using Alexa Helper to make this work? I have it installed as well but don’t know what configuration would be needed to run Alexa as both locations from one ST account.


(Scott Alexander) #5

So basically Alexa’s Cloud to Cloud integration interacts with a single SmartThings location. In addition to the standard devices that location manages, it also has virtual switches representing devices in the 2nd SmartThings location. Alexa Helper allows you to take actions on your second location based on the state of these virtual switches in your first location. It uses OAUTH to send over that command. See the following wiki especially the tips and tricks section that describes a Washington/Oregon scenario.

http://thingsthataresmart.wiki/index.php?title=Alexa_Helper#Cloud_Interface_Smart_App_Setup

So basically the flow is Washington includes a device called “Kitchen Lights” that is a standard Zwave switch. Further, it contains a device called “Oregon Kitchen Lights” that is a virtual switch. Both of these devices have been authorized for Amazon’s Alexa smart app to control. Since that authorization is at the Amazon account level, any Alexa device on that account, regardless of physical location, will be able to interact with the Washington SmartThings location. Finally, using Alexa Helper you’ll configure a scenario such that when Oregon Kitchen Lights is turned on it sends an http request consisting of the url generated by Oregon’s Could Interface Smart App to turn the “Kitchen Lights” on. Note Oregon was specifically left out of those quotes there because here we’re referring to the Oregon Hub’s “Kitchen Lights” device not the Washington Hub’s “Oregon Kitchen Lights” virtual switch…

So when you say “Alexa turn off the kitchen lights”, Alexa will ask the SmartThings Washington Location to turn off that light. SmartThings will send a zwave command from the Washington Hub to that switch (using repeaters along the way) to accomplish that task. When you say “Alexa turn off the Oregon kitchen lights”, Alexa will ask the SmartThings Washington Location to turn off that “Oregon Kitchen Lights” virtual switch. That in turn will trigger the Alexa Helper scenario that says anytime “Oregon Kitchen Lights” is turned off send an http request using the url generated by the Oregon Location’s Cloud Interface Smart App for it’s Kitchen Light’s device off command. That http request will make use of OAUTH to go back up to SmartThings cloud, be directed to your Oregon location’s hub, which will then send a zwave command from the Oregon Hub to that switch (using repeaters along the way) to accomplish the task…

Put even more simply:
“Alexa turn off the kitchen lights” = Amazon Cloud -> SmartThings Cloud (Alexa SmartApp) -> Washington Hub -> Kitchen Lights Switch Off
"Alexa turn off the Oregon kitchen lights" = Amazon Cloud -> SmartThings Cloud (Alexa SmartApp) -> Washington Hub -> Oregon Kitchen Lights Off (Virtual Switch) -> SmartThings Cloud (OAUTH/Cloud Interface SmartApp)-> Oregon Hub -> Kitchen Lights Switch Off.


(Aaron S) #6

Using the Alexa and IFTTT across multiple locations on the same accounts is still a limitation. Most users never come across this limitation, which is why it hasn’t been prioritized as a bug. It’s on the list with other OAuth improvements, but - in full disclosure - a change will likely not happen in the near-term.


(Scott Alexander) #7

Yeah its only the users who believe so much in the platform that they support it multiple times over that get spurned on this one. I say that half in jest of course; since with everything else going on the decision makes sense. Logic doesn’t take the sting out though. :slight_smile:


(Ed Wolfe) #8

Has anybody been able to get this to work. It seems like the auth code keeps changing after each run. For instance I past the generated URL into a browser and it works. However, the all subsequent tries of the exact same url yeilds an access denied - invalid token.


(Scott Alexander) #9

Yeah I use it quite a bit. Your error does sound very strange that it works but then token no longer valid…I just went into Cloud Interface app and tried my url multiple times and seemed to work fine…Can you just confirm paste url, works, turn off via smartthings, hit refresh in browser, does what?


(Ed Wolfe) #12

OK. I got the URL working consistently in a browser; the problem was my lack of understating how to add the Cloud Interface to the SmartThingsApp. Now, however, my Alexa switch does not turn the light on or off. I’ve tried both pushing the On/Off button in the SmartThingsApp and asking Alexa to turn it On/Off. Any ideas what I can look at?


(Scott Alexander) #13

So here is the layout of how it works:

Physical Device -> Smart Switch -> hub 1 -> Cloud Interface SmartApp exposes control of switch via url to anyone with that security token.

Virtual Switch -> hub 2 -> exposed to Alexa which can only be connected to one hub (location) in this case hub 2.

Final part is to use Alexa Helper SmartApp in hub 2 to create a Virtual Switch whose sole purpose is to make the URL call (the call to hub 1’s Cloud Interface SmartApp) and when turned off to make a separate URL call (almost same but with off rather than on). That switch you expose to the Alexa SmartApp so you can use voice control so the flow of data is as follows:

User makes voice request to Alexa to turn on virtual switch -> Alexa SmartApp makes call to hub 2 to turn on virtual switch -> hub 2 Virtual Switch turns on which evokes a url call to hub 1 Cloud Interface SmartApp -> hub 1 Cloud Inteface SmartApp processes request and tells hub 1 to turn on the hub 1 SmartSwitch -> Lights come on…

That works pretty well so long as you always use hub 2’s virtual switch (either via app or alexa) to control hub 1’s physical switch. If you ever use hub 1’s switch either manually by pressing it or via hub 1 app then you probably need to setup Cloud Interface going back to virtual to keep them in synch.

Let’s say the light is on and both hub 1’s physical and hub 2’s virtual show on. If you physical press the toggle off. it will turn off light, turn off hub 1 physical. Hub 1 physical will evoke rule to make url call to hub 2 Cloud Interface. hub 2 cloud interface will turn off hub 2 virtual. hub 2 virtual will make url call to hub 1 Cloud Interface to turn off hub 1 physical. hub 1 physical switch is already off so nothing will be done but both switches will again be in synch (both off)…That’s the advantage of using on/off rather than toggle.

Hope that helps let us know if get stuck.


(Ed Wolfe) #14

Yes, I understand the concept. However, there is is either a bug or my configuration is incorrect in some way because when I tell Alexa to turn on the virtual switch, she says “OK” but there is no affect on the light. However, if I click the On button in SmartThings for the hub where the physical light is located, it works fine.


(Scott Alexander) #15

Did you create the Alexa Helper scenario as a HTTPS control type tied to your alexa controlled virtual switch with the “on” scenario setting of an http request to your browser confirmed “on” url and an “off” scenario setting of an http request to your browser confirmed “off” url?

You need that Alexa Helper http scenario to tie the virtual switch in hub 2 (alexa hub) to the physical switch in hub 1 (Cloud Interface SmartApp hub).


(Ed Wolfe) #16

Yup, I’ve done all that. When i look at it via the SmartThings api hub, it all looks good. I cut and past the URL from the website and past it into my browser address bar and it turns the light on/off as expected. Just doesn’t do it when I ask Alexa or push the virtual switch button in SmartThings App.


(Scott Alexander) #17

Can you post screenshots of your Scenario Settings obfuscating the oauth portion of your http request?


(Ed Wolfe) #18



(Ed Wolfe) #19

Does anybody see an issue with the definition?


(Ed Wolfe) #20

I set up another Alexa Switch to send a URL to someplace else and it never sends either. The problem is then with the Alexa Switch not sending the URL.


(Scott Alexander) #21

Your settings are lil different than mine,

Name Type Value
AlexaSwitch capability.switch Lake Ramp Lights
offContacts contact []
offDelay number "0"
offExtInt enum 0
offHTTP text https://graph.api.smartthings.com:443/api/smartapps/installations/redacted/w?l=Ramp%20Lights&c=off&access_token=redacted
offPhrase enum ""
offSHM enum ""
offSMSMsg text ""
onContacts contact []
onDelay number "0"
onExtInt enum 0
onHTTP text https://graph.api.smartthings.com:443/api/smartapps/installations/redacted/w?l=Ramp%20Lights&c=on&access_token=redacted
onMode mode ""
onPhrase enum ""
onSHM enum ""
onSMSMsg text ""
runDay enum []
runMode mode []
scenarioType enum Control
showOptions enum “”

My helper version is 4.5.2


(Ed Wolfe) #22

I have 4.5.3a (according to the code comments). How can I get 4.5.2 to see if that works better.