The percent of total for CoCoHue is pretty low for the device (the second/app screenshot is actually Chromecast Helper ), which personally wouldn't have me too concerned. The percent of busy just means that among other running drivers/apps, it's responsible for more of that time--which isn't too surprising given that it relies on polling to get device states (so it runs on that schedule, not just when actual device events happen--the current Hue API does not provide a way to send that information to Hubitat as it happens, but maybe soon). Most apps only wake for device events, and most devices only run code when something actually happens (e.g., you run a command or the device sends something to the hub).
If you are noticing problems, you could consider taking steps like reducing the polling interval, which is the main thing that contributes to this usage. Otherwise, I don't want to tell you how to interpret your own hub's stats, but again, they don't seem too concerning to me personally.
Question: Can I visualize my Hue and Friends of Hue Accessories via CoCoHub? I can't see them...
I have for example a Hue Smart Switch (4 buttons) and a Friends of Hue Niko Switch (this one I am more concerned because it uses Zigbee Green and I know Hubitat can't connect to it directly...
Accessories like buttons/remotes are not accessible via CoCoHue because the current Hue API does not have a way to "push" events to external systems, so such a device would be pretty much useless for all practical purposes.
I'm getting error messages re Groups as follows: dev:73472021-08-30 20:47:16.836 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_RMoRobert_CoCoHue_Generic_Status_Device_2843.setMemberBulbIDs() is applicable for argument types: (java.util.ArrayList) values: [[11]] (method setMemberBulbIDs)
dev:73472021-08-30 20:47:16.821 errorgroovy.lang.MissingMethodException: No signature of method: user_driver_RMoRobert_CoCoHue_Generic_Status_Device_2843.createEventsFromMap() is applicable for argument types: (groovy.json.internal.LazyMap, java.lang.Boolean) values: [[all_on:false, any_on:false], true]
Is this supposed to be a group? Did you manually change drivers, by chance? Looks like it's using the Generic Status driver instead of the Group driver.
These messages are appearing on all my groups - across all my 3 Hue Hubs.
You are right - they are using the the Generic Status Driver.
I've no idea how they changed - they were working fine. I'll go change all groups to use the Group Driver now and I'll let you know if this happens again.
If you're using HPM, it's possible something got messed up there during an update (likely by me , but who knows). If you did a manual install/update, perhaps the drivers just got switched during paste or import. If anyone else has problems, let me know!
Just realized I never posted this and I also came up with a better rule using RM5. The "Light" is the bulb group from Hue, which contains these two bulbs in the rule. The idea here is if the bulbs are unreachable for 3 minutes then we assume power was cut (by the switch) and they are off. So in that case I am forcing the group to be off, so that it shows as off on any dashboards or reports, etc...
The reason I also have a trigger for the group turning ON, is in case someone does try to turn it on from a dashboard while the power is cut, which obviously wont work but the group would normally stay ON in that case, so this rule would wait the 3 minutes and then turn it back off if the bulbs stay unreachable.
I have seen where one bulb will randomly go unreachable and then come back on the next poll. Due to this requiring both to be unreachable and also the 3 minute wait I have not had any reports of it unexpectedly turning the lights off when they were on. Seems to be pretty robust.
Does the transition time parameter in the cocohue integration work to provide instant on of hue bulbs? There is a transition time parameter in the native integration but it doesn’t seem to work, at least not for what I think it’s suppose to do. I just want to get rid of the fade in/out delay so that the bulbs turn on and off instantly. I know it’s possible to do with the Hue-branded dimmers, so seems like it would have to be possible here too.
This comment in one of the posts above makes me think it isn’t possible, but maybe I misunderstand?
“ On transition time: is supposed to specify the transition (fade up) time with an on() command, but Hue seems to completely ignore this value, no matter what it's set to. Guessing it's a Bridge or bulb firmware limitation.”
First, it may be important to note what the "transition time" parameter does in most stock drivers and in community drivers (like mine) that follow this convention. This basically provides a default transition time for the "Set Level" command, where the transition time is optional. It does not affect "On" or "Off" commands or anything else. So, that explains the behavior you'd see in the built-in Hue integration plus other drivers like Generic Zigbee RGBW Light, Generic Z-Wave Dimmer, and lots of others. Newer versions of CoCoHue drivers follow a trend Hubitat introduced with their "Advanced Zigbee ... Bulb" family of drivers. These have separate "transition time" preferences for various commands--not just "Set Level," but also "On", "Off," "Set Color," and "Set Color Temperature," all as their own preference, each explicitly labeled.
Back to your actual question: unfortunately, I don't think the behavior you want is possible. Despite the fact that--as far as I can tell--what I'm sending is a valid command according to the Hue API, the bulbs (or maybe Bridge?) just seem to ignore the transition time if the lights are getting turned on. Further, I'd also avoid specifying a transition time for "Off," because then it seems to cause oddities the next time the bulbs are turned on (with the level getting stuck at 1%; not an issue if you turn them on via "Set Level" instead of "On," but you'd have to be careful to actually do that each time if you care). It might be better for me to just remove them entirely. But...it's possible that different bulbs or firmware versions behave differently here. This is just my (and others') experience with current-firmware Hue bulbs of various generations on a Hue Bridge.
Interesting. I guess the Hue-branded dimmer must have some proprietary or special way to turn a bulb on instantly. Too bad we can't hijack that. Thanks for the info!
Does your Hue Dimmer do instant? I think mine look about like their default transition time, which is documented at 400 ms. If you have a specific level in mind, it also is possible to turn these on instantly via the Hue Bridge API--from Hubitat, you'd just need to use the "Set Level" command with a target level and a transition time, and 0 (which sounds like what you want) should work for the latter. The problem is restricted to a plain "On" (unspecified level and so should restore the previous brightness--and it does, but it ignores the transition time).
Hi @bertabcd1234, just wanted to know if there's been any updates on the new way of communicating to the Hue Bridge. You mentioned some months ago that you couldn't make it work. Just wondering if anything changed?
Thanks!
Ah! Perfect. That works well for an instant 'on'. For some reason it doesn't work in reverse for an instant 'off' (setting level to 0 with a duration of 0). But the instant 'on' is more important. Thanks!
No, I am still not able to make Hubitat's EventSocket interface work with the "new" Hue Bridge Event Socket "API" (which itself is completely undocumented and probably not intended for public consumption yet, but that's a different issue). I believe staff are working on some changes in the future that may help, but nothing yet.
You know from our previous exchanges I'm a heavy user and fan of CoCoHue. I did, however, want to share my 1% experience since it is different from your experience.
I'll double-check my motion lighting app, but I'm 99% positive I only ever use setLevel(x) (and never on()) to turn the lights on because the level I want them "on" to varies based on time of day.
My experience with the 1% oddity:
I only experience the 1% behavior on certain Hue Groups. It sort of feels like the more bulbs in the Group the less likely it is to happen although I have a 3-bulb Group that it happens on.
I only experience the 1% behavior some of the time; it works way more frequently then it doesn't. Maybe 9/10 it behaves as desired, and 1/10 it does the 1% thing.
Sometimes the 1% behavior self-recovers after a brief pause (~1-3 seconds -- it's definitely variable ) although sometimes it doesn't self-recover at all and stays at 1%.
Once the 1% behavior occurs, it seems to stop happening for some period of time. ie, if it happens when I open a bedroom closet door, I can then close/open the door over and over and it won't happen again while I'm standing there. Leave it alone for awhile, and it'll come back at the normal ~1/10 frequency.
I once tried spamming a second setLevel after a 100ms delay, and that didn't seem to help. Longer delays (ie, the human delay of observing the behavior and then activating 100% from the wall switch) always works.
I haven't gotten around to it yet, but the next thing I planned on trying was moving the troubled Hue Groups to different Hue Bridges (which would obviously result in a new Hue Group). I have 4 Hue Bridges and they tend to service different "chunks" of the house, maybe I should alternate the rooms they service instead of having a single Hue Bridge handle adjacent rooms.
If anyone else experiences the 1% behavior, I'd love to get a technical dialogue going with you so we could figure out the trigger and work around it.
But as I always like to end a message about CoCoHue with: Thanks @bertabcd1234 for this driver as it is far-and-away the most used component of my home automation setup. Everyone who visits my house thinks the motion lighting + time-of-day circadian lighting setup with smooth fading lights that are in sync with one another is amazing.
), which personally wouldn't have me too concerned. The percent of busy just means that among other running drivers/apps, it's responsible for more of that time--which isn't too surprising given that it relies on polling to get device states (so it runs on that schedule, not just when actual device events happen--the current Hue API does not provide a way to send that information to Hubitat as it happens, but maybe soon). Most apps only wake for device events, and most devices only run code when something actually happens (e.g., you run a command or the device sends something to the hub).
, but who knows). If you did a manual install/update, perhaps the drivers just got switched during paste or import. If anyone else has problems, let me know!
