I intentionally nuked my 1.x setup and did a fresh install of 2.0. It was a breeze using Hubitat Package Manager. The only issue I noticed was that when I first tried manually entering the bridge's IP address, I could only get the first two or three digits inputted before the page updated. That being said, auto-discovery worked great and all devices, groups, and scenes imported without an issue. Great job, Robert!
Thanks! I have an idea as to what might be going on with that manual entry issue.
EDIT: As someone here often says, found and fixed. Will be in next release. (In the meantime, you've got about 5 seconds to type or paste it before it reloads and vanishes...sorry. 
)
2 Likes
Hmm. If you feel comfortable modifying code, line 102 of the preview 1 CoCoHue Bridge driver should say something like:
if (!(resp?.headers?.'Content-Type')?.contains('json')) {
If you replace that with this,
if (resp?.json) {
then it should check more or less what I was looking for with my original attempt but less aggressively. If this check still fails, the rest definitely would, so there might be something odd with the data your Bridge is sending back, but it appears to be coming back OK (HTTP 200). If you're really comfortable with editing code, feel free to also add something like:
log.debug "Headers are ${resp?.headers}"
somewhere (maybe the line right before the one I suggested you edit) and see what the logs spit out. My v2 Bridge on the latest Hue Bridge firmware with the latest Hubitat firmware always gave me the Content-Type header I was looking for, but I guess I don't really care if it declares that as long as it's able to get JSON out of it. No pressure to try that, but I'd be curious what other people's Bridges do. 
The first suggestion alone might be enough to work around the problem for you, in which case I'll probably do something like this instead in the next release.
If all of that is more than you want to try, I'll probably release something like this in the next day or two that will do what I'm suggesting to see if it helps. I just can't get my any Bridge I tested with to send data like that, so I don't have a good way to test. Thanks for the report, and hopefully either this or the next release helps!
Thanks, I see the problem! The v1 Bridge capitalizes "Content-Type" differently from v2. I also made a typo in what I suggested to you, which should have been:
if (!(resp?.json)) {
That's probably what I should do anyway. I guess I really just want to know if any potentially parseable JSON data is returned. 
Thank you! That was it. All bulbs are discovered now.
Come to think of it, this issue will probably be present in all drivers, so they might work but report errors (the rest just send commands and shouldn't affect functionality). I'll go through all of them to check for this and probably release an update soon, but glad this worked! Thanks for testing.
EDIT: I've just released 2.0 Preview 2 with all the fixes mentioned above. This should help prevent spurious errors from v1 Bridges and prevent the "Enter IP address...." page from refreshing unnecessarily if adding a Bridge manually by IP. It should be updated on the HubitatCommunity GitHub (above) now and through Hubitat Package Manager.
1 Like
Good morning.
I found an minor edge case were the driver is throwing an exception.
This morning the power went out for 5 seconds.
The HE hub is on battery backup but the Hue bridge is not.
No other functionality seems to be affected.
I am using Version: 2.0.0-preview.1
Hmm. Around like 160 of the app code, there should be a line like:
if (!state.lastDiscoCommand && (now() - state.lastDiscoCommand >= 300000))
My hunch is that this will go away if you replace it with this instead, which I can only assume is what I meant to do:
if (!state.lastDiscoCommand || (now() - state.lastDiscoCommand >= 300000))
However, it's likely to have gone away on its own already, depending on what else you've done in the app in the meantime. Thanks for the report! I'll have a fix for the next release.
Hey All,
About to convert over from the native Hue integration (thanks for the help over at the Inovelli forum Bert!) but I had a few questions (didn't see them answered here or in the readme, apologies if I missed it!) when converting over:
1 - Is there any "easy" way to convert over all rules, apps, etc. that are using the native Hue integration groups with CoCoHue or is this something I'd have to do manually? (not a problem, just don't want to do unnecessary work if I don't have to)
2 - Once switched over, does the Native Hue integration remove the lights/groups it created in Hubitat when removed or is there an option for that (like in the CoCoHue app) that I'm missing?
3 - Once the Native Hue integration is removed, is there an easy way to spot any rules/apps where I may have missed converting over one of the groups/lights? (Assume there would be some errors in the logs if any of the rules/apps were activated but is there any way to figure it out without actively triggering the rule or app?)
Excited to switch over, thanks for all the great work!
Thanks in Advance,
-Felipe
Yes you will have to do it manually, just don't delete the native integration until you have installed CoCo so it's easy to make the switch by going into each rule and just change devices.
The devices and groups created by the native integration will have to be removed manually once you have moved everything over, at least in my experience.
The best way to do it is to go into each device of the native integration and the scroll to the "in use by" section to identify the rules/apps that need to be updated, then delete the device once you are sure it's no longer in use. In some circumstances the device may still report as "in use" even after you have updated the rules, just make sure it isn't then go ahead and delete it.
2 Likes
Thanks Much! Particularly for the tip on checking "In Use" for the native integration.
1 Like
Sorry for the late response. I was able to replicate the exception. After applying the change the exception no longer occurs.
Thanks
Thanks for this app! I just changed over from the stock integration as I needed the start/stop level for a group. 3rd party developers are really filling in some big holes these days. Not that you can do anything about it, but it is a total pain to replace the old devices in all the other apps and rules.
1 Like
Is there a way for the start level up change to turn the light or groups on? The stock drivers do as do most physical devices. The logic would be if the light is off and the start level up is triggered then start ramping up from zero. Thanks
They do? None of my Zigbee lights (or in wall dimmers) come on with a start level change up or down, only with a set level.
My Z-Wave and Lutron dimmers do both with the Hubitat stock drivers and at the physical switch. The Lutron ones are smoother, but I think that's more about the performance of the physical devices.
I know it is possible to do with Hue bulbs as the old Lutron Connected Bulb Remotes did it and did it smoothly. I don't know how difficult it is to implement in Hubitat.
They don't. 
Hubitat's native Hue Bridge integration doesn't do this, at least, if that's what you mean. I noticed directly-paired Zigbee bulbs do (Sengled was the one I remember most, but they probably all did, probably including Hue), and I see you mentioned Lutron as well. In any case, as far as I can tell, there isn't a good way to do this via the Hue Bridge, which doesn't let you do anything with the bulbs when they're off unless you first issue an "on," so if they're off, the command to fade their level is ignored.
My first suggestion would be to use some logic in your automation that would turn them on if off. That would work now, and I know it's possible (downside: two commands, but shouldn't matter much if it's only a few bulbs or a group). However, I just played around with the API and think I might be able to get something similar to what I am doing for this to work if I issue an explicit "on" along with the command to fade the level, or at least in my testing now, the Hue Bridge seemed to accept it (and, also key, the one to stop adjusting still worked). The included "on" appears harmless if the bulbs are indeed already on. Still, I'd probably make this a preference, as I strongly prefer that this not happen myself, and I'm still not sure behavior would really be consistent with some directly-paired devices that you've mentioned (in my experience, a startLevelChange(down) also turns them off if you go too far, which is even worse for me...though now that I think about it, that could be do-able with a similar adjustment).
