Google home support

changeLevel isn't required, switchLevel is, colorMode is only for RGBW devices

The driver already has capability "Switch Level" though... Anyway, I didn't write the stub driver, but I have some time tonight so will take a closer look/test.

the noted capabilities determine which attribute values we look for, and if these aren't populated the device will get rejected by our integration

First here is exactly what I added:

Second. The first bulb I added worked straight away. The second didn't...but then after setting color/hue/etc manually. The GH app took it. Both bulbs are happily in the GH app now and working to control the color/level/etc. All verified on the bulbs. Hopefully that helps in the mystery.

But if you manually populate those same fields on a device with the original stub driver without the adders it does not work / is rejected?

It gets rejected. I did exactly that yesterday. Multiple times. Then was posting on here.

Just finished importing my other bulbs. All good now. @AndyM do you think you can try and see if you get the same results?

1 Like

@jrfarrar @AndyM

Well guys, I don't know what to say... The unmodified HubConnect RGB bulb driver works fine for me with Google Home...

Here is how I tested:

  1. Created a Virtual RGB Bulb device on hub A
  2. Clicked OFF, Set Color, and Set Level on the device to ensure all state variables were present and populated.
  3. Added virtual RGB bulb to HubConnect, sending to Hub B
  4. Verified new device created on Hub B, and verified all of the same states were present on the new Hub B device (they were).
  5. Added new device to Google Home integration on Hub B.
  6. Verified Google Home did not throw an error, or reject the device. It did not,
  7. Tested control of that bulb with Google Home. Worked fine.

Since I don't have any physical RGB bulbs, I can't test any further, and I can't troubleshoot/fix something that isn't broken on my end. Good luck all.

I have seen the same thing. Until the device has all of the attributes it needs populated google home won't recognize it. So, just flipping through all of the different settings has cleared it up for me in the past. And I only have one hub so it wasn't due to Hub Connect for me.

Wow thanks for all that testing. All I can say is that I read the threads about making sure to set all the states. In fact these have been on both hubs for months. AND they WERE working and at some point stopped. Can't tell you exactly when that was. So maybe a blip somewhere? Either way thanks for all your work. Very curious to see what the results are for @AndyM

I am unable to get the Hue Bulb, after going through hubconnect, to be accepted by Google Home, even after changing all the attributes.

If you wanted to recreate the issue, I think you would need to use the RGBW virtual device, which is more like what the Hue bulbs use (not RGB). I created two:

Server Hub, RGB bulb:
image
Second Hub, RGB bulb:
image

Server Hub, RGBW bulb:
image
Second Hub, RGBW bulb:
image

Only the RGBW was rejected by GH

After changing all the values for the RGBW virtual device on the main hub, the Hubconnect side looks like this:
image
and continues to be rejected

Just a guess - probably the colormode capability is the culprit.

Like @jrfarrar I appreciate everyone looking into this. Both of us do have working solutions now, but getting the official version of HubConnect working would be nice.

Did you try adding the above capabilities to the STUB driver?

Is there even an RGBW stub driver for HubConnect?? If not, then for sure it won't work as the RGB one doesn't have the ColorMode capability, and that is needed for RGBW bulbs...

Add capability "ColorMode" like @jrfarrar mentioned, and it should work. Maybe @csteele can make an 'official' RGBW stub driver and get it in the official github set.

EDIT: I just tried it, as expected you need the capability "ColorMode" in the driver for RGBW bulbs in order for it to integrate with Google Home. May need other helper functions, too - like maybe one to create/update colorName (if that is used for anything - I'm not an RGBW bulb guy).

No, but I'm sure that would work - as you said it would, and now @JasonJoel has confirmed. But for the time being I prefer my current setup of keeping them in the light groups. It is working well for me and I don't have to remember changes I made to the code in case I ever update from github.

I'm happy to continue testing anything if it helps you though. It just sounds like your issue is resolved. Granted, if a new stub driver could be added to the official app that would be great.

I've pushed a HubConnect-RGBW-Bulb.groovy to github. I'm not convinced we need two drivers, but for now, it's there. I tested using a Hank RGBW bulb and an Aeon RGBW bulb. I don't own a Hue anything, so I can't test. Would one of you with a Hue test it, please?

1 Like

Well, we need two drivers if people want Google Home compatibility with rgbw bulbs... They don't work in Google Home with the RGB stub driver.

I guess what I'm saying is we don't need the RGB driver. Extra Attributes are just that.. extra, not used. Like a MultiSensor driver vs an OmniSensor. From this chair, the major difference is in narrowing the selector list. Who wants to scroll through every device they own to find just the Omni's? :smiley:

Either way. If you only use the rgbw driver then the RGB bulbs have a capability that doesn't apply to them.

But either way. No biggie to me as long as things work. :grin:

Thank you for doing that csteele. Should get rid of both @jrfarrar and my manual modifications.

I am going to test it tonight with Hue, but I don't think a new server/client code was posted to github - so I can't select a RGBW bulb. For the time being until a decision is made as to whether it is a new category or not, should I just rename the RGBW code RGB?

He posted a new stub driver. Along with some others. I was able to get them yesterday.

https://github.com/HubitatCommunity/HubConnect/blob/master/UniversalDrivers/HubConnect-RGBW-Bulb.groovy

Not that it really matters to me either way, but I am in this camp as well.

Some people might be confused as to whether to use the RGB or RGBW selector. Granted, the people using this code are probably smart enough to know the difference... but if I was involved in managing the code, I'd just post the one RGBW stub to avoid questions on the topic later.