Hey @bertabcd1234, I was tweaking some rules I use and I came across a small quirk that you might be able to fix.
I'm using scenes to turn on some lights, and I use the option that when a group is turned off, all scenes on that group are turned off as well. It works fine, however I have a specific problem in my setup:
I have some Hue Dimmer Remotes that are paired to the hue bridge, not to hubitat. When the lights are turned off using those remotes, even after the bridge refreshes and gets the off state, the scenes don't get updated,probably because that action is tied to the off command on the group.
I would have two possible solutions for this:
Either change CoCoHue and make it that the scenes turn off if the event off comes from a refresh
Or
I could pair those remotes to Hubitat directly. I wouldn't like that very much because I think my zigbee mesh might not be that strong.
Sounds do-able to me! That is a case that I do now see that my current implementation doesn't handle. I made a small change if you're willing to test before I release it. I've put it in my development repo, and it's just a change to the Group driver: CoCoHue/cocohue-group-driver.groovy at master · RMoRobert/CoCoHue · GitHub (as you may know, click the "Raw" link if you want to use the import URL in Hubitat or copy/paste the code). I've tested it a bit and it seems to work as expected for me...unless, it seems, I test things too fast (off too soon after on), in which case my check to do this only if the state isn't already off (which I added to avoid all these parent/child calls unnecessarily if the "off" state isn't new) seems to fail, possibly because Hubitat is too-aggressively reading a cached value instead of what's in the database ... speculation on my part, but I think it should work fine in the real world, and I can force a workaround if not.
By the way, another question regarding optimization. Maybe it's meant to be this way, but just showing you something I'm seeing in my setup.
I have a RM rule for motion lighting that goes like this:
The problem is that each time the motion sensor reports as active, the scene is "turned on" again, even if it's already on. It doesn't seem like a problem per se, but since I have it configured to also refresh the bridge when the scene turns on, it could end up refreshing a bit too much. This is what I see in the logs:
I'm guessing that was just "info" logging happening even if the state didn't change (so not really LAN traffic to/from the Bridge; I was able to replicate this when it was the result of another scene or relevant group getting turned off, even if it was not a state change for that scene device). I've made another change that should filter this logging. If you wanted to test that, it's the scene driver and it's now in my dev repo at: https://github.com/RxoRobert/CoCoHue/blob/master/drivers/cocohue-scene-driver.groovy
I don't think that's just logging, and here's why:
I tested setting the polling from the bridge to hourly.
Then I walked in the bathroom, scene activated.
I then walked off the bathroom and turned off the bathroom lights using the Hue app.
CoCoHue still thought those lights were on and the scene was on as well.
When motion changed to inactive on the sensor, I walked in again. Lights came on.
That means the scene was actually executed again, because if it was just logging the lights should remain off.
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.
)
