I seem to be losing it here. How do I add one of my hue remotes? I have 3 currently paired with the hue bridge. I tried searching this thread and the only thing I could find was a comment saying it's not supported. But I also already have a hue dimmer added to Hubitat with a cocohue button driver and cocohue bridge integration is the parent app. What am I forgetting?
Basically I need to get one of my remotes into Hubitat so that I can use it to pause and resume my Room Lighting, since otherwise my remote control commands just gets overridden by room lighting
That was weird. I thought I was on V2 api. The switch for "prefer V2" was blue. I deselected that, saved, reselected, saved again, now all options are showing.
Does anyone else have issues with colorMode not updating correctly? I noticed recently that while all my bulbs work and respond perfectly, when I check the colorMode of the bulb it is most of the time incorrect. If a bulb is currently blue it will have the colorMode as CT. It doesn't matter where the bulb is adjusted from either, hubitat can send the command, hue itself can send the command, my home assistant can tell hubitat to send the command, they all operate the bulb as intended but the colorMode doesn't update. Anything I should look for?
Yes, this is quite likely because the bulb is only reporting xy color, which you'll find some discussion on the difficulties of above. If you have polling enabled and didn't disable V1 parsing for polling even when using the V2 API -- both part of the default configuration, so you would have had to have changed this -- it should catch up eventually because the data is there.
So I have both of those settings enabled but they still don't update over time. Any idea how long it may take? It's currently been 4 hours and the colorMode is still set to CT even though they have been RGB the whole time.
I guess V1 still won't help if the bulb is reporting "colormode: xy" from the API, which is likely to happen from many external changes. But if you make a change from within Hubitat, it should get the hue/saturation values (what it needs for RGB color mode) from that. The other possibility is that you're dealing with bulbs that only report xy and not hue/sat at all, which is possible but not anything I've seen with native Hue bulbs. It's also possible Hue changed something about the way devices report, but last I saw, they'd still report hue/sat if that is how the colors were commanded to be set in the first place (not applicable to scenes or saved data, regardless of how the values were set in the first place--they'll always be xy from what I can tell, as will the Hue app and likely some third-party systems).
I do plan to look at this again some day (but even then, xy conversion is difficult--I have already looked at it quite a bit), but for now, outside of modifying the driver code if you always want RGB mode, it assumes CT for this, which I think I chose because it matched how the built-in integration worked, so it would be less disruptive to switch.
Your comment about scenes there, does that mean when using a hue scene to set the color it will never adjust the colorMode? Or am I reading that wrong. That is how these were set btw.
Just did some of my own testing, activated a hubitat scene and the colors updated properly, activated a hue scene via hubitat and they did not update properly. If that is how it's going to be that shouldn't be an issue, I can manage that. Most of my scenes can be done via hubitat, I just imported some cause I was lazy.
Quite likely, depending on how the scene is stored (in my experience, xy when doing it from the Hue app). But if it's really CT, this is unlikely to matter since that's what the integration will assume when it doesn't know.
Seems consistent with what you found above, just wanted to confirm!
@bertabcd1234, is the latest Hue integration from HE causing you to revisit the role of CocoHue? In the OP, you clearly explain CocoHue’s differentiators, but I’m wondering if your perspective is changing given the new in-built Hue integration.
That post could use an update...but most of the comparisons are accurate for a comparison of the old and new built-in integration, at least. (EDIT: Edited.)
Unfortunately I also started seeing these errors during the last few builds of 2.4.xxx beta, was hoping it would be resolved before release, but doesn't look it was.
@bertabcd1234 is aware of them, hopefully a fix will come soon. Rolling back to 2.3.9.xx was the fix for me.
I think there are platform changes behind the recent appearance of these issues, but I'm trying to figure out what those might be.
In the meantime, I've released an update, CoCoHue 5.2.3, with some minor enhancements that may (or may not) help. There should be no functional differences, mostly internal changes that use a cache fetched from the bridge more than retrieving new data from it every time, especially when adding or searching for new devices and similar operations.
Have you upgraded to the CoCoHue version I just mentioned above?
The Diagnostic Tool is the way to downgrade hub platform versions if you want to. Check the release notes for any new features you might be using that could require special care if downgrading.
(EDIT: Edited.)
