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.
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.
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:
On the Master hub, go to the HubConnect Server for Hubitat app.
Click Connect a Hub
At the Main Menu, Click Connect to Client Hub
Enter a Friendly Name for the hub.
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)
Choose the Type of Remote Hub:
Hubitat (LAN) - Remote hub is on the same LAN and IP subnet as the Server
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.
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.
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.
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.
So after previous oversite I started over. Deleted all apps and started from scratch. Now I don't see ability to add oauth. I must be losing my mind or something. I am sure I am doing something wrong. This is my first step. No remote Hubitats.
I got past my issue. I have one final question. When configuring the app on the HT, it says click install button on remote hub. I am unsure where to place the Oauth key in ST hub.
I have ordered a second hub with the intent of using the second hub to install the telnet version of the Envisalink/Honeywell integration. This integration is super chatty so I am going to load it on the second hub and use HubConnect.
I also have 2 Smartthings presence sensors that are also very chatty. If I load these 2 sensors on the second hub and mirror them to my main hub will they end up being chatty on both hubs?
Assuming there's differences between reports. Do you mean this device: ??
Because that device just sends a single 'check-in message" every few seconds.. I would not call that 'chatty.' However, you could use a virtual presence device as a 'filter' and just have a RM rule copy changes to the virtual presence and mirror just the virtual presence.
