Ops my bad, I’m using simulator’s device instead of actual device
so basically simulator devices gave me different hub ID
and the actual ID gave me hub ID same as https://graph.api.smartthings.com/api/hubs
thanks Andy…
1 Like
Digging this to resolve a confusion. @tyler @tgauchat
- Is it still limited to one hub per location?
- Assuming that location.id and hub.id are different - is that understanding correct (since there can be multiple hubs per location)
- How does one get the hub id of the hub on which the SmartApp is running
I’m asking point 3 in contact of adding child devices when using the addChildDevice() API which has a parameter fro hub id. Now in the documentation examples it’s using upnp devices to get the device id (god know where that comes from) but in a service manager architecture the devices are being created by the SmartApp, so if one can get the hub on which the SmartApp is running, it can be used for the child devices.
1 Like
Pick the first Id in the list, element 0, or make the user select it, or use null for the hub id if you don’t need callbacks from the child device.
I’m using null right now but I suspect it’s broken. Some new examples are using the hub id (but taken from some device).
Using hub[0] was my initial thought but then with multiple hubs that wouldn’t necessarily be the hub on which the smartapp is running. How can I make the user select it? As in select the hub? Isn’t there anyway to know which hub the smartApp is running on?
It’s a good question, because though I can’t find a constraint in the documentation that defines a 1:1 relationship between Location:Hub, there is no relationship documented between SmartApp_Instance:Hub… Just SmartApp_Instance.Location…
http://docs.smartthings.com/en/latest/ref-docs/smartapp-ref.html
Right correct, I saw that but couldn’t figure out how to get which hub in that location. Assuming that ST still allows multiple hubs in a location.
The issue is with this API
http://docs.smartthings.com/en/latest/ref-docs/smartapp-ref.html#addchilddevice
hubId - (optional) The hub id. Defaults to null
Why hub id and not location id, I don’t know.
There’s a gap in the documentation or an inconsistency in the data model… @Jim?
A Device must be associated with a Hub unless it is Virtual or Cloud Device.
A SmartApp does not need to be associated with a specific Hub… Unless it is locally executing. Though, frankly, it makes it easier to point to any physical Device more accurately, I guess.
Remember that, originally, there was no such thing as local execution, so SmartApp:Hub was unneeded relationship… Right?
So when a SmartApp Service Manager is creating a child device are you suggestion it should ask the user which hub to create the device on? Hmm makes kinda sense if the SmartApp isn’t running on a specific hub, it needs to device which hub to create the device on.
BTW how does one ask the user to “select” the hub? There’s no capability called hub.
If I answer the question, what do I get in return?
2 Likes
A heart felt thank you! 
BTW the answer is here (although I still think it should mentioned on the capabilities page)
http://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html
So here’s a really funky thing I found, I have only 1 hub (verified from the IDE also, says I have 1 hub and also from teh ST app in settings).
But if I do this
location.hubs.size()
I get 2!
I checked the id’s the 1st one is some id I can’t match, the second one is the real deal.
Now that’s a brain teaser. Anyone? @Mike_Maxwell
EDIT:
Here’s the BEST part, when I use this code:
input name: “installHub”, type: “hub”
It ONLY gives me one hub to choose from. But location.hubs.size() still says 2.
EDIT: The 1st hub (which I can’t see) is a Virtual hub. I didn’t create it, wonder…
Well… In theory you can run a SmartThings Location without a real Hub… So maybe a virtual exists for that odd case just for data integrity?
I wish SmartThings would just document and publish a detailed Object Relationship model.
I agree, I’m just thinking about all those apps using location.hubs[0].id assuming that only hub exists…
Particularly since I didn’t create this virtual hub.
Alex however mentioned in the dev conf yesterday that ST would be happier just putting code out there for devs to use a reference rather than just documention (if I remember correctly).
What does it matter what makes “SmartThings” happy? Isn’t the company supposed to be making Customers happy? (And Community Developers are Customers!) 
I have to watch the whole video to get this in context, of course…
1 Like
@RBoy
I use this method to always get physical hub instead of virtual
def hub = location.hubs.find() { it.type.toString() != "VIRTUAL" }
if (hub == null) {
log.error("User has no physical hub on this location")
return
}
2 Likes
Thanks, yes I got that (BTW another tip, to get the local IP for the hub use hub.localIP and not hub.localIp
What I was curious about was how I ended up with a virtual hub when I never created one.
BTW @Cety, minor modification since one could have multiple physical hubs I used this:
def physicalHubs = location.hubs.findAll { it.type == "PHYSICAL" } // Ignore Virtual hubs
Now you can choose which hub you want (or have the user select it)
Yah… that’s an interesting edge case for Camel Case usage guidelines…
- When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
- Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.