So going back to my original issue from start of thread plus the recent discussion - I tried testing all the built in Hubitat scenes to try to get the patio light capture set up. With Scene Capture and cocohue, I'm still getting the issue where hubitat only captures CT mode on the lights. I guess scene capture is the same as capture within rule machine? Makes sense.
So I deleted cocohue and did the built in Hue hub integration. Scene capture works perfectly to easily copy scenes from Hue to Hubitat. I then reset up my original rule for capture and restore, this time using the Hue bulbs through the Hubitat integration - now it works flawlessly and restore lights with their actual RGB values.
Now I just need to set up my Scene transitions and the natural light copy. So I guess it seems like using the built in hub integration would've been better for me to begin with? I'm not understanding the benefits of cocohue especially with the limitations I'm hitting. The native integration is getting me proper RGB captures, is fairly easy to port over scenes through the Scene Capture app, and I can set up Scene transitions as well. Anything I'm missing or should I just proceed with setting things up like this?
How did you set the lights to these states in the first place, and what does Hubitat report for these devices under "Current States" on the device detail page for each? That's all any app would know to "capture," regardless of what integration you are using. It sounds like you're running into the XY color mode problem we discussed at length above. Different integrations may handle this differently as the hub doesn't have "native" suport for this color model.
Yes, this is the same issue we are discussing a while ago. However what I'm finding is that the built in Hubitat Hue integration is pulling the rbg values even if I'm setting the lights in the Hue app to start (where cocohue was only seeing CT). This allows me to create scenes in Hue app then copy to Hubitat with the Scene creator.
I guess what I forgot to try, and what you alluded to, is I never tried activating a cocohue scene and then trying a capture from there. I'm guessing that would work as well - though I can't think of a reason to do so at the moment since generally the built in integration seems to be playing nicer with more flexibility if I ever manually set things in the Hue app.
Are you only bringing into Hubitat individual lights? I wonder if there is something using polling only versus the eventstream and individual lights versus groups/scenes. That's the only thing I can think of that might explain the differences.
As for this paragraph, what you are finding is that there are many different ways to do things in Hubitat. Personally, I do not use capture and restore. I bring in my scenes through CoCoHue and define what happens to the lights based on Room Lighting and Rule Machine. For instance, my outdoor lights are controlled through Room Lighting on a sunset-30 and sunrise+30 schedule. They are on the tropical twilight scene and adjust their level based on time periods. However, my outdoor motion sensor rule is housed in Rule Machine. Motion activates and it turns my lights to the Concentrate scene. After 5 minutes of inactivity, the rule turns on the Room Lighting Activator device that resets the lights back to their appropriate tropical twilight setting. This is similar to what you want to do, but without the Capture and Restore.
Ultimately, what's likely happening is that your bulbs are getting put in xy mode, which in my experience either scene activation or color manipulation from the Hue app does. Apparently, CoCoHue handles this one way and the built-in another, though in my previous testing it was the same (assuming CT; maybe it's really whatever the last mode was and I have mine in CT most of the time). In any case, with this kind of manipulation, you're likely to find some scenario eventually that won't work for what you want in that specific case with either integration; setting color from Hubitat is almost a ways better if you can.
Ok so this is really interesting. Can you elaborate on this bit?
So basically you have one rule that activates another? If for example you have lights on from 7-10pm and your above time activates your room lighting at 8pm, it activates your tropical twilight scene appropriately?
I actually like this approach much more. Sounds like you have normal lighting routines in room lighting and then anything more complicated goes in rule machine?
I'll have to experiment with that - seems like this also does what I want but allows me to go bank to cocohue, bring in my scenes directly, and avoid the whole capture and restore deal.
Sure. This is my every day Room Lighting instance for my outdoor lights. To keep this post somewhat short, the time periods are (1)sunset-30; (2) 11pm; (3) 4am; (4) sunrise+30, Lights come on at sunrise-30 at 100%, they dim to 25% at 11pm, go back to 100% at 4am, and turn off at sunrise+30. The Means to Activate/Turn Off tells you how Room Lighting turns on and off. The adjust light option means that Room Lighting will automatically change with each time period. The activate even if partially activated is the key to my Rule Machine rule for motion. That option allows my motion rule to change the lights, but then go back to Room Lighting control when it "turns on" the activator device.
My rule for motion is fairly straightforward:
Triggers
Motion active
Motion inactive and stays for 5 minutes
Actions
If Motion active, turn on Front Yard - Concentrate scene
Else, Turn on Front Yard Every Day Switch (Room Lighting Activator)
I bet with Room Lighting and/or Rule Machine, we could probably find a solution that does not required capture and restore. What are the time periods for your front lights and what scenes do you use? I see that you have an Inovelli switch, so this should be fairly straightforward to create.
Geez - so many possibilities, but also so confusing . Every time I think I have it all figured out, I run into more questions. I think I'm just about there though.
Is "turn on front yard every day switch" different from calling the Room Lighting Rule? I couldn't find the "Room Lighting Activator" in terms of switches, but I found what I'm guessing is similar or same thing under the "boolean/rule" section. So my Else is "Activate Patio Daily Lights (Force)" which is the name of my Room Lighting rule.
Now that aside - I thought after recent discussions that I understood everything and was ready to go back to CocoHue. I deleted the native app and re-loaded things through Coco, since using your above logic, I no longer needed to worry about the RGB/CT capture issue.
BUT, now I'm remembering that the other issue with CocoHue is that I can't do scene transitions, right?? Is there a conflict in having both native Hue app PLUS cocohue? Because I know the native app can do scene transitions, cocohue can't.... so I either use both apps depending on situation, or figure out yet another workaround...? Or maybe yet again I simply don't use cocohue at all, since the only benefit that I can see is easier direct import of scenes, instead of copying scenes through capture. Thoughts??
Idk if you can help answer this - but I'm trying to get it to work with cocohue and doing all light manipulations through hubitat, but still not working. If I activate a cocohue scene, and then check the status of an individual light, the light's "current state" still shows CT mode. The " set color" color map does show the correct color though. It seems the only way I can get the current state to report RGB is to command the light device directly (instead of through a coconut scene).
I was hoping that, as you said, if I commanded things through hubitat only, I would see the correct colors reported on the cocohue lights, but that seems not to be the case. I was trying to set up hubitat scenes so I could set up transitions, but I have yet to figure out a way for this to work properly with cocohue vs the native app.
Activating a Hue scene is a bit different. Doing that through Hubitat is the same as activating using the Hue app (or any other method), and it's where recently it seems like the scenes get saved (by Hue) in xy color mode instead of HSV or CT/level--thus back to this problem. Setting actual color or CT form Hubitat (or just using scenes for every rather than trying a capture and restore) is what I meant as one way to work around this.
I see that my original photo was cut off. At the bottom of a Room Lighting instance, there is a place where you can name a switch. By putting a name in the circled box, it creates a virtual switch that you can turn on and off via Rule Machine. Every time I turn "on" this virtual switch, it will set my outdoor lights to their appropriate time period (100% or 25% depending on time).
There is a reason why I provided the Color Temperatures that matched your current Natural Light settings. With Hubitat, you can just send the CT command and have the lights match your scenes. I'm going to show you an example that I whipped up using my Guest Room Light and Room Lighting that matches your Natural Light settings (except I used two minute transitions).
The first picture has the lamp being controlled in Room Lighting by both a hue tap dial (brought in via CoCoHue) and the light itself (if I use the Hue app to turn it on). The lights adjust as the time period changes (next picture) and transition 120 seconds between each command.
I apologize for this quality as I had to Zoom out to get everything to fit, but here are your matching time periods with the CT's matching the Hue Scenes and a "sorta" nightlight for overnight.
Thanks for confirming. I know I've been back and forth, but I was hoping to get cocohue to work. Seems like I need to bring my lights in through the native app if I want to be able to copy scenes to Hubitat scenes (aside from manual settings, as you mentioned).
Got it - I actually did that, but my naming was poor so I didn't see it when I was looking through the switch devices. Do you happen to know how that is different from the method I mentioned - activating the Room Light rule itself (as below?).
Tbh I did realize that. The reason I didn't do that is because if I was going to put in the effort to recreate this natural lighting, I wanted to do more complicated lighting scenes with color added. That's why it was so important to me to figure out scene importing. Based on the other discussion here, seems it's a simple enough solution to just use native app instead of cocohue. I'm sure though I'll eventually figure out some other limitation of the native app and consider cocohue again
Let me get everything set up now and I'll report back how it went.
If you wanted to see if CoCoHue would work and wanted to try a small edit that might help, near the top of the RGBW bulb and group drivers, there is a line like this:
@Field static final String xyParsingMode = "ct"
Changing ct to hsmight get you where you want if this is the underlying issue (assuming you are really in color mode and not color temperature mode; again, I suspect you'll run into the opposite problem with either integration when the opposite is the case).
This also might only work with polling or a "Refresh" on the bridge device, not the eventstream/SSE/push options.
I think they work the same way, but am not confident. I've only ever used the activator device.
I'll be very curious as how everything goes. Please do report back as I'm always interested in how folks integrate color into their every day lighting scenes. I generally use circadian lighting from 7:30am to 7:30pm with a 30 minute fade to tropical twilight in the evening and a morning sunrise from 6-7:30am (at least in my open floor kitchen/dining/family rooms). The bedrooms are on the circadian lighting except when the house goes to overnight mode.
By the way, this did the trick, so I'm very happy about that!! In the room lighting app, I was able to capture each of my scenes. The RGB bulbs set their color appropriately, and the ambiance bulbs captured their values appropriately as well. It also seems the RBG bulbs captured the CT values properly in one scene (where I had them set as CT bulbs).
Is my use case unique, or is there room for an update or a user selection? Although scene importing is nice, setting up the Hubitat Scenes via capture through RL allowed me to easily fade/transition.
I've thought about allowing a preference on the devices, but a way to reliably convert XY to and from CT/HSV would be better (anything I've tried so far hasn't been close in practice, and the saving grace in your case is that Hue still updates the reported CT or HS values even though it's not actually reporting either as the current/valid color mode). That way, this wouldn't be necessary -- and even as-is, it's likely to fail in at least some cases unless you happen to prefer only one or the other. You've lucked out since it seems you do, just not the one it was choosing.
I'll revisit this -- again -- some day, especially as the V2 API seems to use XY even more, but the lack of accuracy in previous attempts was not promising (I've tried several times, each time thinking I learned something since I didn't know the last time--and yes, I've Googled the algorithm others have pointed out as if I haven't in other topics ).
. Every time I think I have it all figured out, I run into more questions. I think I'm just about there though.
).
