Sounds good, I just wrapped up another custom driver for a plug in dimmer someone sent me, and I have a ZEN54 dimmer module on the way to work on as well!
Will Code for Devices
2 Likes
So I started working on this and I think I see how a driver could slowly degrade the brightness as described. It is because the "V" of the HSV is often mingled with the level attribute, even the color picker for the Set Color command pulls in the level for it. But this RGB controller (along with many others) the level is independent of the RGB color.
Taking that into consideration, hopefully my driver will not have the same problem.
I hope to have a beta version within a few days. At this point I do not think I will use child devices to start with, but may add an option to create them because depending on how you use this controller I can see how they could be handy.
What are thoughts about having a command to manually set the R,G,B values? So you can manually control each channel?
Right now I have the setColor working, and setLevel. I dont have a white LED connected (I only have a RGB strip not RGBW).
I'm having different issues but this zen31 device or driver has been extremely frustrating when trying to figure out why one day it manages the LED strips and the next day it doesn't.
I dont personally see a need to have manual commands for R,G,B. HE has great commands for "set color" etc.
So if not child devices? How would you be able to say "turn on Color Red, at 50%"? or "Turn on white at 50% but only the white LED, not r+g+b"?
If you private msg me your address I'll send you some scraps of RGB+W from my last project.
PM sent.
Thats what I am working on figuring out how it would work. I am using the setColor already and have that working as I want. There is a "Color Mode" attribute and also a Color Temperature, which if used when you set the color temp to White I would turn off RBG mode and either only do white dimming via setLevel, or possibly simulate color temps using the RGB lights.
Other possibilities are to have just a child for White and use the main for RGB, or have two Childs similar to the stock driver.
So far I am just getting the color commands all figured out and coded, especially since I dont have a white LED connected yet to see how it will all work together.
Adding all the parameters and also the button press options as well, if using momentary switches.
I expect this to be a little rough as I iron out the different use cases and what types of control will work the best for different situations.
1 Like
Success on separating the RGB from the brightness: What is string format for color attribute?
Now that I am thinking about it more. Is there even a need or desire to control the brightness level separate from the RGB color values? In theory I think R of 125 / 100% should be ~= R of 250 / 50%
Maybe I just keep the actual level on the device at 100% and control the brightness only via the HSL/RGB Values if there is no visible difference. setLevel would still work and change the "level" value, but it would actually just set new RGB values on the device based on HSL to RGB conversion.
I will have to do some tests with more complex color values and see if it holds true visually on the LED strip.
1 Like
That is true. I do kind of currently use "Red at 50% brightness" for my nightlight-function. But I could achieve the same with using a darker shade of red.
Just dont know how that complicates using "white at 50%".
Still digging into this thing. I am starting to see why having the two child devices is helpful and how it works well with the system driver. I am now leaning towards replicating that style to start with but I should be able to eliminate the behavior you are getting. Nice thing going this route is you will be able to drop the driver in and use the same child devices, that is how I am currently developing it.
Once I get the color child implemented all the way I will see if I can replicate your issue with the system driver, then switch to my custom one to see if its fixed / fixable.
This is a fun little project, the most complex driver I have worked on yet.
2 Likes
Getting very close to having this done. Sneak peek at a feature I just added:
When off (default) it will send the color/white all in one command so its an instant flip from one to the other. Working pretty slick in my testing.
Next one to finish up tomorrow:
Nice, love it!
I wouldnt have thought I wanted the first feature, but...thinking about it, I currently have no use-case for using both at once. Will this still have the 'fade out' ? its probably not a big deal.
As long as it doesnt create a race condition if a rule is using both the Activation of one and the Condition of the other.
I think it should use the default "ramp rate" you set in the settings on the new driver.
We can find out today, I should be posting this soon on another thread.
1 Like
So if you flip from white to RGB with that settings off, the change is instant. Are you looking for it to fade from one to the other? I might be able to do this once I add the duration support to the color commands. Otherwise, I might able to be able to send two separate commands, one to turn one off and another to turn on, this may result in a fade out/in at the same time. I will have to play with it. It does sound cool for transitions!
@jercloud @waterboysh @ywavebee
Driver is posted and ready for testing:
1 Like
It would be "nice"...gradual light changes are always better. But....function and stability first 
Yeah I definitely see how that would be nicer looking. I will check that out I am sure its possible especially if its being done on the system driver. I was doing most of my testing with the ramp rate set to Instant so I did have to wait for the fades!
I think I have discovered what is going on when the level decreases over time. If you turn it off and it is fading out with the set ramp rate and then interrupt that by turning it back on, it will just keep the level it was at in the fade out. The setting I have that forces the device to 100% fixes it, and you can still adjust the channel brightness. I might also be able to further fix it by using the level on the main device when setting the "last" level, instead of just letting the device determine its last level.
That is certainly part of it. And that does kind of make sense, though I dont know why it wouldnt work that way for other dimmers that have a ramp-rate, like standard Zooz Dimmers. Or is it a result of having a child-device?
It's also not the ONLY problem. Cause even if I just trigger "toggle 100%" and do it over and over, sometimes i will get confused with the max level.
So without seeing your driver yet, you're saying that "Color" is fixed at "100% level", and you control brightness by choosing a darker color? And then White is controlled completely independently (if you select that option in the driver)?
Sounds like it would certain be an improvement.
Yes, as it is right now, the white level is controlled on the child.
I am working on making it all controllable from the parent as well.
Did you see the link up above where I posted the driver? Guess I did not really say anything about it I just posted the link (edited post above now) [DRIVER] Zooz ZEN31 RGBW Dimmer Advanced
Figured I'd post here instead of the driver thread since it's not at all related to the driver. But I am just adding some data. When I first posted about this issue 2 years ago everyone convinced me it was likely the power supply. Zooz support said the same thing.
I have 2 of these devices. One under a bookshelf and one under a dresser. Both are activated by motion most of the time. Google Assistant or a dashboard sometimes as well. I recently power cycled the one under the dresser and it looks like this.
Screenshot
The one under the bookshelf I have not power cycled specifically because I wanted to look at this data. It looks like this.
Screenshot
So I am seeing what you are describing. I think. The parent/child structure of this device has always confused me. If I want to set the color, do I do it via the parent or the child? When I set it up, I apparently decided on the child. I added both child devices for the color dimmer to a group so I can control both at the same time.
The point I'm making is that this group is the only way I control these strips. I do not have a single rule or app using the parent devices. But yet, the parent device's level has somehow dropped below 99 to 72.
I was able to use the SetLevel command to put it back to 99. However, right now I'm at work controlling it remotely, so I'll see how the light physically looks tonight when "potty mode" engages and see if it's still really dim like it was last night.
EDIT: This is with the stock driver I should add. I'll be trying your driver soon.
The system driver only has one "color" child that acts as an RGB device and one dimmer for the white channel. Did you add both the color and white to a group or do you somehow have two color child devices?
Oh also... I am very close to having a new version that should also allow full control from the parent device. So you hopefully wont need that group setup anymore. But the child devices will still work as well.
Ideally, I wish it was 2 completely separate devices with their own levels.
- A Dimmer
- An RGB "bulb"
