I'm trying...so far, no luck. Looked easy, lol
No worries. I might have some time tomorrow to spend quality time with my laptop. I've made a number of user drivers for hubconnect, so far they all work. 
1 Like
@jrfarrar
Try this. I'm not home to test it, but should work as a user driver in HubConnect.
Switch would be the same, but with no switch level capability.
Now, off to my nephew's gradation ceremony. 
1 Like
ok and for supported attributes in hubconnect, I have:
Main: switch
2: switchLevel
3: refresh
4: motionSensor
sound good?
I made one for the GE motion switch, but I don’t have the dimmer, so can’t test. I used the HubConnect motion sensor and HubConnect switch, combined them, and it worked great! I can post the code here, but the formatting gets thrown off. I would think the same thing could be done with dimmer and motion.
exactly what I did...but I must have missed something here.... really the only addition I could see was in the "capabilities" section and renaming the driver....I wonder if I'm doing something wrong creating the "custom driver" in the hub connect server app?
I saved it as “HubConnet Motion Switch” in driver code in Hubitat. When the device was shared to my coordinator hub, I made sure it was using the correct driver and it worked great. I didn’t add any custom driver through the HubConnect menu, only Hubitat’s advanced area drivers code. I added it just like the HubConnect original drivers were done during HubConnect install, if that makes sense.
Ok, so create new driver as discussed above. Then add that in customs drivers code on SERVER. I thought it got shared to client..but maybe I'm missing adding it on client also?
Basically, the client, where the switch is paired, already has a native driver. The server, when it sees the shared switch, needs a HubConnect driver to operate it, or vice versa. Which hub is the switch paired to?
wait...I think I just figured this out. So I paired it from client to server as just a motion device (device is actually on client). So now I think I'm understanding to just go into that device on the server and change the device handler to the new one we just made??? If so, got it.
I was completely getting thrown off by the custom devices in the Server app...then I thought if I did that all correctly then I'd be able to pick my custom devices from the "custom" section when picking "select devices to syncronize" make sense?
Working, doing what I said just above... thanks all!
FYI, this should work with my homeseer motion floodlight!
Correct, use the HubConnect driver (installed in the server hub's drivers code section) and it should operate correctly. I had a similar problem that the server would only see a switch or a motion sensor, depending on the HubConnect driver I used, so I combined them and it allowed access to both features from the one combined driver. I have almost all of the HubConnect drivers installed, so I can use devices from both of my client hubs, and some of the drivers on my client hubs so that my client hubs can use devices that are actually paired to my server hub.
I'm very confused now... Just changing the driver on the receiving side shouldn't work that way? It would work for commands initiated from the repeated side, but I wouldn't expect all of the attributes to get updated on the repeated side?
Otherwise there would be no need for the user/custom driver section at all....
LOL
Server
Client
Once HubConnect went bi-directional, that terminology got clumsy. There's the Hub where the 'real' device is installed.. it gets a 'real' driver that speaks ZWave, Zigbee, or LAN after receiving Commands from the Device Info page or RM or.... whatever App. This Hub is also where you select the device to send it's events to another hub. The other Hub receives the device definition and a device info page needs to feed commands into the driver -- but the driver doesn't have a 'real device to talk to so it simply pumps the commands over to the Hub that does have the 'real' device.
The Custom Drivers portion of HubConnect Server is how new Attributes are introduced.
- 'real' devices use Hubitat or User created drivers, including virtuals. Anything that isn't a HubConnect 'stub' driver.
Terminology could almost go to sending hub and receiving hub. The sending hub has the actual device paired to it, the receiving hub uses the HubConnect driver to translate the virtual device... and this would be on a per device basis depending on which hub the device was actually connected to!
I recognize this is just greedy, but...
now that we have a mobile app that receives notifications, it would be nice to connect the mobile app to the coordinator hub and be able to send notifications from the client hubs. the presence driver is already working great, but I don’t think there is yet support for a notification device.
just throwing that out there. appreciate the hard work. this app is the lynchpin of my setup.
1 Like
I was getting confused here:
Images help. I thought after adding my custom stub driver on the SERVER that when I went on the client to "find devices" they would show up. The clearly didn't. Yes, just picking "motion" and letting the client add that device to the server...and then going in on the server and manually changing the stub driver works great. Sorry it was my confusion.
Do it.
That's exactly how mine is working.
All of my Dashboards are on 'coordinator' -- it's not even installed on any other hub.
The mobile app is dashboard, right? 
Can you set it up as a notification device set to receive texts?
