Trying to use Package Manager to update, but when I do I get:
" Error Occurred During Installation
An error occurred while installing the package: Failed to upgrade app https://raw.githubusercontent.com/HubitatCommunity/CoCoHue/master/apps/cocohue-app.groovy.
Be sure the package is not in use with devices. "
I tried searching the thread, nothing I found indicated anyone had this issue.
Any help appreciated thanks
I just tried an update and was unable to reproduce the problem. If anyone else sees this, let me know if "Logs" has any clues. Otherwise, consider a "Repair" on the package in HPM or one of the manual methods like the bundle ZIP.
Repair worked, thanks
Hey Robert, I have a weird one. Upfront, this is not an app problem (pretty sure at least). I have two of these Gledopto controllers paired to the Hue hub. I've tried setting the controller to "RGB" and "RGBW" mode with the same behavior. They get into this state where I can't control the color anymore. The integration shows me command them to RGB color mode and the right color, but nothing changes on the light and a few seconds later, I see an event come in that sets them to "CT" mode in Hubitat.
What's odd to me (maybe due to ignorance) is that they initially come back with just HS values but the update that flips them to CT have XY values.
Once they get into this loop, I end up having to bounce them between colors and eventually it'll stick.
TIA!
Without digging too deeply, it looks like those devices might report color and color temperature in only XY mode rather than HS or CT. There is some discussion on this above, but in short, conversion between the two (or three) is difficult and not something the driver does much with. As you may know, Hubitat's native color models are HS and CT.
I believe it favors CT if there are any clues it can use, like both in the data or possibly a recent "Set..." from Hubitat. I plan to see what more can be done with this at some point, but for now, these devices are not likely to report well. (Other notable offenders include Ikea bulbs I tested, at least early on.)
Fair enough on the rest. I wish it were just a reporting problem. They are, in fact, trying to set into CT mode for some reason. I end up with this greenish/yellow color and can't change it. Stupid things.
Could also be how they respond to HS or CT commands, which is all CoCoHue will send (same reason with conversion, though different devoce firmware could theoretically handle that differently/better...).
Have you given any more thought to implementing this change in the group and bulb drivers? I recently decided to try updating CoCoHue, which I had been putting off for months, and ran into the same problem with motion lighting. I copied this fix back in to the drivers and all is again well.
Honestly kind of forgot about that, but since there haven't been any problems reported, I went ahead and released v4.1.7 with this change. For manual installers, all bulb drivers are affected; for anyone else, the bundle ZIP or HPM install should take care of everything. Thanks!
Is there a possibility to pull battery status from hue switches?
This should have been fixed a while back for devices that support it. Make sure you are on the latest version.
Just to be clear enough. I use cocohue and my switches are paired to hue. Hue app shows battery status of switches but cocohue doesn't report them.
These are the variables it reports.
And here's the version:
I take the above back--the fix was for motion sensors. I actually never implemented "Battery" for button devices, likely because not all such devices actually have a battery or report this information. Specifically, the Zigbee Green Power devices like the original Hue Tap and some "Friends of Hue" devices like the RunLessWire Click would never give any data to populate this attribute. Hubitat also does not support "dynamic" capabilities, nor is it probably worth it to create two separate drivers for this use case, nor do I know offhand if there is a way to even distinguish these devices upon creation to know which driver would be most appropriate even if there were.
I'm not sure this is something I want to implement right now for the above reasons. 
This is especially true without a clear use case for the information in Hubitat. However, unless the data is reported in an odd way drastically different from the motion sensors, it seems like this should be possible (though I have not checked the actual device data to be certain...).
Hi all,
I have an Innr bulb that intermittently becomes unreachable for about a minute and then becomes reachable again.
I have checked the devices settings and Hue app a couple of times and it always seems to be the same bulb.
Any suggestions how to remedy this issue or if I should just remove this bulb from the network?
Thanks
Is that bulb missing commands? I see that periodically from most of my bulbs, mainly the non-Hue ones furthest away from the hub. It is not something I worry about as I've never noticed commands being missed. Plus, I tend to think the minute between unreachable and reachable is just the time between polls, not the time the bulb is actually unreachable.
No, I don't think it is missing any commands. Most of my bulbs are Innr brand and they all have the same commands.
I setup the alerts as there was one time where this light was totally unreponsive and I had to do a manual power off/on to get it working again.
Strange thing is that it is mainly this one bulb.
CoCoHue is just reporting the status that the Hue Bridge provides for these devices. I'm not sure how the Bridge calculates this data, but it's possible it relies on configuration that some third-party bulbs may have problems with (though I don't think I've ever seen this despite having a few on my Bridge, though no Innr devices there). If you aren't actually having problems with the bulb, that seems the most likely explanation.
In any case, it's definitely not anything CoCoHue is doing--it's just passing along this data.
Can someone help me understand the error I'm seeing in the log for the CoCoHue Bridge device (not the log for the CoCoHue - Hue Bridge Integration). I'm assuming it has something to do with my use of one of the many scenes defined in the Hue bridge. I see this once or twice a day, but have not been able to correlate it with a specific event...
Yes, I believe it is this issue again:
I didn't and wouldn't have made that connection, so thank you for connecting the dots! It doesn't seem to actually cause an observable problem in terms of the lights, so will let it be for now. Thanks again.
Download the Hubitat app
