I feel that room lighting should offer RGB AND RGBW options
In the case of my driver choice I can issue CT value - however Activation settings doesn't offer Temp like a CT type does.:
In the case of my driver choice I can issue CT value - however Activation settings doesn't offer Temp like a CT type does.:
What are you trying to actually do? Room Lighting supports RGBW lights, but you can only activate it to one or the other (CT or RGB), per standard device behavior, and the options in the UI let you choose which.
3 Likes
Standard device behavior. That's confusing. The driver of RGB and RGBW are different - standard device behavior of an rgbw bulb is both. I'm sure you just overlooked that.
Or perhaps the app interface is streamlined in such a way as to accommodate most common use cases and to avoid confusing less advanced users.
For users that want additional complexity, there’s always rule machine.
2 Likes
Standard device behavior for RGBW bulbs is to either use the bulb in RGB mode or CT mode.
Can you point me to an RGBW bulb that simultaneously supports both RGB and CT illumination?
5 Likes
I think we are confusing RGB, RGBW, and RGBWW as activation methods in RL. They are simply way to allow us as consumers to know the LED arrangements of the devices we are getting. It really doesn't have much to do with how the said LED's are activated.
As @aaiyar mentions generally you don't have both sets of LED's on at the same time, though, I do think some devices have been found to do it to enhance light output. That is generally handled at the device controller level though and not at the driver in Hubitat. The problem with mixing the Color LED's with the cool white LED's and warm white LED's is that you distort the color or white temp output.
From a RL perspective you just select the kind of light output you want and then set it accordingly. You can choose either from Switch, Dimmer, RGB or CT (if the device supports it) when setting up the RL instance. If it shows RGB but you would rather tell it a CT then click on "RGB" and change that device to CT instead or vice versa if it shows you CT but you want RGB instead.
6 Likes
No, I am familiar with the behavior of RGBW drivers and such devices and have accurately described their standard behavior. You may have overlooked the colorMode attribute on an RGBW device, which will tell you whether it's currently in CT or RGB mode:
A setColorTemperature() command will conventionally put the device in the former, or a setColor() (or some related commands) in the latter. What I mean is that standard behavior does not allow both at the same time – as others have now mentioned above. (If a particular device actually does, a compliant approach would be a parent device with two child/component devices, one for CT and one for RGB. I am not aware of any, except maybe some RGBW strip controllers with completely independent channels.)
So, Room Lighting is asking which you want to -- it has to be one or the other (again, "both" would be achievable by separate devices if that is actually supported by your device, this separation being the role of the driver). Hope this clears things up. If not, I'd suggest explaining what you are actually trying to do, as I also suggested above. Good luck!
2 Likes
Pretending I agree with you, then the ability to add 2 versions of my strip light would be desired.
MOCKUP*
and that opens a whole can of worms that I hope no one wants to see.
My solution to this 'weakness' is to front end the strip, and create 2 virtual devices - so when I use Room Lighting I can add both devices - then I can control CT during modes I only want CT management and RGB when I want color management.
What always gets me when arguments start is that instead of finding ways to improve things, we shoehorn. It's sort of a game around here. A second point is if a device can have 2 capabilities, why can't it have two types? A device can be a switch and a contact. So why the limitation I ask myself and no one cares.
Ideally, RL should check the driver, and if it offers CT, add Temp value option. If it offers RGB, then display Color option.
Finally, I'll add that the rabbit hole goes deeper - RGB+CCT has two distinct chips, and requires a driver capable of talking to both:
I off to split my working device into two devices so I can make it work the way I want.
You don't need to agree with me; I linked to the specs above and explained the most relevant part. 
(You also don't need to pretend; try any built-in driver with a supported device and you'll see that this is how it works. Or try the built-in virtual RGBW driver if you don't have any.)
I'm still not clear on what you're trying to do. Are you trying to set either CT or color depending on time/mode/etc.? If so, that is already do-able without workarounds. If you are trying to set both, i.e., at the same time, I (and others) have already explained above that this is not standard behavior. The capability model I linked to above mirrors this, and it's what apps like RL use as an assumption for device behavior (this is the point of capabilities--standardizing commands and attributes so apps know what to expect).
If so, I think your solution of two virtual devices to separate this behavior is actually an OK workaround for that. But as I mentioned above, the "best" approach is probably for the driver to do this (e.g., creating two component devices, one for each, each of which you could use in RL). Another alternative is for the driver to offer custom commands or perhaps even usurp standard command behavior -- but then you won't be able to use apps that depend on standard behavior, as RL does (a custom app or rule could work, however). But with a single device, you are subject to the capability expectations above, at least if you want to use standard apps. The capability is unlikely to change in any way that could significantly affect backwards compatibility (or perhaps at all, given that it works for the vast majority of devices out there, and there are already ways to use these capabilities in different ways to get the behavior you want if my assumptions are correct).
3 Likes
You can do this. You can set the device type separately for each mode or time period. So for one its RGB and another its CT. Like this:
4 Likes
It’s a game that some users seem to insist on playing a lot more than others. Even when there’s no one else that particularly wants to play.
4 Likes
Okay. Thats brilliant. a hidden gem I never thought of! What I did was use Mirror to create a 2nd, virtual unit as CT.
Then I mirrored the CT back on itself to the RGB. So if I issued ct command to the CT device, boom. If I issued RGB command, boom chacalaca.
of course, your way is better - and now I'll go rip out the virtual excess, and do it the lean way!
Here's my solve (which worked perfectly!)
I hope I get some prop's at least for out of the box thinking...
To be fair, you went around your elbow to get there. I suppose it saves a mouse click when setting up RL but with the extra overhead of setting up the device mirror.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
