Do you mean that you're turning on (and possibly off) via setLevel()? If so, that should be fine. The problem I was talking about above was specific to using a specified transition time for the literal "On" and "Off" commands, which inintroriced in the RGBW driver a while back, with a note that at least one often won't work as expected. Actually thinking of taking these preferences out in the next version for that reason unless anyone really had a good experience with them.
But "Set Level" should always be good, with or without an explicit transition time.
Yes, I am working on the ability to use updates pushed from the "server" (Hue Bridge) in real time. Beta coming soon. (But I would caution that this is still not a public API on the Hue side of things, so it could break/change at any time. Also, not all information that I'd like is included, so it may not completely eliminate the need for refreshing/polling.)
I was surprised to see button pushes coming through in the logs. Event stream is a little temperamental, but it’s very exciting to see what you’ve accomplished.
Color is the biggest thing. Hubitat's color model is hue/saturation (or CT if in CT mode), but the "push" from the Hue Bridge includes either only xy or xy plus CT (if the bulb is currently producing a CT). So, if you change color--even by sending hue/saturation--all that comes back is xy, which isn't helpful since I have yet to find a reliable conversion algorithm (a future goal...) and Hubitat events want hue/saturation. In most cases, that is still reported by polling the device (although if the bulb is in xy mode, it may not be accurate--xy is, but the hue, saturation, or color temperature it reports may not be, though they do seem to be for me if the bulb is doing a color or CT at that moment, though when the mode is just "xy," there is no way to tell; another reason I hope to find a reliable method of conversion in the future).
On/off, level, and CT work great, though!
Wait, I hope you're not using the experimental version from my personal repo instead of the (production-ready) HubitatCommunity one. But I don't think I broke anything too bad in there either way...haha.
And yeah, I'll have to figure out what is going on with the buttons. I wasn't able to get the data that I needed to figure out what button it actually was, but at the moment I'm probably stripping out a lot of things that I didn't think were necessary for lights, and I'm pretty sure it was there in the "raw" HTTP data and in whatever Home Assistant's library is doing, so it should be possible somehow.
Okay . But if I am, I am not bugging you about any group errors or socket disconnects because I know it’s a work in progress, and the public version works perfectly.
Yes, I've tried that and several others. It just doesn't line up with what the bulbs actually do (or with what they report for xy and hs when in the other mode but doing a color). Part of this could be the wrong white point or gamut corrections/adjustments not being made, and if you only deal with xy by conversion to/from HS, I suppose it would at least be consistent (just ignoring Hue's HS values)....but I still haven't found any solution I like.
Robert, your tenacity pursuing a comprehensive & robust solution to that color issue is so darn impressive... Based on prev posts here & there, I know it's a topic you regularly research & toy with as Hue's overall development evolves.
I (and I'm sure many others here) really appreciate your dedication to getting the little details like that as right as possible. Thank you again for CoCoHue and all of your other contributions to the community here!
Great App!!!! It's so much nicer to use this and enjoy Hue scenes.
I was wishing though that Hue Essentials scenes and effects would have been integrated too but that doesn't work. Just noticed that someone else asked same thing year ago and I guess nothing has changed from there. Cocohue still lists those scenes from Essentials that's why I was wishing it to be true..
Yeah, I'm not sure how Hue Essentials stores its "scenes" or effects. If they use a Hue API Sensor to start the scene/effect, then that actually might work now via the new-ish Hue Labs feature (that's how those works, but it looks only for specific types, as "sensor" in the Hue API sense encompasses a lot of things--motion sensors, buttons, Labs activators, etc., so it needs to narrow them down)0 It's possible they combine "real" Hue scenes with other parts of the Hue API, which could explain why they show up (and I assume don't have the intended effect, though that's not clear to me from the description). I don't use this app so can't look myself. Might get to it some day, but no guarantees. In the meantime, real Hue scenes and most Hue Labs activators should work.
Hi @bertabcd1234, not sure what's causing this but a specific group is causing 3 errors in the logs at each time the bridge is polled.
Sorry if this has been asked before.
Do you have Group devices that are using the CoCoHue Generic Status driver instead of the CoCoHue Group driver, by chance? If so, switching those (and making sure the code is up-to-date) should help. Someone else had that problem recently, so I'm not sure if either that is just an easy error to make for some reason if you're copying/pasting code or if I maybe messed something up in the HPM repo at some point (if you're using HPM)...either way, that definitely looks like what's happening.
Interesting! I just tried adding a new (previously not added) group on my test hub and was not able to replicate the problem. If it keeps happening or you figure out some pattern to if/when it does, let me know and I can dig into it more! (To be safe, I'd recommend a re-match before you update next with HPM--just in case it happened to associate the wrong driver name with some driver code.)
Just to let you know, that hue labs scenes do not work with cocohue and can't be controller from Hubitat. So none of the color transition scenes can't be used. I'm guessing that what ever it is that prevents this has same root cause for the hue labs and for the HueEssentials.
There is still something that works and that is turning scene off. So if scene is started from hue app (labs section) and scene is migrated to hubitat with cocohue, then it is possible to turn scene off once it is started. Scene cannot be started from Hubitat.
Log is active though and everything seems to "do" right things..
So, turning "off" a scene really isn't anything special, and I'm not surprised that that works; it just finds the associated group or lights and turns those off. (Hue does not have a concept of scene on/off states, at least in their current API; they are just activators. Part of me wishes I never made them switches, only buttons, on the Hubitat side, but I added reasonable-seeming switch behavior based on feedback from a particularly vocal former early adopter.) The "scenes" you're using that don't work to turn on/activate must be using additional parts of the API, perhaps multiple scenes plus schedules, to do their work, which won't work with CoCoHue at the moment.
In my testing, most Hue Labs "scenes" (formulas) I tried did work. However, you must add them from the "Hue Labs" page in CoCoHue, not the "Scenes" page (some may have associated scenes that appear with regular scenes but are unlikely to work as expected for the above reasons). I haven't tried every single one, but any that lets you create a virtual activator for use on the Hue Labs website should work, since that is the same device this integration tries to find and use. However, they likely all work slightly differently and are all experimental by Hue's own definition (some eventually become "real" features that are easier to use),, so your luck may vary from one to another.
(But I would caution that this is still not a public API on the Hue side of things, so it could break/change at any time. Also, not all information that I'd like is included, so it may not completely eliminate the need for refreshing/polling.)
But I don't think I broke anything too bad in there either way...haha.
. But if I am, I am not bugging you about any group errors or socket disconnects because I know it’s a work in progress, and the public version works perfectly.
