[RELEASE] CoCoHue: Hue Bridge Integration (including scenes!)

So driven by changes in Hue's platform?

No, this has been going on with the V2 API since I started looking into it. (An upcoming change on my side might help, though I don't know if that's really the cause...)

I went back through the app first two pages . hit done and the messages stopped?

@bertabcd1234, quick question regarding Smart Scenes. I noticed when Smart Scenes are activated by Hubitat, the scene device turns them "off" like regular scenes. They do stay activated within the Hue App. However, when they are activated by the Bridge (via app or hue switches/buttons), they stay "on" within the Hubitat device. Is this intended behavior? I noticed the built-in acts the same way.

Probably just never thought about. :slight_smile: If this is a problem for any of your automations, you can just disable the auto-off feature (the "Automatically set switch state to off after activating scene with 'on' command" setting) for that scene. Whether this should be on by default for smart scenes, as it is for others, is maybe something to consider -- but I assume this is the reason behind the behavior you're seeing unless there's something else I'm missing.

It's all good and it does not affect any automations. My post was more to bring it to your attention than anything else since the Smart Scene behavior is slightly different compared to a regular scene. Disabling the auto-off feature does make the Smart Scene device in Hubitat act like the Hue app counterpart.

@bertabcd1234, I was wondering if you had plans to add door/window sensors to your app. I just purchased a few. I added them to the hue phone app but don't see them under any of the categories in cocohue. Thanks

If time allows some day, maybe. However, the built-in integration supports them now if you were not aware!

Thanks, I will try the built-in one but really like yours. Hope you can find time some day to add it.

I think you'll find the built-in one now looks an awful lot like CCH :wink:

Is there a simple way to transition across to the built in driver?

Originally it was suggested there was little value in doing so as there was feature parity - in fact, that CCH was slightly ahead and would continue to be as it was quicker to implement and test changes prior to baking into the built in driver.

Thanks :grinning:

Automatic migration is not possible, so a manual move is the only option. I don't think I've suggested that the built-in integration was behind since it got a significant upgrade in 2.4.0 (maybe others have postulated?), though I would have certainly said that before then. :slight_smile: Since then, it's been similar or ahead with some features, such as this.

Yes I did notice that and yes @jason12 I am having to transition every hue device over to the existing rules, but it was expected.

New issue happened yesterday, not sure if it is the integration or the device itself.
I get this:
image

Has anyone encountered this before, or have any ideas what I can do to troubleshoot?

Hue app and devices work fine.
I have power cycled the Hue Bridge.

Hue bridge shows as connected and online within HE

Did your bridge IP address change? Are you using automatic discovery in the integration app or a manually specified IP address? What is device 2528, and is it the Bridge associated with this instance of the integration app on your hub? What model of Hue Bridge do you have?

A 408 is a timeout, normally meaning that the app/driver can't reach the bridge, often either because it's offline or its IP address changed and it hasn't caught up yet -- but it could also really be any network problem. If things are working, those all seem less likely. If the problem persists, enabling all logging in this driver and the integration app and taking a look at both together may reveal more clues.

Just checked device list in router, and it looks like the IP address did change. Must have forgot to get a reserved IP.

Just changed it. Will see how it goes.

UPDATE: Pushing button on bridge and trying to re-authorize times out. Ideas?

Fixed. I had the IP address all wrong. Doh!

Hello and merry Christmas!

When migrating two hubs to a single bridge pro, is there a way to keep all of my lights or do i have to reconfigure the whole house?

Also, does the API expose the new motion sense features of the pro bridge?

I was wondering this too (though I'm using the Hubitat built in Hue integration). I tried 'motion aware' in the Hue app with a lamp and two downlights. It was very quick to react when entering the room to turn lights on but I couldn't see way to turn them back off again. It would be great if motion aware events were usable in Hubitat.

The API does expose the motion sense features of the Pro Bridge. Right now, the built in Hue app does allow them to be used as motion sensors in Hubitat. CoCoHue does not support them at this time.

It should all be the same, but I only did one bridge. My understanding is the the Hue Bridge keeps all the ids the same, so you shouldn’t need to redo the rules in Hubitat. Granted, this is based on previous restrictions of only one bridge migration allowed. I’m not sure about multiple.

In the Hue app, you need to select into each time slot. You’ll see a section titled duration. This is where you set the time before the lights do something (off, previous state, etc…).

No idea! :rofl: It largely depends on how Hue handles this migration, which I don't know. But my guess is it adds one of the Bridge's devices as new devices to an existing Bridge's configuration, which would mean you'd need to re-do at least that part of your setup (if not the whole thing, but it would be nice if it kept one in tact). If someone has tried this or has more information, I'd be curious.

One Bridge is straightforward, as mentioned above (though you'll need to re-authorize since that information doesn't get migrated).

Do you mean MotionAware? If so, yes; however, I have not had time to add this to CoCoHue yet and don't know if or when.

The built-in Hue integration has this feature (and if you are re-doing your setup, I'd consider that instead).