Hi, I'm taking my words back because I did not understand how to use Hue Labs scenes. I did not add them from hue labs page in CoCoHue. For some reason I thought that they are "scenes" like other scenes are too. So my apologies for asking stupid questions and writing stupid messages 
I asked more information from hue essentials folks but did not yet receive any.
The only stupid questions are those that are not asked …
2 Likes
This community is excellent for supporting each other!
2 Likes
I have been experiencing the 1% power on issue and thought it was just nature of the beast. Glad to see that using the setLevel with a 0 duration is my work around for the rules. However when I ask my Echo device to turn on the light, she will use the power.on setting and they will turn on at 1%. I ended up writing some additional rules that if the light changes from off to on, then setLevel to 100. And this will work 95% of the time. However if I ask the Echo to turn on a group, everything in that group gets turned on to 1%. And I then have to ask for her to set the level to 100%.
Any other work around? Or should I be doing something different? It does look like when ever I use the power.off setting, that the light will reset to defaults after a minute or two. I witnessed this when writing some color loop rules. For some strange reason I could not unset the color loop, but if the light was off for a short time, it would unset it for me.
If you use "Set Level" with any transition time to turn the light off (or use a non-default preference value for the "off" transition time, which I think I'm just going to remove due to the fact that nobody else seems to jabe had any luck with it, either), I think the only way to avoid an "incorrect" level when turning back on is to also use a "Set Level" to do that. If you aren't aware, a "Set Level" to a device that is off, pee Hubitat convention, will also turn it on (and to that level).
How you do this depends on the app uoire using. In thinlgs ike Rule Machine or Button Controller, you can use "Set dimmer" instead of just "Turn on." But after this "feature" is removed, you shouldn't have to worry about it from a plain "Off" command anymore, just a "Set Level" to 0 with a transition time specified.
So if I were to change all my rules from power.off to setLevel=0, the next time they are turned on they will turn on at the level they were before seeing them to 0?
How will this function when I ask my Echo to turn it on or off. I believe the Alexa control is On or Off and not a setLevel. And to be honest, I have the Hue bridge linked into my Alexa app. I don't use Hubitat's Echo Skill to publish the Hue lights to Alexa. Will my publishing need to be changed to HE's Echo app after you remove the straight power.off function?
To make it easier, I would recommend just setting the "Off transition time" preference to the default ("Hue default/do not specify") then use the off() command. Do note that, as above, there may have been a bug when the supposed default was incorrectly set, so changing it (back?) to "Hue default/do not specify" should help. (You can use the Preference Manager app to do this more easily if you have many such devices, BTW, but individually on the device page works, too.)
The issue with setLevel(0) is that it calls off() under the hood, and I see in the current code where I pass a transition time to that call regardless of how you invoke the command (if you specify something, it passes that along; otherwise, it uses the "Level transition time" preference value, which right now is only explicit; I can add a similar "Hue default/do not specify" option to this to make that potentially less problematic). I may have not been clear on this above, but it looks to me like any kind of setLevel(0) will have this problem, regardless of whether you explicitly specify a transition time.
However, the problem is easily worked around if you use a setLevel() to turn the bulbs on instead of just an on() command (and, again, a setLevel() alone will turn the bulbs on if off). But, as you note, it's hard to make Alexa do that. Instead of "turn on," you could say "dim (lights) to x%," and that should make Alexa call setLevel() instead of on()--just a bit wordier. So, this is a workaround you can use if using a slower/faster "off" transition time is important for you, and in that case, I'd recommend a setLevel() to 0% with your specified transition time, since that will continue to work even if the "Off transition time" preference is removed.
Hope this makes sense. 
Thanks. That does make sense. The only piece I am not sure where to find is the "Hue Default/do not specify" setting. Is this within your HE app, or within the Hue mobile app itself? I am not familiar with that setting.
Now granted I am not a developer, but as you mention the setLevel(0) really just calls the off() under the hood. Is this the piece that you are talking about removing/updating? Making the the off() really just call the setLevel(0) instead? I'm mentally trying to see if I need to update any of my Reactor logic now, or if it will still function the same after your under the hood updates. I did change all of my on() calls to setLevel(#) already, but left all my offs to off(). It's easy to change, just need to know if leaving it will ultimately break things down the road.
This in the preferences for any device that uses the CoCoHue RGBW Bulb driver (or is at the moment...again, I will probably just remove it).
I'm not sure what the actual implementation details will be, but my goal will be to make a call to off() "safe" (in terms of not affecting the level when turned back on with an on()--which seems to be either a Hue bulb or Bridge/API oddity, but I digress), regardless of how it's implemented. Probably the same for a setLevel(0) (i.e., with one parameter). What is will likely remain problematic (and unavoidably so, given again that this seems to be a problem on the Hue side somewhere) is a setLevel(0,x), where x (a transition time) is indeed specified.
2 Likes
This happened to me using Hue dimmers on the Hue bridge after configuring the dimmers using the Hue Dynamic app (prior to using HE), so it definitely seems like a Hue oddity.
Greetings, everyone! I have CoCoHue 4.0 (Beta 1) available if you are interested in testing. You can manually install it from the ZIP bundle linked to at the end of this post (recommended), the beta folder in the non-HubitatCommunity repo, or you can turn on the "beta" option in HPM if you prefer that method* (this is the "When updating, install pre-release versions" setting)--but note that this affects all packages, as HPM does not have a more specific level of granularity.
NOTE: Before upgrading, make a hub backup. After upgrading, open the CoCoHue app and hit "Done." Devices will not work properly until you hit "Done." Additionally, version 4.0 makes some changes to all CoCoHue devices that are not reversible by simply downgrading the app/driver code, so you will need to restore a hub backup to downgrade (or re-do your CoCoHue setup/devices).
Here's what's new:
- Instant status updates from the Hue Bridge!
- This is disabled by default, but it can be enabled in the CoCoHue app.
- I still consider this experimental, as this uses an undocumented "API" on the Bridge side, and Philips may change or break it at any point; being undocumented, I am also making my best guesses as to what the output means, though most seems straightforward
- I would still not recommend completely disabling polling (see below for some reasons why), though you may feel comfortable significantly reducing your interval if you were a heavy poller (like me) before
- Minor bug fixes and tweaks, including:
- Removed the "off transition time" preference in the RGBW driver due to problems with incorrect level when turning back on, an apparent Hue problem (if you still want this functionality,
setLevel()to 0% with your desired transition time will do the same) - Removed the "on transition time" preference in the RGBW driver due to the Hue API (or possibly the devices themselves) completely ignoring it anyway (if you want this functionality, you will--and always did--have to use
setLevel()with a specific level and transition time).
- Removed the "off transition time" preference in the RGBW driver due to problems with incorrect level when turning back on, an apparent Hue problem (if you still want this functionality,
Known issues:
- If using the new eventstream (instant status) option, the eventstream will occasionally disconnect and reconnect a few seconds later or incorrectly report a disconnection when still connected. The driver attempts to compensate for some of these oddities but may not succeed in all cases.
- If a large number of events are received all at once (e.g., if turning off an "All Hue Lights" group--whether inside or outside of Hubitat), either the Hue Bridge or Hubitat (haven't figured out which yet) seems to cut off the data, usually resulting in malformed JSON and the inability to parse the events. Thus, I do not recommend completely disabling polling at this point.
- Rarely, the eventstream connection seems to fail with a "Oops, there appears to be no lighting here" error in the logs (heavily buried in HTML, but that's ultimately what you'll see). Waiting a minute or so and trying again seems to work, which should happen automatically for you. Again, I recommend not completely disabling polling for this reason.
Let me know if you discover any other issues!
*EDIT: I'm having problems with HPM beta installation (maybe something is wrong in my repo?), but I've made it a bundle for easy installation if you want to do it manually, just a bit more easily: [EDIT 2: Bundle removed; newer beta released, below]
8 Likes
It seems to be working beautifully. You are amazing!
1 Like
I should have kept my mouth shut. I am seeing an issue with some groups where only the “on/off” command is syncing, and not CT or dim level.
I thought I was able to replicate this problem on my test hub, but it turns out I was running a mix of old and new code (including the old Bridge driver that didn't do the new eventstream). I'm not sure how that happened, since that is where I did this development in the first place, but if you were grabbing things from my "dev" repo, it's possible you got something I didn't intended to put there.
If you haven't tried with the known-latest version of the code, perhaps most ideally done from the ZIPped "bundle" import I linked to above, I'd try that first. Make sure you hit "Done" in the parent app (and maybe "Connect Event Stream" in the Bridge device--or at least make sure the button is there!). This is assuming you're using the new eventstream interface. Without this, it should function similar to version 3 and prior.
I am. I’m using the drivers dated 10/19. I’m assuming it’s on my end since some groups sync everything fine while others only sync on/off until everything is polled. It may just be too many events happening.
OK, I found something here. The "new" API apparently doesn't send color/CT or level events with changes to the group--no idea why, as it's still poll-able via the "v1" API. I can work around this by not ignoring these attributes when the command that generated them originated from Hubitat (I was if the new API was in use, otherwise you'd get duplicates--and still will for the bulb drivers, but apparently groups are different). I also had a bug in the group driver that always ignored these attributes anyway, even if the command did come from Hubitat and even if the Bridge was polled, so not even polling would have helped.
I'll have a second beta shortly to address this issue.
3 Likes
I forgot the group I thought was updating was actually a bulb, not a group, syncing non Hue bulbs using the Mirror App. Thanks for looking into this obviously better than I did.
Alright, I've released CoCoHue 4.0 Beta 2 with some fixes for the above. I'd recommend manually importing the Bundle to install: https://github.com/RMoRobert/CoCoHue/raw/master/beta/CoCoHue-4.0-Beta-2-Bundle.zip (but manually as above should work, or maybe HPM with beta enabled).
Fixes:
- Groups will now update color- and CT-related attributes and level when a successful command is sent from Hubitat (they were previously ignored if the new eventstream API was enabled in hopes that the events would come in through that; only switch on/off appears to do that, so this parsing was added back for all cases)
- Fix for polling not updating group states
Because the new API does not send as much information for groups as is available via the old API, I would still recommend leaving polling enabled to some extent. This is practically necessary if you make changes outside of Hubitat or use scenes and care about a group state and not individual bulbs (possibly the case if you use CT scenes like "Read," "Concentrate," or "Relax" where all bulbs--effectively the entire group--get set the same). But you may feel more comfortable lowering the interval.
And again, this API is totally undocumented and I've mostly just been trying to make sense of the data it spits out. Most of it makes sense, but then there are oddities like this. So, let me know if anyone discovers anything else!
3 Likes
Robert to "upgrade" a bundle does one have to remove the existing bundle first then re-import?
Edit: Nope doesn't appear that you do
Not sure if what you are seeing is different than what I see in my code. For me, I receive all the color related events for groups -- if the changes were applied to the group directly. The implied attributes (other than on/off) that are computed based on changes made to individual lights is when I do not get those attributes. May be worth looking into closer.
