[RELEASE] HubConnect - Share Devices across Multiple Hubs (no longer SmartThings!)

⚙️ Custom Apps and Drivers Custom Apps
,
2652

Not me. :smiley: :smiley: I only have 4 Hubitat hubs in my Production system:

18%20PM

(Homebridge and ST won't go through the NodeJS server in this iteration, if ever.)

I'm not sure "speed" is a measurable criteria...

The point of the NodeJS server is to reduce the number of packets that need to be discarded... it does the discarding instead of the hub. That increases 'available CPU' to anything else the hub needs or wants to do. Which might be nothing. For small'ish (small relative to using multiple hubs :smiley: ) systems, the 'cost' of discarding may not cause any other action to be delayed.

Let's imagine you have 20 devices on one hub, you mirror 15 of them to the server and it's got 20 additional devices mirrored from hub #3. In that scenario, hub #1 is going to be receiving 20 devices worth of event socket packets it must discard. 20 is nothing :smiley: easy for the hub. At some point however, 60?? 120? the simple act of receiving the packet will delay something else. If that's a Z-device packet, then perception of delay might occur. It's all relative to the CPU available at the moment. The Hub has a LOT of CPU, but for any given millisecond, all cores might be busy. By offloading those packets, CPU isn't being consumed in a 'do nothing' exercise.

2653

There is no built-in mechanism, but tools are provided such that you could build something in RM...

There's a "Toggle Socket" command in the Remote Hub driver. This is used to switch between proxy/websocket. There are attributes available for websocket status so when it shows a "disconnected" state for a period of time, you can have a rule to run that command which will switch over to the websocket method.

I've never had the server fail in my testing.. But that's only in my environment. I'm sure there will be other failure scenarios that I've not envisioned yet.

2654

Me either BUT using a Mac Mini, I've got LaunchCtl to keep the server running.

2655

Attention Beta Team... Thank you for the bug reports. I've released a hotfix (4b1) to address all issues that have been reported so far. It's a pretty easy job to update. Re-import the Server Instance code, and the Hubitat Remote Hub driver.

Please open a ticket with any new issues.

2656

Question about local http (HubAction) support on SmartThings in V2...

To enable this feature, do I need to do a disconnect and then re-connect the SmartThings hub?

I added the new SmartThings HubConnect Remote Client device handler in the IDE and opened up the App on my Server Hub. Don't see any settings to change it... :slight_smile:

Thought I'd try it out...

2657

More or less, yes. Part of the changes in v2 is a more error free connectivity workflow. While it makes it simpler to get it right, it insists you start at the beginning. (In other words, there's a couple more clicks.) It doesn't affect the device selection side though.

I wrote it elsewhere, but if the connections between hubs is a 'highway' the attribute data of selected devices are the 'cars.' In this case, repainting the lane markings on the highway, doesn't affect the cars. (Yea, and the maintenance window of closing lanes to do the painting is equivalent to the key exchange time for hubs. :smiley: )

The connection criteria is still selected in the Server Instance on your Primary hub. The Key also contains details the Remote needs for it's side of the connection.

2658

I have devices shared from both my secondary Hubitat hub and the SmartThings hub that are then shared with the HousePannel app... If I have to reset those connections, I might think twice about it... But if its not gong to affect those devices, I'd try it...

Was this the thing mentioned earlier in this thread about rec-connecting the hubs without changing the keys?

2659

Resetting the connections between Hubitat and SmartThings does not affect any of the shared devices. Just the connection settings. You're safe.

1 Like
2660

Attention beta testers...

The HubConnect Proxy Server has been released! Please re-import both the Server Instance and Remote Hub Driver (Hubitat) code before proceeding with the installation of the Node proxy.

Instructions are in the knowledgebase.

Please open a support ticket to report any issues that you encounter.

Enjoy!

1 Like
2661

I deleted the remote hub devices on the secondary hubitat, SmartThings and the server, then went through the part where I pretended to add the key, leaving it alone... It rebuilt the devices and all my connections are there, but still didn't see any new options for communication... I'm still missing something that is probably staring me in the face...

1 Like
2662

Can you enter a Ticket into the Beta system, so we can keep this thread relevant to the v1.6 users.?? Maybe there's someone attempting to be helpful, scouring their 1.6 app looking for that. :slight_smile: Won't find it :slight_smile:

2663

Will do... Sorry

2664

not a problem.. I 'tease' the features too.. but you're about to go down a Problem Solve path, which, when successful will result in a Fix to the code.. and no one else will ever see it again. That's what Beta is supposed to be, anyway. :smiley:

1 Like
2665

Totally understand and you are absolutely right... :smile: Ticket submitted...

2666

@csteele I think this is the proper thread to ask these questions. My set up is a Hubitat hub set up as a HubConnect server with all cloud based apps and devices and the Zigbee and Z-Wave radios turned off. It also handles all apps and rules. For client hubs I have another Hubitat hub that has all of my Z-Wave and Zigbee devices paired to it and no apps or rules. This hub is for the house and there are about 200 devices paired to it. The other client hub is a SmartThings hub and it is in my shop but on the same network. I have Ethernet cable run to the shop. It has currently 25 devices on it but I will probably trade it out for another Hubitat hub to make it all local. All running on HubConnect 2.0.

I also just happen to have a Raspberry Pi running the latest Buster that is sitting on my network that is currently doing nothing. Would my setup benefit from using it as a HubConnect Node.JS server? I worry about having too many points of failure that would shut things down. I love the fact that I can backup and restore the HE hubs and get them back up and running in minutes if I screw something up when tinkering with the system. I would like to give a Node.JS sever a shot if it makes sense to use the Pi in the mix. If it would not offer any benefit, I would forgo it.

2667

In the welcome e-mail and instructions, I asked that all v2 beta participants communicate issues with tickets (preferably) or PM as to keep this thread free of confusion for the vast majority of HubConnect users who are using 1.6 (or older).

General questions/comments are always welcome here, but I do kindly ask that all v2-specific discussions be taken out of this thread. :slight_smile:

That's a valid concern, and one that I share. I've found that I need to reboot the hubs far more often than I have to reboot my Mac server. As long as your Pi is stable you shouldn't have any issues. HubConnect Server does not write to disk, so wear and tear on an SD card shouldn't be an issue. It literaly just receives and parses textual messages.

1 Like
2668

200 devices sending everything they know or do to your Apps and Rules. There's duplication in that stream, but probably not a lot of 'devices-to-be-ignored' (filtered). Minimum benefit, as I see it.

When you swap the ST hub for Hubitat, you will probably choose to use Event Socket.. this is where the NodeJS Server helps. That hub is going to receive Everything Rules and Apps related. A lot of it will be specific to the 200 devices it has no interest in. Filtering out those 200 will help. De-duplicating helps too.

As v2.0 gets closer to Release, I imagine people are wondering specifics about where the benefits are to be found for them individually. I have a NodeJS Homebridge connection. It uses the same computer. In my case a Mac Mini (primary use as a Media Server) that is always on, has TimeMachine backup, etc. It was pretty easy to 'insert' the NodeJS HubConnect Server. I don't think I would have taken the time to over think it, because for me, it's completely free. I don't really distinguish between saving 2% or 80%. But maybe that's just me. :smiley:

2 Likes
2669

Newby and proud supporter to the project - I think the application is a brilliant idea but I am having some growing pains.
I have read through as many of the >2k comments as I could, and I am currently running 2 hubs. I moved all the applications off of one and over to the other (now the server), and that seemed pretty straight forward (by move I mean recreated them after I shared the devices to it).

However, here is where the questions start:

  1. I am not certain why, when you select a device, that is appears in multiple categories? I have deduced that if it is a dimmer, I should only select it in the dimmer section, and not every place I see it - is this correct?

  2. I have a ZooZ double-plug. It registers as a master, then the left/ right outlet on the plug. These items appear in the "Energy Meter" section, so I select them there. For example, one is called the "Kitchen Desk Lamp". When I go to the list of devices on the SERVER I see it there, yet when I try to build a rule to control it, it is not there? As a sanity check, it does appear on the slave device in rule machine just fine. What am I missing here?

  3. If I need to make a change to a unit's name, and I enable all the checkboxes between the two devices (Push Mode, and HSM changes), where does this need to occur? I cannot seem to get a good feel for this. Do I update only on the device that actually holds the units, or the server that they are sent to. Seems that it could be either, but when I do this, and then go into a rule, the ability to edit the devices is now broken and I have to recreate it from scratch. Again, I am sure I am missing something but don't know what.

  4. I see that the Server is again reporting that the slave is "Paused" and orange. I don't know where or why this occurs and can only assume that they aren't talking so nothing can happen - please advise.

  5. Last one for now... It would be great if the tutorial had selectable text for the github url's. At least in Chrome, I cannot select that text and had to type them all out - good practice, but lengthy. Also, the drivers URL would not work (the bottom one that installs all the extra dimmer drivers and such). I had to do them all manually via cut/ paste. This is more an FYI.

Thanks in advance and today a third hub is arriving that I believe I need as I cannot get good coverage in my house even with range extenders from the current slave hub. I am presuming this new one would be slave #2 and I would only install devices on it and the Server will always only ever handle the apps?

Thanks,
Charlie-

1 Like
2670

Every device driver identifies it's Capabilities... a ST and Hubitat 'grouping' of related functionality. Take one of the simplest: "capability switch" -- it automatically relates to an Attribute of switch and Commands of On and Off. It's up to the developer of the device driver to choose the most ideal Capabilities.. there often are more than one. In many ways, Capability is shorthand for the underlying Attributes and Commands.

HubConnect, when using http (oAuth) must subscribe to each attribute to "see" the event and thus send the event to the paired hub. That means selecting a device from the Group Selector that most closely matches Attributes, real to virtual. Any mismatch would then use the Custom Driver option of HubConnect.

For Event Socket connections, all attributes of all devices are inside the Event Socket and Selecting of devices mostly identifies the filtering needed. As an example, 40 devices on Hub A sending 3 of them to the Server.. the Server will "hear" all 40, but use the Selection to filter down to just the 3. And since it 'hears' all attributes, HubConnect will update any that are in the HubConnect Universal driver in sync. Again, attributes that exceed the list within a HubConnect Universal Driver, would fall to Custom Driver.

My advice on this point is: During Selection, assume http (oAuth) because any problem solving can easily become "Switch from EventSocket to Http and... " and you'd want everything to continue to work.

For 'real' devices that are Parent Child, Select only the Child devices to 'mirror' to another Hub, using "best match" as I outlined above.

HubConnect doesn't USE the names of devices. It copies them at the time of creation, and displays them for selection, but if you manually change a name on one hub, HubConnect will not notice and won't fix the name. It's an entirely manual process... change the "real name" (nothing happens, it all continues to work, because the traffic is tied to the DNI, not name,) and then on each Hub that has a copy of that device, manually change it too.

"Paused" indicates the Switch inside the HubConnect Hub Device is in the Off position.

Have you used:
https://hubconnect.hubitatcommunity.com

On there is an "Import" link, which displays a sorted list of github URLs.

1 Like
2671

For your architecture/design, yes, it's a valid option. It is not required though. :slight_smile:

You can on the new hub 'bundle' devices + automations. Each architecture has advantages and disadvantages. When either are running well, I'd expect to see very little perceptible difference, which is entirely due to superior LAN speeds.

My point is, you can try the 'bundle' architecture/design on the new hub without any effect on the existing pair. (Obviously if you're splitting devices.. removing them from one hub, adding to the new... there's disruption in that act alone.)

1 Like