How to specify hub to use with sendHubCommand()?

When using sendHubCommand() from a smartapp installed in a location with multiple hubs, how can I specify which hub is used to send the command?

If this is not currently possible, how does sendHubCommand() currently decide which hub to use?

@Staff_Members @slagle @Jim

I would assume the “selected” hub is the one connected to the location under which the SmartApp that calls the sendHubCommand() is running. As far as I know, a location can currently only hold one hub, so that seems like the common sense way of choosing which hub. To run the command on another hub, the command needs to be executed by a SmartApp that runs within its location, I am assuming again?

Ah, according to

The list of Hubs for this Location. Currently only Hub can be installed into a Location, thought this API returns a List to allow for future expandability.

…poor wording in the documentation.

So if we’re ever allowed multiple hubs in a location, then sendHubCommand() would need updating to support the specification of a particular hub.

That is correct. :smiley:

The new ST app seems to support multiple hubs quite well. I bought another one for my shop building that is out of Zwave range even with repeaters. Everything works great except I have several smart apps which are sending duplicate hub commands because of the multiple hubs. How can I overcome this? Is there any parameter for sendHubCommand or any way to limit to a single hub without having to rework my network?

Ah, I haven’t experienced this myself but I’ve seen reports of it happening with webCoRE and local IP requests.

Not that I am aware of, unless it has never been mentioned. I think this is what they had in mind when warning of edge cases when using multiple hubs.

The architecture works when you are communicating via device handlers and when making external web requests. It is local web requests bypassing the device model that aren’t supported quite fully enough.

OK, so if I call sendHubCommand from a device handler, will it issue the command from only the hub assigned to the device handler?

I simply just don’t know what happens.

To my mind a SmartApp using web requests over the local LAN to communicate with a box (the purpose I assumed for the hub commands) is fighting against the architecture. It seems to me that it is intended that the box should be created as a SmartThings device. As the device can be assigned to a specific hub it seems to me that there isn’t any ambiguity over which hub should be used. Whether that is what happens is another thing.

I tested with sendHubCommand from a device handler assigned to a hub, and I got the same behavior: the LAN http request was sent from both hubs.

It seems like it would be quite simple to add the ability to specify an entry in the ‘options’ parameter of the HubAction constructor to narrow down the hub. I actually tried to guess with a good dozen parameter names, but no dice.

It turns out I was a bit incorrect in my previous reply. At the very least I didn’t have the correct logging on my HTTP server to determine the requests were in fact coming from a single hub.

Some findings:

  • sendHubCommand from a device handler will be dispatched only from the hub assigned to the device
  • all devices belonging to a SmartApp must have the same hub specified (you can observe from the web interface an Access Denied error occurs if trying to set different child devices to different hubs)
  • specifying a different hubId in createChildDevice from the Effective Hub Assignment will be completely ignored and the child device will be assigned the hub from the Effective Hub Assignment
  • at any point that all child devices of a SmartApp are assigned to a single hub, the SmartApp itself will effectively be “assigned” a hub meaning that any sendHubCommand call will only be dispatched from the single hub
  • deleting all child devices clears the Effective Hub Assignment
  • I did observe some weirdness in that sometimes my SmartApps would get the Effective Hub Assignment after only assigning a hub to a portion of the child devices. Yet another time the SmartApp did not get the Effective Hub Assignment until I assigned the hub to all child devices. In any case, if the child devices are created with a hub, this is obviated.

Sorry, I know the above is a bit disjointed, because I gave up trying to understand the exact behavior.

@orangebucket: Both of these SmartApps are bridges that communicate with a single “processor device” in order to expose many devices to SmartThings. Even each HTTP call applies to many different SmartThings devices. I suppose I could create my “processor device” as a SmartThings device, but I did not feel the need when I first created these.