You absolutely correct. This goes back to a time when most were still not using the new app. I'll make sure a note is added for the next release.
Exactly. You have nothing to worry about. If you end up using websockets, the messages sent between hubs are only a few hundred bytes, max. They're normally small enough to fit into a single IP packet.
Another question:
I have decided (basically) to put my devices on one hub, and all the rules on the other
What do I do about a Group Switch?
I can't move that from the remote to the server.
A further question:
Isn't the state (for a switch on/off) supposed to be reflected (shortly thereafter) from the remote to the server?
I have 3 simple switches (zwave plus), with a simple lighting rule:
-when switch "a" turns on, turn on switches "b", "c", "d"
I had this simple lighting rule in my remote hub.
After setting up the server, I put this rule in the server, and removed it from the remote.
It doesn't work, because the state of switch "a" isn't pushed from the remote to the server.
How is it supposed to work? Am I supposed to issue a command "synch" to get it to work?
Also, I got the following error:
That's umm.. 4 switches.
What is switch "a" ? Real or virtual? It's using a Hubitat built in driver, correct?
Is the 'mirrored' switch found on the server hub?
Thanks for taking the time.
Yes that's 4 switches.
Switch "a" is using the built in "generic zwave smart switch", and it's a real Leviton switch, on the remote hub.
The mirrored switch is found on the server hub.as a "Hubconnect Switch".
When you toggle switch "a" via the Device Info page, does the 'mirrored' switch match?
If no, delete the 'mirrored' switch from Server's devices and re-select it on your remote. When you've clicked Done all the way out, HubConnect will recreate the virtual (mirrored) switch. Then retest to validate Device Info page to Device Info page, it works.
Suspect device ("a") is called Downstairs Steps.
Note: in the log of the remote, I did find the following entry:
I'm thinking of converting all my old ST->HE devices that were originally shared with Send Hub Events to use HubConnect instead. Unfortunately, the old shared devices are being used by multiple RM and webCoRE between my 2 HE hubs.
I seem to remember there being some issue with renaming devices that are already shared out via HubConnect, but wasn't sure if it was an issue in renaming the Device Name or the Device Label...
What is the correct way of renaming my existing devices in HE, so that I can get them re-shared from ST, without breaking HubConnect? (I'll be going back to update everything with the new shared devices, I just want to append the current ones to something like "Garage Door-old")
I've tried a number of different permutations and combinations, but I just cant get the remote hub to send status to the server hub. (I've tried event socket/http, re positioning the hubs so that they are next to each other, removing then re-adding the switch, rebooting, upgrading the hubs, etc.)
Is there some sort of a switch/parameter that says "OK, start sending state changes"?
It doesn't get removed from HubConnect's Server. It needs to be deleted from the Device List on the Hub that (in your case) is running Server. More specifically: You have a 'real device' on one hub and the 'mirror' of that device on another hub. You need to delete the 'mirrored' device.
In the Device List, find "a" (Downstairs Steps) and it will have a HubConnect Switch driver. (My example will be my Christmas 2019 switch)
Click on it, and on the device page, make note of: in use by. You will need to fix up those later.
Click Remove Device.
In a new tab, Open Live logging on the server hub.
On your Remote and HubConnect Remote Client, click in until you could select the switch.. it should be selected, don't touch it, don't select anything new. You simply must drill into the menus deep enough. Click Done all the way out to the Apps list.
Verify 1) that you have a 'mirror' device once again on Server. 2) Logs show that everything got pushed across, but ONLY the missing device got created:
app:85 2020-01-13 07:11:19.557 am info Sending refresh command to HubConnect Server. app:85 2020-01-13 07:11:19.396 am trace Creating Device HubConnect Switch - Christmas2019... 192.168.7.65:44... app:85 2020-01-13 07:11:19.204 am trace HubConnect RGB Bulb Qubino RGBW Controller (192.168.7.65:1) exists... Skipping creation.. app:85 2020-01-13 07:11:18.935 am trace HubConnect Omnipurpose Sensor Walkway (192.168.7.65:43) exists... Skipping creation.. app:85 2020-01-13 07:11:18.613 am trace HubConnect Dimmer Qubino RGBW Controller Dimmer (192.168.7.65:2) exists... Skipping creation.. --- Live Log Started, waiting for events ---
Test.
My test results are: (on Server)
app:85 2020-01-13 07:16:46.576 am info Received event from Ze4th/Christmas2019: [switch, on null] app:85 2020-01-13 07:16:46.004 am info Sending on command to HubConnect Server. app:85 2020-01-13 07:16:45.353 am info Received event from Ze4th/Christmas2019: [switch, off null] app:85 2020-01-13 07:16:44.752 am info Sending off command to HubConnect Server.
Shows that on Server, something caused an OFF (me, I did that) and the Server sent that. The Remote reported back that the switch went OFF. And then same again for an ON.
I'm sure that I've done the deletion/creation of devices OK.
(And recreated devices).
However, in my logs on my server, I don't have any messages like:
Received event from...
or Sending off command...
I don't have messages like that on my server hub or my remote hub.
Is there something that I didn't do in setting up properly?
That implies that the Hub virtual device isn't 'connected' anymore.
On Server try deleting the 'mirrored' Hub device. (At the top of the Device list, click the Type column to sort by Type. Then find the devices with 'HubConnect Remote Hub' and delete them.)
Then in HubConnect Server copy the Key for your Remote, and click Done all the way out. The Remote's hub device will be back in your device list.
You can do the same on the Remote hub too.. delete the Server's hub device. In HubConnect Remote Client, paste in the key again and click done all the way out. The Server's hub device will be back.
@csteele is onto something. It appears that you’ve got a connection issue. The best bet is to clear out the key on the remote and start over with that part of the process.
I think in one of your screenshots it looked like you were using Websockets. I would also suggest that when having any sort of connection issue that you start of with http (oAuth) until you verify that the hubs are talking. You can always seamlessly change that later on.
The good news is that HubConnect 1.7 which will be released to the beta group very soon has received a major overhaul of the setup and connect process with controls in place to halt the installation until the hubs are taking. I know it won’t help you now but relief is coming soon!
SOON??
How soon? LOL 
On a more serious note, I just tested that overhaul.. it is slick. So nice. So much harder to click in the wrong order (server click vs remote click.) You must build the connection correctly and now there's no choice in how to do it so of course it's right at the end. I'll be testing more, but at least the first 2-3 tries, I have to repeat.. it's slick.
Doesn't really matter for those of us not beta testing. Until it is released to the masses, I can't get overly excited. 
I was thinking, at the time, "it won't come out of Beta til it goes in.. so.. SOON, please" But only typed one of those words. Because i just know you're listening in to what I'm thinking, right?
Like he’s (@csteele) is not already running it now. Such a drama-mamma. 
Heya Jason, do ya have that custom driver on ya by chance? Node-Red doesn't seem to be getting the correct temps from HubConnect, and I'm wondering if it's a driver issue.
It's on my github, but here is the forum post. I couldn't comment on the Node-Red side, as I don't know exactly how you are getting values from Hubitat to there. I sue Node-Red extensively, but the devil is in the details, as they say.
Sorry - I meant for a custom driver on the server side of HubConnect. I have your Enhanced GoControl on a Remote Hub, and on the Server I'm currently using the default HubConnect Thermostat driver. Is that what you're doing?
Download the Hubitat app
