Help with multiple locations

Devices & Integrations
1

Hi!
Hopefully someone can help me.

I have 4 hubs in 4 different locations (restaurants)
I’m using ifttt to create a trigger when I get an online order to set off an alarm. I have iftt connected and repicies set up to turn trigger if I get an email with #location1 #location2 up to 4. However, the recipe keeps turning on the same alarm in location1. Can’t seem to set up a recipe that will set off any of the other locations alarms. When the recipe asks to set up the channel with smartthings the only option I have in the “select an alarm” is from location1.

Any ideas? I know it’s kinda complicated

Thanks in advance!

2

You will need a different IFTTT account for each SmartThings location, I think.

You could then trigger events across different IFTTT accounts using the IFTTT Maker channel to trigger from one to another. IFTTT account can be many actions from one trigger, just set up multiple rules each with the same trigger.

Be warned, IFTTT events can have a delay (depending on which channels you are using), so I would recommend you make sure you have some other way of getting your orders to each restaurant, or you could have some very unhappy hungry customers !

3

Thanks for the feedback. Not sure I know how to do that, but I’ll hook to that channel and see if I can figure it out.

4

Unfortunately Most third party integrations are limited to accessing 1 location. @tgauchat and @625alex worked around this somewhat with their new SmartTiles, but its my understanding that the standard SmartThings supplied 3rd party integrations (IFTTT,Echo,etc…) are still limited to the one location.

So even if you had 100 different IFTTT accounts, if they all come into SmartThings via the same account you’ll only be able to use devices in one of your 4 locations.

With the recent SmartThings account sharing, you could potentially move each of your hubs (with supports help) into their own account (thus requiring 4 emails). Each account would have its own custom device types etc… You could then cross share all accounts if you wanted to allow access to all locations from the app. At that point you should be able to associate IFTTT account 1 with SmartThings Account/Location 1, IFTTT account 2 with SmartThings Account/Location 2, etc…

5

That’s actually not true anymore – no “workaround” is required if the integrator is using the basic, but proper, authentication procedure.

When you link SmartThings to each single IFTTT Account (or each single Echo Account), it links to a specific Location under your SmartThings Account. The 3rd party service (IFTTT) has no idea that the Locations are related to the same SmartThings Account.

(i.e., The root of the authorization tree is Location, not Account).

6

Have you tried it? I have two IFTTT accounts and I can only interact with one of my locations under my single SmartThings account. Now maybe you’re qualifying your not true statement with the “if the integrator is using the basic but proper procedure” clause, meaning the newly provided method of integration used by SmartTiles does remove this restriction.

But if that’s the case you’re really not saying anything differently than I did. Bottom line, unless there is something broken with just my specific integration, currently even 100 different IFTTT can only interact with 1 location per SmartThings account.

Will SmartThings reach out to IFTTT informing them of the benefits in updating their integration? Will IFTTT decide its worth the investment to do so? Maybe but right now, based on my testing, it appears my statement remains true.

2 Likes
7

Just did… and you are correct.

IFTTT improperly uses the SmartThings Account ID (email address) for the connector database instead of the Location ID; and this makes it impossible for you to use IFTTT with more than one Location, regardless of the number of IFTTT acccounts.

The problem is entirely on their side (since SmartThings currently does not allow a single SmartApp instance to interact with devices from more than one Location; all that IFTTT needs to do is:

(a) Use Account ID (SmartThings login email) + Location ID as the identifier for the Connector instead of just Account ID.

and

(b) Allow multiple SmartThings Connectors to run under one IFTTT Account.

8

I agree this may be your best option. I have a hub at 2 different locations. The one at my house is my main one. For the 2nd location, I created a new Smartthings account and then added that shared that location with my home. This way my iphone has both locations on it. I also have 2 ifttt accounts. The reason I set it up this way, is I don’t need anyone who has access to location 2 having access to location one, but I need access to both. My only concern for you is will ifttt let you connect the same email channel you using with the keywords for #Location1, #Location2 to multiple ifttt accounts. If you can, this should work for you. If you wanted another option than using an alarm this way, you could hook a tablet up with speakers at each location and have ifttt trigger a virtual switch that could make the table speak instead of having an alarm go off.

9

Not to quibble too much, but I’m guessing IFTTT is using the integration method SmartThings provided when they first created the channel. Further It seems like the improper logic is more on the SmartThings side of forcing third parties to account for the concept of SmartThings locations. Imo, that should be abstracted beneath the web service layer. It just seems like a stretch to say every 3rd party integrated wrong… To me it seems more that the improper logic and problem is simply the SmartThings restriction that SmartApps can’t interact with devices across locations and thus requires each 3rd parties integration to be replicated for each SmartThings location a single SmartThings account wants to expose to said 3rd party…

Am I glad SmartThings developed an integration work around? Absolutely, but will I be surprised if 3rd parties don’t jump at the chance to redo their integration “properly” ? Not so much.

1 Like
10

No workaround is currently used.

A SmartTiles Dashboard can only contain Things from a single Location at a time. Users, however, can install up to 5 Dashboards per Location. Previous to a SmartThings bug fix, it was not possible to install SmartTiles to more than one Location under a single SmartThings Account. That bug was fixed in approximately October 2015.

SmartThings is working as designed at this time. IFTTT and other services may not know that the previous bug has been fixed, or are waiting for a design improvement; but it is not difficult for them to implement their connectivity to spec. It was trivial for SmartTiles (once the bug was fixed).

11

I’m not talking about SmartTiles specifically. I’m talking about SmartThings providing a workaround to their arbitrary design decision that prevents their original integration method from allowing 3rd parties to interact with more than 1 location per account via a single account to account connection.

The workaround they provided requires multiple connections that are made unique by the location id being appended. While the update for the extra locationid to the webservice call my be trivial, the work effort to represent the SmartThings location topology within the 3rd party may not. For instance IFTTT may see a chancel=service=single integration connector. It’s basically asking the third parties to create the location abstraction at their layer rather than where it belongs in SmartThings.

Presumably the currently used connectivity is stil to spec, its just not to the latest spec they released as of October 2015. If it was an improper and unsupported spec I assume SmartThings would error out on its use rather than allow it through.

2 Likes
12

The object-data-model of SmartThings has SmartApp Instance Objects linked to the Location Object instead of the Account Object.

It isn’t an “arbitrary” design decision; though it would be nice to learn of the precise reason for the design.

This may be different than the way IFTTT (etc.) interface with other vendors that have some concept of “multiple-locations-under-one-account”, but that doesn’t make SmartThings’s design arbitrary or incorrect.

IFTTT’s entire product is based on the ability to interface with arbitrary services, regardless of the particular unique designs and other API challenges each such service presents.

I’m not saying SmartThings has a good API (man, it has a lot of shortcomings), but I am saying that this particular challenge is not difficult to accommodate. This is IFTTT’s wheelhouse!

13

While I agree that this is a possible way for third party developers to string things together to get it to work, this seems like quite a hack and is not a clean architecture.

@scottalex has already put into words the things I’m thinking. :slight_smile:

On the other hand, focusing on improving the stability of the platform is probably more important than supporting multiple locations in a single SmartApp at this point.

3 Likes
14

Absolutely agree. I’ve already taken this thread too far off track, but my main objection to terry’s great insight was simply the onerous being so easily placed on the 3rd parties to work around SmartThings design. My apologies to @Stythe, in short recap for your specific question. In its current state you should be able to accomplish your goal but you would need to have a 1 to 1 to 1 location/SmartThings Account/IFTTT account setup…

1 Like
15

I agree… It’s just that SmartThings is a rather young company to have a “legacy architecture” that has to be “hacked around”. There must have been some reason that SmartApps live at the Location level instead of the Account level. Or perhaps I’m uncharacteristically giving SmartThings’s architects and engineers too much credit.

Hear hear … I don’t even know if this issue is on the very edges of their radar; perhaps it should be, because it might be a key element to making it easier to build a Hub-to-Hub (Location-to-Location) “Migration Tool”, something that is, supposedly, a high priority project.

The reason I’m so motivated in this particular thread, is that this particular problem has a relatively simple workaround (especially for a company with the mission and sophistication of IFTTT!); whereas, as you note Josh, the Platform has much worse problems that are very difficult or impossible to workaround.

@scottalex … Thanks for the lively discussion. I hope someone at SmartThings (@jody.albritton?) can escalate this to their partnerships department to come to a resolution with IFTTT.

16

From a really-big-system perspective, I’m in agreement with those who said it’s not up to IFTTT to make this change, they’re using the standard oauth model: the only information you enter on the Ifttt page is your account login credentials. Once you’re in, it’s up to SmartThings to determine what information will be exposed in their IFTTT channel. There is no reason at all for IFTTT to know that locations exist in the ST model. All they offer is a doorway. What’s on the other side of that door belongs to ST. ST needs to handle any subaccount issues from their side.

JMHO. :sunglasses:

1 Like
17

I agree that this is the ideal situation, but it’s a simple fact that SmartThings hasn’t changed their data model related to Accounts / Locations and SmartApps (REST-API Endpoints) since their initial integration with IFTTT.

SmartThings didn’t even revise the data model over the past year when it could likely have facilitated Hub V1 to Hub V2 migration.

I’m not disagreeing that SmartThings has a significant weakness abnormality in their data model and/or the API to it (from an outsider’s perspective); but that doesn’t excuse whoever wrote or is responsible for the IFTTT integration from the task of just making it work; I don’t know if that responsibility lies with an employee of IFTTT or SmartThings; but just complaining about it and pointing fingers won’t fix the problem.

SmartThings has no obligation to make this “easy” for anyone (and trust me, they don’t – @625alex and I are working on multiple Location support for SmartTiles Dashboards right now, and it’s a pain in the donkey, but it is completely doable with enough work; we just wish our time could be spent on other things). And, SmartTiles even (successfully) developed and Beta tested a short-lived workaround to support multiple locations while the SmartThings multiple location OAuth installation bug existed for a period prior to October 2015. We saw a problem, reported it, and then proceeded to figure out a solution for our Users.

And SmartTiles is just us two folks; IFTTT (or their SmartThings counterpart) has a magnitude of more resources. If SmartTiles can do it; so can IFTTT; and Amazon Echo, for that matter.

I think the fact that the integration doesn’t work reflects poorly on the reputation of both SmartThings and IFTTT; perhaps a little like the sketchy integrations of Nest Thermostat and Philips Hue, etc… There are two sides to every integration, and it doesn’t matter if one is “technically” right and the other “technically” wrong. The buck :dollar: has to stop :x: somewhere.

1 Like
18

I think I stepped in way over my head here! But I THINK I agree that at this point my only option is to have a 1 to 1 relationship between ifttt and smartthings accounts per hub. Until a better solution is available. I understand that this is relatively new tech, so I’ll live with the inconvienence for now. Thank you all who responded.

2 Likes
19

I just discovered the limitation with IFTTT and multiple locations. However, I don’t know if they changed something but I was able to create another IFTTT account, connect to my same ST account, and create recipes using the 2nd location. My recipes using both locations are firing correctly.

1 Like
20

Small additional data point: I found that yes, I could create a second IFTTT account and connect to the second SmartThings location and that at the end, recipes for both accounts/locations fired correctly.

HOWEVER, when I went back to the first location and added a switch and wanted to create a new recipe, that’s where things went south. I could ONLY see the SmartThings devices at the second location from the first account (which had previously been controlling the first location). Try as I might, I could not fix it. I disconnected and reconnected SmartThings from IFTTT on the first account – which was a huge mistake as it killed the existing recipes working with the first location. Now I can’t even recreate those.

So, short story: I’m going to have to delete and rebuild the hub configuration for the second location even though the second location appeared to work in the beginning. I have to admit… this is a little infuriating.