Thanks. I've saved/published it as you suggested. Now, off to see if it "speaks".
Pretty sure this was mentioned before, but I can't find it...
I have a device I was passing from server to client that I want to remove., When I go to the device setup, I can't remove the device from the selection.
Any workaround?
What I see when I click the device type. Notice no way to remove the existing device.
All versions show up to date:
That's what I'm saying... I get no devices in the drop down when I click on it...
Not clicked on:
Clicked on:
Question: I have a Parent-Child device (s) which I would like to send to SmartThings via HubConnect.
How do I define the customer device drive for that relationship?
Generally you'd select the "real" Child device for 'mirroring' to the opposite Hub.
The Custom Driver is used on the opposite Hub and the 'parent' aspect of the 'real' device is invisible. The Hub mirrors a device.. the parent/child element is stripped away. A Custom Driver would therefore need only enumerate the child attributes.
But there are attributes(?) on the Parent that I want to "mirror" as well.
The parent is an Envisalink driver for a DSC alarm panel. So, for example, the parent has a "button" "ARM", which when pressed, "ARMS" the alarm panel. So I also want to send attributes from the Parent to the remote hub.
I have several Parent child devices. The closest matching are some RGBW strips driven by either a Qubino RGBW led controller or the very similar Fibaro ones.
The "real" device is:
and then after 'mirroring':
They appear as two individual devices with different drivers, based on how I selected them. Mike Maxwell created this driver segregating the RGB LEDs from the W LEDs. White is a dimmer only, no color control. while the RGB set is independent.
The Envisalink driver sounds similar.. are they independently selectable already?
My original answer was assuming a device like:
where only the child devices are 'mirrored':
None, other than the hub still thinks there's a device associated with that option, even when there isn't.. I'm drawing an assumption, but does the Weatherflow device actually exist?
Any errors in the logs?
Except there is a device associated with that option and the server hub is passing the values to the child hub / child device as expected.
I am trying to remove the device, but can't.
Source device on server hub:
Repeated device on client hub:
I had missed a driver for the server hub. Things are working now.
1 Like
Glad to hear you got it working. It's easy to miss a driver, or get confused about what goes where when managing multiple hubs.
No way.. it's perfectly clear. LOL 
1 Like
So you're trying to de-select the device on the server?
I no longer have a 1.6.x environment to test with, but the only thing in the code that could affect the selector/capability generation is contained within a couple lines of code.
You can try this... In the Server Instance code, around line 1595 you should see..
def capability = (device.synthetic && (settings."syn_${device.selector}" == null || settings."syn_${device.selector}" != "attribute")) ? "device." + (settings."syn_${device.selector}" == "synthetic" ? "HubConnect" : "") + device.driver.replace(" ", "") : device.capability.contains("device.") ? device.capability : "capability.${device.capability}"
Right after it add a logging statement..
log.debug "Capability is [${capability}]"
If the selector capability is not being generated correctly this will uncover it.
As soon as I click sensors (but before I click the omnipurpose sensor device list) it says:
app:4552020-03-02 07:37:23.021 pm debugCapability is [device.ShockSensor]
app:4552020-03-02 07:37:23.015 pm debugCapability is [device.OmnipurposeSensor]
app:4552020-03-02 07:37:23.009 pm debugCapability is [device.MultipurposeSensor]
app:4552020-03-02 07:37:23.005 pm debugCapability is [device.MotionSensor]
app:4552020-03-02 07:37:23.002 pm debugCapability is [device.IrisV3MotionSensor]
app:4552020-03-02 07:37:22.989 pm debugCapability is [device.GvOmniSensor]
app:4552020-03-02 07:37:22.986 pm debugCapability is [device.DomeMotionSensor]
app:4552020-03-02 07:37:22.951 pm debugCapability is [device.ContactSensor]
As the device is an omnipurpose sensor, using the in-box Virtual Omni Sensor driver, I don't think the debug log shows anything new (?).
Might be time to just scrap the whole thing and redo it. Again. 
Seems like I get it into an unrecoverable state every 3-4 months.
Anyway, don't worry about it. I just manually deleted the device, which obviously broke it/removed it from HubConnect. Good enough for now.
2 Likes
I really love it when I realize that I have shared a HubConnect device back to the originating hub 🤦🏼
3 Likes
Having a bit of an issue with my Hubconnect and Hoobs. I initially had the wrong ip in the client in HE and then corrected it. Everything is working fine, but I was bored and looking in the logs and it's still trying to connect to the wrong IP as well as the new one. Any suggestions?
Question: Regarding Lock Codes on "shadow" hub:
I have set up a simple rule to be notified upon a "Help" code being entered in the Front Door Lock. The rule fies OK on the "real" hub (remote), but doesn't fire at all on the "shadow" (Server) hub.
I think I've narrowed down the essential difference to an event which show up in the remote hub, but not the server hub. The following are the events from the status page of the remote hub:
Notice the line: LastCodeName
The following are the events from the status page of the server hub:
There is no line called: LastCodeName
Is this a problem with the HubConnect driver that it doesn't generate that line?
Is it supposed to?
Or, something else? (perhaps with the general lock driver?)
P.S. I have just discovered that there are NO lock code names ever generated from the HubConnect driver. Can you please add the capability for that?
