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

⚙️ Custom Apps and Drivers Custom Apps
,
1295

@csteele

FYI - I started getting a new error from SmartThings HubConnect, possibly since the recent SmartThings software update:

12:09:28 PM: error org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorized SQLException for SQL [select this_.id as id108_0_, this_.version as version108_0_, this_.date_created as date3_108_0_, this_.`key` as key4_108_0_, this_.type as type108_0_, this_.value as value108_0_ from server_config this_ where this_.`key`=?]; SQL state [null]; error code [0]; [SimpleAsyncTaskExecutor-3] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:0; idle:0; lastwait:30000].; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [SimpleAsyncTaskExecutor-3] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:0; idle:0; lastwait:30000]. @line 742 (sendGetCommand)

Also, would you mind adding the ability to specify the name (label) for the HubConnect Remote Client app? I'm using 1 SmartThings and 3 Hubitat hubs in my home, and thus several of the hubs are remote clients to more than one HubConnect Server - I'd like to name the instances to indicate which hub it is the slave to...

Thanks!

1296

Because:

  • the repo where the "Latest" is stored is a file owned by @srwhite -- I don't have access to update the number.

  • Four digit 'build' number means it's a hot fix.

1297

I'm pretty sure I don't understand this one. :frowning: I mean I know about naming an App but the need escapes me. It seems tied to:

Why is there more than one server instance? HubConnect is not HubLink/Link to Hub where you have to build the bidirectionality manually.

48%20AM
48%20AM715×166 23.3 KB

I think I have a similar number and type of system. 1 SmartThings and 4 Hubitat. I have Server on one Hubitat Hub and one Remote Client per each remaining hub. There's no significant coding difference between "Server Instance" and "Remote Client." Both implement a bidirectional ability.

1298

Thanks, I thought maybe I had the server or something outdated.

1 Like
1299

I actually have the same circumstance as the original poster: my "main" setup has one "coordinator" hub with two remote hubs (a ZHA Hubitat hub plus ST), but I also have a third hub that does Zigbee bubls only, and I didn't want to route that one through my "coordinator" hub since that's the one where I relegate Z-Wave, risky code, and anything I'm not quite sure about--and my lights can't be one of those. I wanted them to go directly to the ZHA hub. Thus, my ZHA hub is both a remote client for my "coordinator" hub but also a remote client for my ZLL hub, which runs the server (I could do this the other way around but didn't see a reason to prefer one way or the other).

Adding a "label" field to the app would help distinguish the remote clients since they otherwise show up with the same name--it's the same thing the Server Instance app allows so you can distinguish (except those are child apps and this isn't, but same idea and field--just a label input).

Obviously a fringe case, but just thought I'd throw my use case out there since I'm apparently not the only one. :slight_smile:

1300

Is Steve (@srwhite) ever coming back / planning to update things? Or is this a dead product? We can't update it on the community side due to the licensing restrictions on the apps, so I think this is a reasonable question.

For the record I'm not trying to complain about the licensing model, or start a licensing discussion/argument of any kind. Just asking about the future of the apps - nothing more.

1301

Have you seen his Logo??

58%20AM

As far as I know... that's where he is :smiley: Before he left for the 'season', he mentioned an idea or two about v1.5 -- so yes, he had a plan :slight_smile:

1 Like
1302

I didn't notice that. Good for him!!! :+1:

1303

Like this:
43%20AM

to this?:

40%20AM
40%20AM717×46 4.08 KB

1304

Looks like it! I swear that wasn't there last time I checked, so if you just added it, thanks!

1305

it isn't there in your version :smiley:

[evil laugh] :smiley:

Was pretty disconcerting... I've gone, what... a whole year and that Remote Client has always been at a certain place on my screen.. in the H's.

I changed it's name to match what I use on the Server and IT'S GONE... oh, wait, it's down the bottom with the Z's. :frowning:

1 Like
1306

Exactly what I was looking for, although I suggest changing the names to start with "Hub" :slight_smile:

And before I go any further, allow me to say that I totally appreciate what HubConnect is today - as you'll see below, I couldn't run my environment without it.

As to the question: Why do I need multiple Server hubs and hubs that are Clients to more than one Server?

Simple Answer

The simple answer is that I have over 500 total devices in my home - a number that neither SmartThings nor Hubitat is designed to handle efficiently on a single hub.

As a result, I prefer to avoid the hub-and-spoke design you have deployed in your own environment because it creates a single point of failure - if the "Server" hub goes down for any reason, none of the Client hubs can coordinate or exchange events with each other. Plus, there is no need for the "Server" to see every event from every single device in my home, nor should I waste the limited resources of a Hubitat hub repeating events when I could send them directly instead.

Longer answer:

Hubitat hubs do not perform well under heavy loads - if the CPU is being taxed for any reason, Z-Wave and Zigbee events will be (often silently) dropped or lost. In my environment, I run several such "heavy CPU" apps, and so I have distributed them across my hubs so that no single hub is running all of them (which is how I started and how I found the CPU limitations of Hubitat). Now, several of these apps do need to know about SOME of the Zigbee/Z-Wave/Cloud devices that are managed by other hubs, but none of the hubs needs to know about ALL of the devices (even the Hub running the Alexa Skill only needs to know about on/off devices, and in my environment it doesn't need to know about any of the sensor-only devices). I have thus moved the heaviest CPU load apps back to SmartThings (which runs them 5-10 times faster than a local Hubitat hub does), and the ST apps need to see events/state from a variety of devices on each of my 3 Hubitat hubs). And since SmartThings can't be the "Server" in HubConnect, my only choice is to have it be the "Client" to each of the 3 other Hubitat Servers. SImilarly, if Hubitat 1 needs to see events on Hubitat 3, I prefer to link the two directly, rather than force events to go from 3 to 2 to 1.

Related, each of my hubs (both HE and ST) reflect devices to my Apple Home/HomeKit environment via independent HomeBridge instances - both to minimize unnecessary multi-hop event repeats, but more importantly to get around the 100-device limitations of Apple Home accessory hubs (i.e., HomeBridge). Where I have reason to have a HubConnect Server on the hub, I use the HomeBridge support, otherwise I use the Maker API link (or the ST HomeBridge support). Again, trying to minimize traffic that is repeated, network overhead, and CPU load on the hubs.

BTW, acknowledging that I may be using HubConnect in a way that you didn't intend, I note that there are several error conditions that arise as a result. For example, if I configure devices to go from "Server" hub 1 to "Client" hub 3, but don't configure any devices from "Client" hub 3 to "Server" hub 1, both the hubb 1 Server Instance and the hub 3 Client will throw errors in Live Logging. Often, this can result in circular deadlock issues that saturate the CPU of 1 or more hubs, again causing lost ZigBee/Z-Wave and/or Cloud events.

1307

Short Response:
Thanks!

Longer Response:
I'll have to read the long answer another 3-4 time to glean the nuances. :smiley:

However, I'll mention that in my spoke-and-hub implementation, my Server has no Radios on/enabled and thus my 4th (development) can be swapped in as Server in just a couple of minutes, should the Server die. When using HubConnect via Event Socket, there's zero additional load on the Hubs. All the work is already occurring via Event Socket. The listening Hub has a very small task to confirm a message in the the Event Socket is for itself and to 'parrot' it as an Event.

My development Hub is outputting Event Socket data at all times, and no one/ nothing is listening.

For the time being, I'm seeing the Hubs handling the 'parrot' task (listener) with no detectable impact. Like you, I don't have all 'sensors' in a Listener. However, as is clear, they are sending via Event Socket. :slight_smile:

1308

Sorry, but I am about to ask a very big NOOB question. I got my HE about two weeks ago. I am still planning my migration from ST and am trying to learn HubConnect as I think it will solve some of my challenges with my nearly 200 devices.

So, I am trying to understand how Hub Connect works. The documentation I have read thus far is less than clear. I have tried to read most of the nearly 1300 posts in this thread and am still a bit stumped. So my primary question is this... If my understanding is correct, do i need to use the HubConnect skeleton drivers on both the server device and the remote device? I mean, I have numerous devices which use custom device handlers/drivers that I want to move to the Hubitat Server device where there are ported Drivers from ST. The functionality I use depends on these custom drivers (i.e. I use GE/Jasco Switch drivers which support double tap). I just don't understand how to use Hubconnect to create a virtual device on Smartthings which will support these device drivers on Hubitat. Do I need to use the HubConnect drivers on both the server and the remote? Nothing I have found makes this clear to me.

Sorry for the NOOB question. I am normally not this thick but assistance would be appreciated. How do i set up devices on both sides which allow for supporting the drivers I need. What am i not understanding? Do I need to use custom driver capability of HubConnect or is the answer even more basic? Can't seem to get started and get any of this working in Hubconnect.

LJ

LJ

1309

I like you didn't understand this clearly and actually originally when I first went this route installed all the hubconnect drivers on both hubs (server and remote), that is not needed they only go on the server hub. You use the stock and/or custom device drivers on the remote hubs.

1310

That doesn't make sense to me. I would think the server hub should be the home of the full functionality since the actual device will be running on that device. I would think that the remote would only have the skeleton since it only needs to remotely control the device on the server. Am I still not understanding? Why would the remote have the the full function custom driver?

LJ

1311

The HubCoonnect drivers are intended to provide (generally) all functionality possible, sometimes a function doesn't work correctly and when this occurs tag @csteele and on his good days :laughing: he usually will be accommodating to try to make it happen like the RGBW driver a few posts up. The way the server hub knows what functionality is available from the device being linked is by how the devices driver is coded from the remote hub. So your custom or stock driver is what opens up that function to be recognized by hubconnects driver.

1312

Maybe I should be more clear about what I think I am trying to accomplish. I am spending a lot of time trying to plan my migration to limit the obvious impacts to certain functionality so my Significant Other/Girlfriend doesn't get frustrated more than she is about the the learning curve and about things not working the way they have until now. Acceptance and adoption of all my automation has been a challenge and things were going smoothly on Smartthings for the last few months and she was starting to get comfortable with the ActionTiles panel on her side of the bed and all the other voice controlled and automations available to her.

When thinking about the migration, one of my first goals was to minimize the impacts to her as much as possible until I have to switch her to the HE dashboards instead of actiontiles.

I was considering HubConnect because I thought i could do the following: Migrate devices room by room, setting up the new devices on HE and using HubConnect to set up virtual devices on ST of the same name to keep my ActionTiles and Webcore pistons running without interruption while the actual devices were being run by the HE Server. This would allow me to work on the migration of Webcore pistons to Rule Machine and other HE standards, and build dashboards for these devices that resemble what she is used to, before actually repointing the panels to HE dashboards. Also I need time to reprogram my Alexa devices and groups so the voice commands work. i can't really do these things until I get the actual devices over on HE.

I hope that makes my goal more clear. Any more suggestions are welcome.

LJ

1 Like
1313

Simple rules.. at least for my brain...

The Hub with Real devices use Real Drivers.

The other Hub gets the stub/Universal Drivers.. or mirrored devices use universal drivers, said a third way, virtual devices use universal drivers.

The concept of "Server" vs "Remote" does NOT enter in to those Rules. A real device is on some hub... probably working.. don't touch it. On the other hub, make sure the universal driver is available. It will automagically be used if it's there at the time of the mirroring.

You will migrate a device from ST to HE, and then confirm it works using HE's Device Info page. Then select the new device in HubConnect on HE. When you click all the Done's, Hubconnect will try to create a MATCHING named device on ST using the universal driver.. it needs to be there before all the Done's are clicked.

You need to think about naming and how to manage the migration. If you take a device off ST, using HE's Exclude, ST will not know about the loss. The device will remain known to ST, but obviously non-functional. Perhaps you want to rename that ST device to be a placeholder so that what you add to HE is using the same old familiar name. When HubConnect mirrors it will create the device name on ST the same as HE. Then it's a matter of going into WebCoRE and reselecting the original name. Then you can delete the placeholder.

1314

I see your point, but my complicating factor is that I can't have a central "Server" hub reflecting all of the "Client" hub's events to HomeBridge, given the HomeKit limits on the number of devices that a single appliance hub can reflect (100). So, I need some sort of server application (e.g., Maker or HubConnect) on each hub that reflects (local) device change events to HomeKit via HomeBridge.

And though you insist the overhead of sending every event to a single HubConnect Server via Event Socket is minimal, I have observed that a single Hubitat hub simply cannot handle the overhead of 500+ devices, even if the events AREN'T being reflected to other hubs - even with both debug and info logging disabled (which is unrealistic in my environment - I need to keep some logging going so that I can figure out what's going wrong when things don't work properly).

If Hubitat were faster, and able to gracefully handle heavy CPU loads without losing events, then maybe - but this isn't the case with the current Hubitat hardware/software combination. And since the computational overhead of several of my cloud-based devices is so high on Hubitat, I really have no choice but to run them on SmartThings, where the benefits of Event Sockets doesn't apply.

Net-net, this leads me to run a HubConnect Server on each of my Hubitats, and to have a separate Remote Client on my SmartThings hub for each of my Hubitat hubs, where the overhead of the ST HTTP connection logic get distributed across all the hubs, instead of being concentrated on a single HubConnect server.

All that said, you've addressed my request for being able to specify the label for each Remote Client instance, so I'm good for now. I will try to capture/debug/isolate the issues that I am seeing with no devices being reflected in each direction. And the errors on the ST thing are new - hopefully I can get more information so that the issue(s) can be resolved - clearly the SQL errors aren't being directly caused by HubConnect, more likely some recent change on the SmartThings side is causing this new error as some side-effect...

Thanks again for all you have done with HubConnect...

1 Like