Can WebCoRE Bridge Multiple Hubs/Accounts?

rtvanhook · 2018-09-26 13:39:22 UTC

1) Give a description of the problem

As a parent of two teenagers who don’t always get along…

The first child would like to control his lights.
The second child would like to control her lights.
Neither would like the other to control his or her lights.
But both would like to control a common hallway light.

And my wife and I would like to control all 3 (his, hers, and common)–but ideally don’t want either controlling the rest of OUR lights.

We use Alexa for day-to-day control, and nobody but me uses the SmartThings app. We have three different Alexa devices signed into three different Alexa accounts, but they all link to the same SmartThings hub/account…without the ability to limit which Alexa account sees which SmartThings device…and that’s the root of the problem.

I’m not opposed to multiple SmartThings hubs and accounts…and one possible solution (and perhaps this is easy…) might be the creation of virtual devices in one hub/account that are somehow mirrored to actual devices in another. I just can’t figure out the “somehow mirrored” part. Perhaps WebCoRE can help? Robin once mentioned it on the SmartThings forums.

2) What is the expected behavior?

Virtual device state on one SmartThings account/hub is mirrored to actual device state on a different SmartThings account/hub.

and/or

Actual device state on one SmartThings account/hub is mirroed to virtual device state on a different SmartThings account/hub.

WCmore · 2018-09-26 16:27:29 UTC

It is definitely possible to use webCoRE to talk (and listen to) multiple hubs…
… BUT…
it will make even a simple piston quite complex, and make a single ‘light on’ command actually send out multiple web requests as well. (which will double if you want to verify the status of the Simulated Switch)

So, while all of this is possible, I highly recommend steering away from this idea. You will drive yourself bat-crazy, and you would miss out on the true power of webCoRE.
(and even if you went thru the process, there is nothing stopping ChildA from giving a command to ChildB’s Alexa… If there is a will, there is a way)

Perhaps the easiest solution (if they were my kids), is to simply take away their Alexa for awhile if they cannot play nice and abide by your house rules.

That being said, here is one basic example of one hub talking to another. Double the code if you are syncing a SimSwitch. Triple it if you send a reply back to verify the device’s status.
(and triple it again since you are considering 3 hubs)

Notice each light or command has to be programmed on each & every hub.

Here is another example more geared towards your goal. The following example assumes that:

HallLight is connected to Hub-A
SimSwitchB is connected to Hub-B
SimSwitchC is connected to Hub-C

HUB-A

If HallLight changes to on
Then 
    Send GET request to HubB with arguments 'onReal'
    Send GET request to HubC with arguments 'onReal'
End If

If HallLight changes to off
Then 
    Send GET request to HubB with arguments 'offReal'
    Send GET request to HubC with arguments 'offReal'
End If

If incoming web request has the argument 'onSim'
Then
    Turn on HallLight 
End If

If incoming web request has the argument 'offSim'
Then
    Turn off HallLight 
End If

HUB-B

If incoming web request has the argument 'onReal'
Then
    Turn on SimSwitchB
End If

If incoming web request has the argument 'offReal'
Then
    Turn off SimSwitchB
End If

If SimSwitchB changes to on
Then
    Send GET request to HubA with arguments 'onSim'
End If

If SimSwitchB changes to off
Then
    Send GET request to HubA with arguments 'offSim'
End If

HUB-C

If incoming web request has the argument 'onReal'
Then
    Turn on SimSwitchC
End If

If incoming web request has the argument 'offReal'
Then
    Turn off SimSwitchC
End If

If SimSwitchC changes to on
Then
    Send GET request to HubA with arguments 'onSim'
End If

If SimSwitchC changes to off
Then
    Send GET request to HubA with arguments 'offSim'
End If

It is important to note that there will be about 1-2 seconds delay from the moment a SimSwitch is toggled, until the command is read and acted upon back in Hub-A.

So that is at least 16 groups of logic in 3 different pistons for the most basic command possible.
(which means if someone flips the HallLight 5 times quickly, you can basically create a mini-DoS attack on your home network)

Seriously, don’t do this. You can thank me later

The only reason I took the time to create this example is to show you how much grey hair you’ll aquire if you go down this path…

WCmore · 2018-09-26 17:29:00 UTC

For the record, multiple hubs works best when only a few ‘flags’ are set across the miles…

For example, if I am approaching time off from work, I can send a command to my vacation house to set a certain variable there. My vacation hub has code in place to do things a bit differently if that flag has been set. (AC adjusts etc)

This way, I only need to send one command a couple times a year to update my ‘status’ at the vacation house.

rtvanhook · 2018-11-05 13:35:51 UTC

Got some time to hammer away some more. Much thanks to both Robin and WCmore. But it doesn’t seem to be working as I expect. Issue is triggering pistons across locations.

I downscoped the problem to the “simple” issue of keeping a real switch in one location synchronized with a virtual switch in another.

As WCmore suggested, I have 3 pistons at each location–one to turn the switch on when triggered, one to turn the switch off when triggered, and one to trigger the other hub’s on/off pistons when the switch changes.

It works using external URL calls.

It doesn’t work using “Execute Piston” across multiple WebCoRE instances.

As Robin instructed me, I logged into one dashboard and then “register instance” for the other. I can then a) switch back and forth between the locations, and b) allegedly trigger one locations pistons from the other.

But it’s not happening.

11/5/2018, 7:10:34 AM +622ms
+1ms ╔Received event [Robert’s Room].switch = off with a delay of 630ms
+110ms ║RunTime Analysis CS > 34ms > PS > 61ms > PE > 15ms > CE
+113ms ║Runtime (37814 bytes) successfully initialized in 61ms (v0.3.108.20180906) (110ms)
+114ms ║╔Execution stage started
+124ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+126ms ║║Cancelling condition #2’s schedules…
+127ms ║║Condition #2 evaluated false (7ms)
+128ms ║║Cancelling condition #1’s schedules…
+130ms ║║Condition group #1 evaluated false (state changed) (10ms)
+137ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+139ms ║║Cancelling condition #6’s schedules…
+140ms ║║Condition #6 evaluated true (7ms)
+141ms ║║Cancelling condition #5’s schedules…
+143ms ║║Condition group #5 evaluated true (state changed) (10ms)
+145ms ║║Cancelling statement #7’s schedules…
+158ms ║║Executed virtual command executePiston (8ms)
+162ms ║╚Execution stage complete. (48ms)
+163ms ╚Event processed successfully (163ms)

It seemed to “Execute virtual command executePiston”…but the piston doesn’t execute on the other hub.

WCmore · 2018-11-05 18:18:07 UTC

As far as I know, execute piston does not work between hubs, but external URL calls do.
(although you can edit both hubs from the same browser, which is nice)

This is because external URL links work regardless of source. That link can be in a SMS app, email, third party app etc. (and why it is so important to only share that URL with people you trust)

Alternatively, "Execute piston" is an internal command, so it stays within that same hub.

rtvanhook · 2018-11-05 19:51:26 UTC

Thanks for your quick response.

If it won’t allow piston execution between hubs, it certainly lets me write non-functional code that LOOKS like it will.

Perhaps I’m the only one this will confuse, but–just in case–I re-posted just to document the non-functionality.

It works just fine with url calls.