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

[dcaton1220]

So why the IP addresses? Will it try those first and then fall back to the cloud?

All of my IOT things are on a separate lan/wifi from my computers and NAS. I had to put HE on the lan with the computers though, so I could access it.

I imagine things would sync a little faster if they were on the same lan, but is there a perceptible difference (I have a pretty decent internet connection)? Not sure I want to trust ST on the same lan as my NAS.

[yototogblo]

@yototogblo

So additional question on the TV integration. I also added an attribute called tvChannelName (that displays the app currently running). The issue I have is that it doesn't update in realtime. I have to hit the refresh button to get it to update. The volume also doesn't update in realtime.

In the ST app, it updates in realtime.

Please is there any way to make this update in realtime? Seems I need to subscribe to this but HE doesn't automatically subscribe? Wonder why it worked fine with inputSource but not this.

Any other thing you might suggest if not possible? I can possibly add a command in RM to run the refresh() command every 30s but don't want to put more strain on the hub.

Also, please any idea how to deal with attributes that have null values? tvChannelName is null when no app is running. I want to be able to track when there's no app running but HE overwrites the null with the previous value (which isn't useful). As a result, it appears I'd need to replace the null value with a string like "no app running". Not sure which hubconnect driver to edit to make this change.

Thanks

[csteele]

@dcaton1220

So why the IP addresses?

DNI
The mirrored devices get a DNI of the IP address+deviceID

@dcaton1220

Will it try those first and then fall back to the cloud?

Not exactly. The most common use is to mirror devices paired to the ST hub onto Hubitat. If the ST hub must physically manage the ZWave/Zigbee traffic, then you have the choice to use HubAction, which sends commands directly to the ST hub BUT the ST hub probably has to send that to ST's cloud and back. Clearly a small portion is run locally on the ST hub, and that would continue. If the ST managed device is itself a cloud device, then really, the hub isn't participating and you can power it off.

[csteele]

@yototogblo

Not sure which hubconnect driver to edit

HubConnect is like a mirror... you want to stick an Elmo sticker on your mirror to make the reflection better? Don't think it works like that, if you see my metaphor

If you want the attribute to have a value, then the "Real" driver would be updated to have a value. I don't remember Hubitat replacing nulls with a previous value, but a change in 2.2.4 involved de-duplication... and maybe nulls are being caught in that fishnet.

[yototogblo]

@csteele

If you want the attribute to have a value, then the "Real" driver would be updated to have a value. I don't remember Hubitat replacing nulls with a previous value,

Thanks... Was hoping HubConnect figured out a way to deal with it since ST has always supported null as an attribute value while HE has not (so this issue might have come up before). In my case, the TV uses a built-in driver so there's no way to edit the driver unfortunately. I have updated to 2.2.4 and it still doesn't handle nulls (simply sets the attribute to the previous value). I still don't understand why null isn't a valid attribute "value" but HE has decided.

[yototogblo]

@yototogblo

So additional question on the TV integration. I also added an attribute called tvChannelName (that displays the app currently running). The issue I have is that it doesn't update in realtime. I have to hit the refresh button to get it to update. The volume also doesn't update in realtime.

In the ST app, it updates in realtime.

Please is there any way to make this update in realtime? Seems I need to subscribe to this but HE doesn't automatically subscribe? Wonder why it worked fine with inputSource but not this.

@csteele please any idea about this? Thanks!

[yototogblo]

@csteele

If you want the attribute to have a value, then the "Real" driver would be updated to have a value. I don't remember Hubitat replacing nulls with a previous value, but a change in 2.2.4 involved de-duplication... and maybe nulls are being caught in that fishnet.

Figured it out. Had to edit the Server Instance to check for nulls in the value and replace it with string "blank". Works fine now though.

Thanks

[Sebastien]

@csteele

a change in 2.2.4 involved de-duplication

Does that mean the NodeJS Server is no longer required? Not sure if that was mentioned... I may have missed it.

[csteele]

Doesn't alter the functionality of HubConnect's NodeJS Server. My interpretation of the Platform change was to deal with duplicates related to a 'missed' ZWave ACK. The platform also got improvements to the ACK response time, so it sounds 'belt and suspenders' a bit.

HubConnect NodeJS Server will de-dup 'intentional' duplicates. (Those that the device sends out - just because.) But the larger effect is still the filtering of traffic to the specific Hub. Hub's A, B and C all send Events to Hub S. Hub S therefore sends Hub A's traffic to B & C who discard it. By inserting the NodeJS Server in the center, each Hub only sees traffic that it needs to action. It never has to de-dup and it never has to discard Events.

[Sebastien]

Ah! Good to know! Thanks!

[ApriliaEdd]

hi all
im trying to upgrade from 1.6 to 2.0 and when i paste the code for the ST app into IDE i get an error

groovy.lang.MissingMethodException: No signature of method: script_app_metadata_f52b4245_1d73_4218_84c9_0348c30c9969.metadata() is applicable for argument types: (script_app_metadata_f52b4245_1d73_4218_84c9_0348c30c9969$_run_closure1) values: [script_app_metadata_f52b4245_1d73_4218_84c9_0348c30c9969$_run_closure1@3cb58db1]<br/>Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure) @line 28 (run)

Any ideas what I've done wrong?

EDIT: Ignore me I'm clearly not reading things correctly! ive pasted the driver not the app

[BrianX]

Does the new hub mesh feature now in 2.2.4 mean that hub connect is no longer needed? I haven't updated my hub yet and have been using hub connect with great success. But if they have built that into the firmware now that sounds like a good way to go.

[samiam]

New to Hubitat and it was recommended I install HubConnect to get a feel of the interface before transferring. I have a Hubitat and ST Hub. When I got here, I don't see remote client. Did I miss installing a remote client for ST in the directions?

Connecting a Hub:

1. On the Master hub, go to the HubConnect Server for Hubitat app.
2. Click Connect a Hub
3. At the Main Menu, Click Connect to Client Hub
4. Enter a Friendly Name for the hub.
5. Enter the Private LAN IP Address of Client Hub of the remote Hub (even if the hub is not
   on the same LAN or in the same location)
6. Choose the Type of Remote Hub:
7. Hubitat (LAN) - Remote hub is on the same LAN and IP subnet as the Server

[csteele]

HubMesh is a lot more an upgrade to the old HubLink/Link2hub pair than HubConnect, in my opinion. It certainly won't help with those people using SmartThings. And, in a continuation of HubLink's pattern, there's zero user extensibility.

Thus I'd conclude that the audience for HubConnect has been narrowed, but not to zero. I am pretty sure HubMesh has removed any incentive to build a new SmartThings app. Hubitat will have to improve Send Hub Events to support the new SmartThings environment.

I saw that HubMesh got an upgrade to use tcp: "Hub Mesh: Added support added for TCP based connectivity (for mesh routers)." which I assume helps with Hubitat Hubs not on the same subnet. ++

If you need custom attributes, I think HubConnect's Custom Driver feature is the only option.

++ Apparently HubMesh is still restricted to the subnet. HubMesh in a router mesh

[csteele]

@samiam

Did I miss installing a remote client for ST in the directions?

Yes. Two blocks of code need to be installed via the IDE... an App and a Driver, both specifically for ST. Then the key needs to be copied from the HubConnect instance to the Remote.

[BrianX]

That sound reasonable. I'm only using HubConnect to share sensors for basic automations between two hubitat hubs, so I might give HubMesh a try.

[samiam]

Thanks I will go back and start over. I swear I read and re-read it to follow it to a T

[bertabcd1234]

@csteele

If you need custom attributes, I think HubConnect's Custom Driver feature is the only option

Hub Mesh takes the entire device (both capability and custom commands and attributes, plus things that app-based approaches can't really do, like all device logging and a read-only view of all preferences) to the other hub, so it would handle custom devices OK, if that's what you mean. But certainly HubConnect would let you customize things a bit more--like if there are attributes (cough, cough, power metering devices) you don't care to sync.

[csteele]

it's at the bottom of page 4, step 10+...

HubConnect%20V2%20Installation%20Instructions.pdf

[ApriliaEdd]

Has V2 stopped pushing mode changes to ST?

If not then let me rephrase: What have I done wrong to stop HubConnect pushing mode changes to ST?
not a massive issue everything mode based is in Hubitat now just curious.