Hub Mesh

So is Hub Mesh basically replacing the 3rd party app Hub Connect?

1 Like

As well as the built-in Hub Link/Link to Hub.
And appears to be much easier to setup than HubConnect.

1 Like

Adding in your ST hub might be a problem, though. :thinking:


Hublink is still there I think

They've needed this...can't wait to see it.

EDIT: BTW I love HubConnect! Been using it since it first came out. Just nice to have this functionality built in!


I don't sepak for Hubitat or the HubConnect folks, but I think both hub mesh and hubconnect will continue in parallel. HubConnect can do some things that hub mesh cannot (ST connection, connect to hubs on different networks/subnets, etc).

That said, if the only goal is to share devices between Hubitat hubs, and the hubs are on the same network/subnet, then hub mesh has an advantage in that it doesn't need custom drivers on the repeated side. And that is HUGE in my opinion.


...especially as the HubConnect folk have shunned Hubitat Package Manager (and they have such a large number of drivers so it would have made it so much easier)


If it wasn't for HubConnect I'd probably still be on SmartThings. HubConnect really took the sting out of converting over.


I think you missed an announcement...


I did - that's great news - and I think actually the package that HPM gives the most benefit for

Ahhh... I now see that was a month ago - sorry I really did miss that...


Yeah think it's more a replacement for this. Hub link and link hub had massive limitations and pitfalls.

Mesh Hub won't replace hub connect because hub connect can do it over WAN and works with ST. Mesh Hub is LAN broadcast only, but that makes it super efficient and easy for that perpose. It is also device only currently.


I have two C7s. One is currently unused but my intention is to have all devices on one hub and webcore running on the other. Currently everything is running on the one hub. If I use hub mesh would it simply be a case of backing up my webcore pistons from the current hub and restoring them in a new instance of webcore on the second hub. Would I need to remap all the devices in the pistons or would hub mesh take care of that? I initially tried with hubconnect and that did require all the devices remapping but as I used some devices that hubconnect struggled with on the driver front I gave up on it. As hub mesh doesn't require drivers I am hoping it will be easier for my use case.

Does Hub Mesh also sync modes between hubs?

1 Like

Not yet, but it is "on the list". Whether that means in the initial version or a future version I don't know. My guess is future version at this point - gotta cut off new features somewhere or 2.2.4 will never be released.


Thanks for the confirmation. I can always use a virtual switch in the mean time if I decide to abandon hubconnect once 2.2.4 is available.


Will this work across a vpn?

If the VPN does multicast routing yes. Hub mesh works on multicast traffic, so you would have to have a VPN that sends multicast. That would be very VPN specific, but as most VPNs are a separate subnet, I would say that it is unlikely that it is routing multicast (by default).

For instance OpenVPN normally runs in Layer 3 mode, so would not route any multicast traffic. That said, you can run an OpenVPN server in TAP mode (layer 2) and configure it to route multicast, but a lot of OpenVPN clients don't support that. So may/may not work.

In the end for remote facilities, if you are using a VPN and not bridging the network, then hubconnect may be a better solution.


I’m mostly guessing here, but I think you would need to remap your pistons. From what I have heard, Hub Mesh syncs devices between two hubs, it’s not truly sharing one device between the two hubs. So the device IDs on one hub mapped to devices in your webcore piston probably aren’t the same device IDs on the second hub.

But I’m not in the current beta test, and could be misunderstanding how it will work.

1 Like

I'm not a beta tester either but it is possible to change the device network ID on the HE hub. I haven't experimented with that but that would be one way of mirroring devices that would match to what the piston expects

If you change around Hubitat device IDs, wouldn’t that mess up everything else associated with that device, requiring other steps to clean up? Not sure it would make sense to do that for purposes of moving a webcore piston between hubs.

But it’s also been a few years since I used webcore too, so my memory of how it works at all is fuzzy. When it comes to creating rules/automations, my limiting factor is between the keyboard and the chair, so I’ve never had much reason to try integrating webcore with hubitat :upside_down_face:.


Download the Hubitat app