I guess I should look at it in the context of your rule: that will indeed re-execute the "On" command, regardless of whether the scene thinks it's on or not. Hue doesn't have a concept of scenes being off or on (only lights or groups), so that state is basically heuristically derived on the Hubitat (CoCoHue) side based on those observable states. Like most Hubitat devices (so I think I'm following convention here), issuing an "On" command on Hubitat will indeed send that real-world command to the device, regardless of what it believes its current state to be. With Hue scenes, I think this is particularly important given that their on/off states are non-Hue constructs. (Have I mentioned recently that I wish I just made these things button devices instead? )
In your case, if you do find current state to be an accurate indicator for you and want to avoid the extra commands, I'd suggest adding a check in your rule: basically, if off (or not on), then send "on." I believe an app (including a rule) is the appropriate place to handle this in Hubitat. But it's also likely harmless to leave as-is.
Thanks for the explanation, I think you are absolutely right and it makes sense to keep it as is.
I agree that given that scenes aren't really off or on, having them only as button devices would make more sense. But it's also nice to have the option as it is now.
In terms of my rule, I believe the additional polling generated is harmless, since it's something like 1 extra per minute. I could add the if off like you suggested, but then there would be the edge case of someone turning off the lights using the dimmer button and someone walking in again without the bridge refresh having happened, which would mean the lights wouldn't turn on until the off is detected. Also, I like the fact that the logic now makes the scene change if the mode is changed while the light is already on. Some automations only change the scene when the lights change from off to on.
In summary: I'll keep it as is and understand the consequences
Thanks for your time!
(1) What is the best practice when creating scenes and grouping Hue lights with lights on a zwave dimmer?
I am unsure whether I should define per light scene specifics (like colour temp and level) from within the Groups app on Hubitat, or whether these be set separately in Hue and then nested into a Hubitat scene.
This is starting from scratch, so I am not particularly attached to the Hue scenes.
(2) Is there any possibility for starting/stopping animations created with the iConnectHue iOS app using the Hubitat?
For the first question: my suggestion would be to do as much scene work as you can on the Hue side rather than the Hubitat side, the reason being that Hue scenes work very well and utilize group messaging, whereas a Hubitat scene that contains individual Hue bulbs or groups will have to send (at least) one command per bulb/group. Doing the scene on Hue results in fewer calls both from Hubitat to Hue and from Hue to the bulbs.
That being said, if you only have a few bulbs, a Hubitat-only scene should still work fine; my biggest concern would be Hue's recommended rate limits of 10 commands per second for bulbs and 1 command per second for groups (plus visual oddities you may notice like slight "popcorning," where everything doesn't change entirely simultaneously). You could certainly try it either way and see what works best for you.
For the second question: I'm not aware of any right now, unless you figure out how to activate one via the Hue API (which I'm certain is possible since that's probably how the app is doing that; I just haven't dug into this part of Hue's API yet, so I'm not familiar, and I'm not aware of any other Hubitat-Hue integration that has...it's on my to-do list at some point in the future).
Just released an update, CoCoHue 2.1, with some minor feature additions/changes:
Automatic "scene off" heuristics improved as requested above (all GroupScenes for Group will be marked as "off" if group becomes off, even if this happens when read from Bridge state, not just when a command is sent from Hubitat)
Reduced (eliminated, I hope?) "info" logging for device state when no event actually occurred
Added support for optional "rate" key for RGBW bulb and group drivers in setColor() value map (Hubitat uses this for scene transition times in the built-in Groups and Scenes app--not sure anyone is really using this, but I figured I might as well match what at least some of Hubitat's stock drivers do)
Additionally, I performed some code cleanup--for the Groovy-inclined, this was mostly more static typing and less def, which shouldn't affect anything user-visible but might help with performance (there was no specific problem I was addressing, but this is a trend I've seen Hubitat apps and drivers gravitate towards lately, and it's probably always been a good idea).
As always, let me know if there are any problems! (Also as always, if you're still using v1.x and want to upgrade, see the notes above for manual installation. Do not upgrade with HPM from 1.x, but you can begin using it after manual upgrading if you want. Existing 2.x users for any preview or final release can upgrade without concern.)
Someone linked this thread on a different question I had asked. I'm about to get some energy-harvesting switches that work on the Zigbee Green Protocol. I can't pair the switches with HE directly, but I can pair them with a Hue Hub. Could I use the Hue Hub to receive a command from the switch and somehow pass that command on to Hubitat for processing?
(I'm very new to this and I'm still waiting for both hubs to arrive)
To my understanding Hue does not expose accessories to 3rd party integrations other than HomeKit. However, if you integrate Hubitat devices into HomeKit using HomeBridge, you can then configure Hue accessories in HomeKit to control Hubitat devices that are shared to HomeKit.
A very hacky way is to configure the switch via the Hue App to set a light to, say, 41%. Then you set up Hubitat to do an action when said light changes exactly to 41%. Then another action could be triggered when said light changes to 43%, etc. Some people use some unused bulbs just for that, and there used to be a method of creating a "ghost bulb" (which you unpaired manually from the bridge) just so you could manipulate its levels.
It's a slow solution because it would depend on how often you poll the Hue Bridge, since HE would only get that change of level after each poll.
I would not recommend it, but it can work depending on your use case.
This is what I was originally hinking about but I didn't know that it would depend on polling rate. I sort of assumed that both hubs would communicate in real time. I don't have a "dummy bulb" but I would most likely end up using the switch to control groups of bulbs anyway. The catch is that I need to control a combination of Hue Bulbs, Lifx bulbs and the Osram LED Strip with whatever protocol it uses, which is why I bought the Hubitat. This could be a potential solution if I can't manage to hack something else together.
Yes, unfortunately they don't communicate in real time, but you can set the polling rate pretty frequent if you want.
Have a look at this, it might still be possible to do:
I noticed some strange behaviour in my rules and I wanted to know if this is fixable and if it happens to anyone else.
I have rules that set some light groups levels to specific numbers or CT, but it seems that after giving the command to set level the number is not the one I chose.
For example, in one rule if I set level to 25, the group then reports 24. With colour temperature it's the same, I ask for 2700 and its set to 2698 or something like that.
Maybe it's a problem with some rounding function? @bertabcd1234
It's not a huge issue, but it's weird.
Thank you!
Hubitat's level goes 1-100, whereas Hue goes 1-254, so there is indeed some rounding going on due to the conversion that must be performed. I discovered that I could be doing this a bit more accurately (I'm inadvertently just stripping anything after the decimal point right now instead of rounding) and will get an update out for that shortly.
The situation is similar for color temperature: Hubitat uses Kelvin (Hue has bulbs that range from 2000-6500 and 2200-6500, and there may be more I don't know of), whereas the Hue Bridge uses mireds, or reciprocal megakelvins. So 2700 K on Hubitat is 1000000/2700 ~= 370.37 ~= 370 for the Hue Bridge. When this value gets reported back, we convert 1000000/370 ~= 2702.70 ~= 2702. Hubitat has more resolution that Hue here, so anything within a few Kelvin is possible. I did check my code here and don't see any rounding problems as above.
Hue Bridge bulbs aren't unique in this regard; Hubitat's Generic Zigbee RGBW bulb driver appear to do this too, and as far as I know it's just how color temperature with Zigbee works. I don't see a good way around this, so I'd suggest not writing automations that depend on exact color temperatures but instead ones that can accommodate a range of a few K in either direction. (I do see less-good ways around this, like tracking the last set color temperature and considering anything reported back within a few K to be that value instead, but I'm not sure I want to go down that path.)
EDIT: Version 2.1.1 is out with the above-mentioned improvement for level (brightness) rounding.
That was quick, thank you so much!
Indeed my automation were using ranges instead of exact points, but now at least for levels I think I can get around it.
Edit : just tested and you are right about CT:. No issues there. I think the stock hue integration has the issues I mentioned.
Got my new Hubitat installed and both Hue hubs working with Alexa. Then realised none of the scenes work on the native Hue Hubitat app - does this build resolve this?
Does it also allow you to set bulb brightness, ie ‘Alexa set bulb to 70%’? Is this is what is referred to as change level?
By "Hue Hubitat app," do you mean Hubitat's built-in Hue Bridge Integration app? If so, yes: CoCoHue allows you to import scenes from the Hue Bridge, which Hubitat's built-in integration does not support.
The command you want on Hubitat is called "Set Level," and both CoCoHue and Hubitat's stock Hue Bridge integration support this (as should pretty much all Hubitat drivers for any dimmable bulb). From Alexa, you can indeed run this command by saying something like "set bulb XYZ to 70%."
Also, note that the Hue Bridge (if you're using a v2 Bridge or newer) has its own Alexa integration. Many people like to use this instead. That way, you don't need to put Hubitat in the middle (and you'll have access to all bulbs, rooms/zones/groups, and scenes, even ones you don't use in Hubitat). However, either way should work. The pros and cons of each approach was recently discussed in another thread if you were interested in reading more: School me on Alexa Integration?
Thanks for your detailed response. I did indeed mean the Hubitat Hue integration app.
I didn’t think the Alexa app could be linked to more than one Hue hub at a time, so I thought I would have to get Alexa to link to Hubitat instead as I have two Hue hubs.
You cannot link the Hubitat Alexa skill to more than two Hubitat hubs (if that's what you meant, sorry!). You can link it to both Hubitat and Hue at the same time (they are separate skills; as far as I know, this is mostly the result of Amazon not letting you install multiple instances of the same skill--and skill developers not finding creative workarounds).
Greetings, everyone! I've been working on the next major version of CoCoHue, release 3.0, and thought I'd preview some of my changes:
Support for Hue Motion sensors (indoor and outdoor) with motion, illuminance, and temperature attributes. Do note that this relies on polling, so I would not recommend using this for time-sensitive automations like motion lighting. I trust people to understand the tradeoffs here.
Support for Hue Labs "activator" devices: any Hue Labs formula you've configured on the Hue Labs website with a "virtual activator" device can be imported as a device in Hubitat. These devices, as you might expect, support being turned on and off and reporting their state (like everything on Hue, also only via polling or changing from Hubitat). I also made them a PushableButton device, so pushing button 1 is an alternative to sending an "On" command.
There are two new drivers for the above features: cocohue-generic-status-driver.groovy and cocohue-motion-sensor-driver.groovy; the former name is a bit odd but closely matches what Hue internally calls these devices and it may be usable for other things in the future. All of the apps and drivers have received at least minor updates, though these are only new visible features.
The code is available in HPM if you have the "prerelease" option turned on. If this works well enough for people, I'll tie up some loose ends and eventually promote this to a stable release in the "regular" branch. You can also manually install it from a temporary location I created for this: CoCoHue/beta at master · RMoRobert/CoCoHue · GitHub (should be apparent what code goes with what apps/drivers; don't forget the new ones).
And yes, 1.x users still need to perform the first upgrade manually for at least the app portion according to the instructions in the first post. After that, HPM should work, though you'll probably still want to perform the uncommenting-in-the-app step each time.
)
