Agree,
HubConnect was created under the initial "mental image" of that drawing I created.. three hubs, two with radios, one 'coordinator.' Surprise, surprise it's grown.
I was originally doing that, but I was having issues with HSM not working correct early on, so I have my coordinator as the main hub, and a second hub that is handling my annoying OSRAM lights (cheaper to add second hub than replace all the lights) and I have some other devices running with it for motion lighting, and the third is for development and those apps that I don't have total faith in yet. The HubConnect app is by far the best I have used... it works and works well. I also love the homebridge connection in it, the option to use Homekit is awesome! I did find a super easy way to get homebridge up and running on a pi - hoobs.org
I have not installed the mobile App.. I may never, but certainly there is a hint that If I want to help out.. I'll need to. Like Modes and HSM, I have no desire to use it, but being familiar, in order to help out.. ok, I can see that..
I have Dashboards on my iPhone and iPads, I have notification via Pushover, and Presence via Homebridge.... just like so many of us for the past year 
It all works so well, I have no incentive to change.
So far though, I can't help with that Mobile App and notifications, but I can't see how it would work any differently.
streamlining and reducing the number of companies I rely on appeals to me.
I have the pushover devices installed on all my hubs, but the mobile app only allows connecting to a single hub. so right now I can send notifications to pushover from any hub. I can only send notifications to the mobile app from my coordinator hub.
I can see that my first task will be to get all Pushover decisions onto 'coordinator' - maybe the entire Rule moves, maybe parallel Rules, maybe a virtual something. Centralize Pushover onto 'coordinator' -- I don't see that as hard. Lots of clicks, yes, my finger might get tired, but not hard 
Edit: I looked and I have 5 rules to move... that are using Pushover on my radio hub. (only one of two) Might only be 15 mins of clicking.
@csteele, I had a fan ( GE Smart Fan Control ) on Client Hub. When I synchronize to Server hub, I had a device ( HubConnect Fan Controller ). It's working good, but when I add this device to Google Home app, it isn't compatible with Google Home ! ? When I change the fan to Generic Dimmers ( HE Client ) , HubConnect Dimmer ( HE Server ), then I can add this fan like a dimmer to Google Home app. Did I miss something here ?
Thanks.
Nope. You got it right.
1 Like
I have another request.
I have an electric valve (really a NC solenoid) connected to a z-wave outlet that controls my drip irrigation setup in my garden. I’d love to be able to select it as a valve instead of a switch when connecting to homebridge. I’m hoping that would give me a water spigot icon instead of a switch icon? me want spigot icon!
thoughts?
Trying to sync lights to google home that are on the SERVER (being pushed from a client) and get this error in google home.
The following devices are not supported by Google Home and will be removed from your device list:[Bathroom Lights MBTH....
Thoughts? The original drivers are a GE switch, Sylvania RGB lightstrip, Generic RGB bulbs.
I don't have Google Home (except as a TTS speaker) and can't answer directly. I do have Amazon Echo and I looked at my RGBW lights and found they were 'switches'. I changed them to be Lights in the Echo app.
I'm assuming this has to do with the stub driver as I think that's what google home uses to determine if it's compatible.
point taken. i've moved my rules. all is well.
1 Like
I moved mine too.. still using Pushover, but at least it's ready for the Mobile App 
Getting this error trying to set RGB color on bulbs USING the color dialog box in the driver. Setting the individual HSL values works along with temperature.
groovy.lang.MissingMethodException: No signature of method: java.lang.String.call() is applicable for argument types: (java.lang.String, java.lang.String, java.util.LinkedHashMap) values: [192.168.13.46:814, setColor, [hue:94, saturation:85, level:94]]
Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
This is using the latest HubConnect RGB Bulb driver.
Otherwise I've worked out most of the bugs of this two hub setup.
A few more custom drivers I might need some help with
I'll need more info I guess, I'm not seeing the error:
on my 'server' using the HubConnect RGB Bulb driver, logs show:
app:33 2019-05-27 07:29:27.464 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [switch: on null] app:65 2019-05-27 07:29:27.462 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [switch: on null] app:3 2019-05-27 07:29:27.430 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [switch, on null] app:3 2019-05-27 07:29:26.977 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [colorName, Orange Red null] app:65 2019-05-27 07:29:26.959 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [RGB: [255, 77, 0] null] app:33 2019-05-27 07:29:26.882 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [RGB: [255, 77, 0] null] app:33 2019-05-27 07:29:26.845 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [color: #ff4d00 null] app:65 2019-05-27 07:29:26.816 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [color: #ff4d00 null] app:3 2019-05-27 07:29:26.798 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [RGB, [255, 77, 0] null] app:65 2019-05-27 07:29:26.735 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [saturation: 100 null] app:3 2019-05-27 07:29:26.733 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [color, #ff4d00 null] app:33 2019-05-27 07:29:26.729 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [saturation: 100 null] app:3 2019-05-27 07:29:26.669 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [saturation, 100 null] app:33 2019-05-27 07:29:26.656 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [hue: 5 null] app:65 2019-05-27 07:29:26.650 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [hue: 5 null] app:3 2019-05-27 07:29:26.605 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [hue, 5 null]
On the hub with the physical device, using the native Hank RGBW LED Bulb driver, logs show:
dev:582 2019-05-27 07:29:27.393 am info Hank RGBW LED Bulb switch is on dev:582 2019-05-27 07:29:26.839 am info Hank RGBW LED Bulb colorName is Orange Red dev:582 2019-05-27 07:29:26.836 am info Hank RGBW LED Bulb RGB is [255, 77, 0] dev:582 2019-05-27 07:29:26.829 am info Hank RGBW LED Bulb color is #ff4d00 dev:582 2019-05-27 07:29:26.826 am info Hank RGBW LED Bulb saturation is 100 dev:582 2019-05-27 07:29:26.786 am info Hank RGBW LED Bulb hue is 5
I clicked to get the color picker, picked a color and then clicked SetColor. The Hank driver seems to send "everything" according to the logs. Perhaps the driver you are using with the 'real/physical' device isn't?
I know you're seeing the error, this message is saying: I can't duplicate 
that error was on the server and the client device driver for that bulb (Sengled) is "Generic ZigBee RGBW light modified" and the other bulbs are "AEON LED Bulb" I need to test with scenes to see if it really matters. I'll do that soon.
Also, one more small problem.. I've had my client hub lockup now twice. I have a LOT of things disabled on it...so I don't know if that causes a problem and I should just delete stuff but my first thought was just to disable in case I run into a problem. However all that's left on that hub is my zwave and zigbee devices along with Hubconnect remote client. The only other apps in total are: Mode Manager (I think I might be able to disable this), Other Hub event pusher (for my ST hub, haven't put hubconnect on it yet), and Rule Machine.
This used to be my main hub and the new one is now my "server" or "controller". The controller hub has not locked up and I have not had any issues with it. The only thing really left to do is disable hubconnect, but then really pretty much the whole house won't function. I haven't looked deeply into the logs to see what's going on yet. Was away today and came home to it locked up. This was the 2nd time.
I have 5 "Hubs" -- One Hubitat Hub is 'server/coordinator' Two more are my radio enabled hubs, one upstairs, one down. Outside of that is a Homebridge "Hub" (running on a Mac Mini) and of course SmartThings Hub. SmartThings is not doing anything but sitting there waiting for me to test something. It has nothing to do with my day-to-day, but every few days I poke a button just to make sure it's all alive. 
So far, I've never had a crash. I think we've had 3 HotFixes in 2 days and I've installed them... therefore I have very small uptimes. Is it a factor? No way to tell but I'm certainly able to see how it could be.
My two 'radio enabled' hubs have very few Apps.
Not shown on both is Zwave Poller. ABC is the button (pico) controller.
'coordinator' is certainly doing what I intended with more apps... and just yesterday I removed pushover from both radio hubs, it's only on 'coordinator now'
As for user built drivers...
12 on the downstairs radio hub:
and 5 on the upstairs radio hub:
I don't think I'm significantly different from your config.. with one exception and that's Other Hub. I am pretty sure I've never used that.
@dan.t and @csteele
are valves supported for homebridge? I can select it, but I can’t seem to get it to pop up. I haven’t seen anything strange in the logs on hubitat or my server. and after I select a valve in the list, hubconnect does NOT suggest that my homebridge hub needs a driver for a valve - it suggests that it needs drivers for everything else though.
HubConnect does have a Valve stub driver.
Dan's RELEASE message for New Homebridge Plug-in via MakerAPI and Eventsocket has a table, (Attribute Filtering) in which valve equates to Valve.
I know, which is why I thought it was weird that it wasn’t listed in the recommended drivers. I wasn’t sure if the two homebridge apps were fully at parity yet.
