The only error I see on my end so far is on HE when updating
java.lang.NullPointerException: Cannot invoke method split() on null object on line 1397 (updated)
On the ST side when I look at the connection state it does say it's connected
The other thing I noticed on the ST app there is no way to allow it receive mode changes or SHM status like you can do with other HE hubs. You send send mode/SHM status but not receive them.
I think I had the same error, but when I did the last update to HubConnect like 3 day ago it created a phantom device in this area but not visible
I discover it clicking in to the error red box in the logs, then entering on the gear at the top and deleting the phantom device. After that no more error.
Not sure if this will help, but I hope it does
That is probably an orphaned device. There was a rash of devices becoming un-linked from HubConnect last fall. Not sure why that is, but thats the likely cause.
That fixed it !! Thanks !!
Is it possible to add the code to allow mode changes sent to SmartThings ?
Go to the server instance for SmartThings and flip on the toggle for "Push Modes". You will need to create the modes in SmartThings to match identically to what you've defined in SmartThings
The HubConnect RGBW Bulb driver has all the attributes.
As a workaround, you can select the CT bulb as a Bulb [switch, level] on the Hub with the 'real' device and then once it's 'mirrored' swap to the HubConnect RGBW Bulb on the connected Hub.
Are you using the Generic Component CT built in driver?
The list of attributes of the 'generic CT' device are included in the list of the 'HubConnect RGBW' device.
It's the Inovelli multi-white and the other is a Generic Zigbee CT Bulb (dev)
I swapped from 'generic CT' driver to "Generic Zigbee CT Bulb (dev)" and then checked the attributes:
So that would work via the workaround also.
Ok I'll give it a whack
That worked -- thanks @csteele
Edit: hope there is a real fix for this sometime soon...
I've just added 16 Motion Sensors and a Siren via the Konnected device and I'd like to share those devices back to the Primary from the Secondary hub. I've pushed them to the Primary and have installed the Konnected Motion and Siren drivers on the Primary hub but the devices won't show - any chance these could be supported, please?
Those are "real drivers" -- meaning drivers that converse with the real physical devices. Installing them on the connected hub does no good because there is no real physical device there.
The correct drivers are detailed in the Hub with the real devices:
Real devices have real drivers. Real drivers have defined Attributes, Capabilities and Commands. Those Attributes dictate where in the HubConnect Menu system a device can be selected. At the same time, the HubConnect Universal driver is dictated. On the connected hub, those drivers must exist PRIOR to the virtual ('mirrored') devices can be created.
In other words there's a cascade, a set of falling dominos, that begin with the definition of Capabilities in the physical (real) driver. Capability "Motion Sensor" cascades to a specific HubConnect driver being used for the virtual/mirrored device on the connected hub. Capability "Siren" cascades to a different, yet equally specific HubConnect driver being used for the virtual/mirrored device on the connected hub.
Question:
I have one hub (called Remote) with all my real devices.
My second hub(called Server) has all my rules and apps (RM 4, Simple Lighting, etc.)
If I ever remove Remote from Hub Connect, won't all my rules and apps suddenly break with "broken action" (or whatever it says when the device has been deleted)?
Is there any way to get around this? What about when we upgrade to a new version of Hub Connect?
You're describing different scenarios, I believe.
Upgrading HubConnect is just a swap of code, you don't delete/disconnect anything.
If you Remove the HubConnect (virtual) Hub driver, it gets recreated. In my case, I have these 4 Hubs in my Server hub's device list:
I can delete any of those and then 'pretend' to add the hub within Each HubConnect Server Instance, they get recreated when the final Done is clicked.
The same is true on each Remote where a virtual Hub device exists.
On any Remote hub, if you click Disconnect the Server Hub and Remove this Instance, you get this menu:
There's the option to delete the 'mirrored' devices or not... if you choose 'not' then they remain in the Rules and no 'broken action.' If you choose to clean all those 'mirrored' devices, then yes, you're really deleting them and 'broken action' becomes likely. Either way, using this Uninstall option does break your existing Rules on the connected hub, it's just choosing to loose the 'breadcrumbs' or not.
Excellent!
So, on a temporary basis, I can leave all those 'mirrored' devices, even though they wouldn't be attached to anything.
Great! That gives me an opportunity to remove the remote hub, keep those devices, then after some time, to 'reconnect' those devices.
Thanks again for all your hard work on a super tool!
(It works quite amazingly well - stopped all issues of slowdown, completely!)
Thank you for that, makes perfect sense and all works now.
Sometimes I spend too much time playing that the most simple of things become confusing, I need to take a break and come back to things with a clear head before posting 
Yes, they become placeholders or breadcrumbs depending on which metaphor you subscribe to 
For each 'old/placeholder' device, perhaps you'll want to go through and rename them. Thus allowing you to 'mirror' the same devices a 2nd time. Maybe an example is better...
Let's say you have 2 'real devices' in your Kitchen, on your Remote Hub. They are 'mirrored' to Server and therefore have the same name(s). Maybe KitchenLight and KitchenSink.
When you delete the Remote, the 'real devices' are ignorant of that Nothing happens to them! On the Server, the 'mirrored' (shadowed) devices can be deleted, leaving broken rules. So you choose to NOT delete the 'mirrored/shadowed' devices.
When you attempt to add the Remote again, all the mirrored devices will prevent that... not so much prevent it, but it will fail to connect.. duplicates. So.. you start by deleting (manually) the Remote's Virtual Hub device. Then, change the names of the old 'mirrored' to something recognizable... exKitchenLight and exKitchenSink, perhaps.
Now when you connect a remote to the server again, there's no duplicates and it all joins smoothly.
The penultimate step is to go through all the rules and swap 'ex' for the correct names. The final step is to delete all the "ex's" 
So just to clear up one thing.. And I apologize if I am simply misunderstanding... When you delete a remote client, the remote hub device is always removed so there won’t be any clashes with duplicates upon reinstallation.
I know that's true with v2.0, but I honestly can barely remember v1.6.4 anymore.. all those brain cells have been consumed by v2.0 elements. 
I thought I was accurately describing v1.6
Download the Hubitat app
