I believe Zooz Powerstrip is just 5 child devices that need to individually be selected. They will appear as 5 devices (not as children) on the other hub, where they can be individually monitored (dashboard) and controlled using a Switch universal driver. As is so often the case, I don't have one to test my opinion. 
I have my Yale Lock on a Hubitat Hub, mirrored to the Server Hub. Just now I mirrored it to ST and tested in each direction. Locking it from ST and Unlocking it from Hubitat. Worked fine.
2 Likes
My usage of the app has changed over time, plus I didn't completely understand the suggestions of which should be the server vs client in the instructions, but I now see I have my apps on the wrong hubs. My current setup has all devices going from the server to the client. The client has no devices going back to the server. So I have them backwards if I want to use the event stream.
Do you know if I just switch the apps on each hub whether it will reconnect to my already created hubconnect devices? Or will they be recreated as duplicates, and I'll need to manually change them in all my RM rules?
No problem either way, my fault - we learn as we go. But I'm just wondering if this is a half hour change or an all night adventure 
I'd suggest waiting.
I won't tease, but I think next week you might be smiling. 
You can practice smiling now if you want. 
3 Likes
Gonna grab me a mirror
3 Likes
You won't tease, but I will!
HubConnect 1.5 has a cleaner Server UI...
...and Remote Client UI
The Required Drivers are linked to Github for instant download!!
There is a new Technical Support Report option in the Utilities menu...
... this is the output of that report!
... part of it anyhow.
7 Likes
And those aren't even my favorite parts.
"Wait, there's more..." hint: You'll be putting the HubConnect Remote Hub Driver on ALL Hubitat Hubs.
5 Likes
... except SmartThings. 
corrected Thanks
1 Like
3 Likes
Very impressive improvement! Curious to ask if any improvements for the custom drivers? I would like to see all existed attributes of my custom driver devices . So far my xiaomi temp/humidity only report temperature using provided iris driver..
Custom drivers are working in the current release although there were a couple fixes that are going into 1.5.. There shouldn't be anything stopping you from creating a custom driver with all of the attributes you need and using it now.
1 Like
Is there any possible way when a Hubitat Hub is deleted, it'll automatically delete all of the HubConnect devices automatically on both Client and Server? Not sure if this is a platform thing since it works fine on Smartthings if I delete the HubConnect app for example but doesn't do that on Hubitat.
Glad to see some fixes will be for 1.5. Doing custom driver is pretty annoying and confuse in the current release (1.4), maybe more doc/help/sample for it?
I'm surprised so many people have issues with custom drivers. For MONITORING, I've found that if you are using the eventsocket connection, all attribute/event updates come over whether you want them or not / whethr they are specified in the stub driver or not - thus not needing a custom driver above and beyond the tempates already provided.
You definitely need a custom driver if you want all of the capabilities/commands on the repeated side, though. But not for events.
1 Like
There's always a way, but I have not pursued that as an option.. The reason I've not considered this to date is primarily due to the flexibility.. One can uninstall and reinstall HubConnect server or remote, and any devices shared to remote hubs will automatically re-link when they're selected again. This obviously has the potential to save a lot of hassles in updating automations or dashboards that use the virtualized devices.
Custom drivers were really meant for people with some familiarity with coding. You first have to create a stub driver then go into HubConnect and define the attributes that HubConnect will pass to that driver. I will see what can be done in a future release to make this easier.
Not my experience... If the hubs are connected via event socket all events come over for a device whether the attributes are in the stub driver or not. 
Unless I'm really remembering incorrectly and made more stub drivers than I remember? I'm not in front of the system to verify.
Commands are a different story, of course, as there has to be explicit support/capabilities in the stub driver for them to show up at all on the repeated device.
You are correct.. For performance reasons HubConnect doesn't filter attributes coming over the websocket so your method works perfectly.
I was pretty sure that is where I left it...
Although I balked as I made a 'super mega omni' stub driver at one point with basically EVERY capability HE supports (well every capability that I use/needed - not 100% of the HE supported capabilities) in one stub so I wouldn't have to mess with stub drivers any more.
Yes, with an omni stub like that you will have many commands/capabilities that don't actually work for a given device/type - which would definitely be confusing to most, which is why I never released it - but it is super easy to implement.
Then you're probably going to really like the fact that in 1.5 websockets are bi-directional now! 
1 Like
