Maybe it's good listening when HE <-> HE, but HE <-> ST was not ?
Ok, make sense, mine I had to play a lot until I got it but I deleted all instances because the hub not appearing in the server device list, still with that problem
I believe you should wait until the new release tomorrow.
I just make them connect again when I find out : Hub Connect Remote Client had 2 build 1.5 and 1.7 . Now I use build 1.7 and ST connect to HE.
Mine worked first try more than a week ago..
ZeeSmarts is the SmartThing hub in this mix.
Looking your screenshot, is not the remote hub driver the same for both hubs? ST and HE? Looks like it's different
The Github has two 'folders' and the SmartThings one has one App.. the Remote Client app for SmartThings.
HubConnect-Remote-Client.groovy is not the same as HubConnect-Remote-Client.groovy
One is for ST and one for HE.
It's using an identical name so that Server makes no differentiation for the Platform.
That is the app installed in the remote hub, I meant the driver installed in the server
For you, I have
I removed the SmartApp from ST, which deleted all the HE devices I had 'sent' to ST.
On Hubitat Server Hub, I deleted the hub (ZeeSmarts) from devices then sorted on DNI column and deleted everything with the ST's IP addr.
I'm ready to add a ST hub, again.
Same NAME different code.
One code for ST
One code for HE
I thank you for this but honestly I'm more worried about the HE to HE problem, I have my hubs disconnected because the server is not installing the virtual hub on the device list
The only way that can happen is by either not following the directions to the letter, or by not inputting the correct IP address. I cannot replicate this on my dev hub on a clean install using the latest hub version.
I can give you 2 separate remote IPs and the local IPs addresses and you can try yourself, I know I'm following the instructions, I had no problem with the old code to link 3 HE hubs, the problem was with ST but it was the cloud issue and it was fixed, now just using the 2 hubs that they worked with the old code they are not creating the hub in device list. The only difference is the updated code.
The issue with the virtual hub devices not being created is a partial bug.. Success/failure depends on the order of steps that a user takes.
Tomorrows update will have this fixes so that virtual hub devices are consistently being created when a new hub is connected. I've also added improved key exchange error handling, the ability to disconnect hubs, and some other fixes.
@csteele is doing some final testing on the 1.2 release.
I've been testing asyncHttp for a couple days. As is apparent from all over the forum, async is a small'ish change, with big potential.
But a few hours ago I began testing EventSocket vs http and my testing is finding no problems... yet. It's another change with so much potential to reduce the processing time.
I have been playing with the eventsocket for the last week or so and it is amazing how much load it can take off the system by not having to subscribe to every event..... It has also been very stable for me and I can only suggest to continue into that direction.
That will be an option in 1.2 which is coming out today. The speed improvement is very noticeable. I'm sure most will see the difference.
Unfortunately there is no way to filter data going over the eventsocket so HubConnect won't be supporting eventsocket communications in both directions, only remote -> server. This is because eventsocket on the server hub contains all of the aggregate events from the remote hubs. That means all events from all remote hubs would be sent back to every remote hub, creating a lot of unnecessary traffic and load on the remote hubs.
I have a suggestion, could you create a folder in github with copies of the older code releases? this is useful to go back to a previous version if we forgot to save it before importing the new one to our hubs. Thanks.
I have a simple design question, the flexibility of this is awesome but daunting - given the upcoming eventsocket stuff is it better to synchronize devices TO the server or connect local server devices to the client hub or does it matter?
That is exactly what github does. You can see and download older versions by using the History tab.
Since the concept of a server hub (or coordinator) is to act as the aggregator of devices, the eventsockets were implemented in that direction with the server hub listening for events on the sockets from the remotes.
You can have device communications in both directions if needed, server to hub will continue to use the http oAuth method for those events.
When selecting a server hub, I recommend delegating a hub that either has no radios (optional), or one which will have the fewest locally connected devices. If you only have two hubs for example, I recommend making the hub with the least amount of directly connected devices your server hub. Even in that deployment, you can still have a local device off of your server hub and link it to a remote hub so it's available for automations on both.
You are unfortunately correct, the flexibility is a bit overwhelming at first, but once you get the hang of it you will have a really powerful system!