Zooz ZEN31 RGBW Dimmer driver with the goal of exposing all advanced features and settings.
If you are using this driver PLEASE like this post Support my work by clicking the Info & Purchase affiliate link below to buy!
Current Version: v0.3.0 BETA TEST Driver does not yet create its own child devices. You must start with the system driver to create the child devices.
Beta Work in Progress:
set Level Duration is not implemented for child devices - will be coming soon
Energy (kWh) reporting not supported yet, Power (W) reporting works.
Device supports some sort of voltage reporting with something connected to the Inputs, not sure how it works, does anyone use this?
Advanced association parameters 154-156 not implemented
Scene control parameters implemented as all on (up to double click) or all off, not sure why anyone would use any other settings? Does anyone need 3x clicks?
Have not added digital/physical switch distinction yet.
Specifically tuned to this device for max efficiency
Events avoid duplicate info logging
All useful device parameter settings are exposed
Smooth transition between changes with fade duration
Control from parent device or child devices
Precise control of each channel with a custom command
Reporting Issues
Please use GitHub to report any issues so each one can have its own conversation and tracking. Please provide as much info as you can including model, firmware and the "configVals" data string. Issues · jtp10181/Hubitat · GitHub
Must PRESS CONFIGURE BUTTON and check all your parameters after changing to this driver.
For the commands like DoubleTap, Hold, etc... It would be a lot easier/nicer in the device page if it was not an open-ended number field but rather a dropdown of the possible values. Since there are only a few and it helps eliminate user errors. I know you are getting these from the capabilities at this time, but you could still make matching command names so it overrides those.
I personally have no need for the energy monitoring but it could be implemented as a Preference so that those people that want it could enable it and those that do not... don't. Or just implement it and some people can ignore it. The only real use case I can think of is if someone adds Rules to detect a possible LED strip fault (if they have a more expensive setup than normal) by determining that the power is too low or too high in certain conditions.
I really dislike having the child devices for the normal Zen31 driver because they do not add any value. If the parent can select the colors needed and the white temperature... why do I need more devices and more complication. Plus it would mean a child device driver is needed as well. I cannot think of scenarios as to when the children would be beneficial. Certainly they never have been for me with the built-in drivers (having to make sure it is On in multiple spots for example).
I don't like this child devices because there is no easy way to swap them.
For the RGB(WW) channels I would like to see 100% separate individual control for each one. For instance, I would like to turn on all channels 100% in order to increase brightness to max possible. All other Color Control shemas could be present in addition to individual per channel settings.
So originally I was trying to figure out the best way to switch from RGB to white, and I think the intention is to use set the Temperature? Is that how other RGBW drivers do it? This is my first true RGBW device. This device has no temperature control so this was throwing me off. So I decided to just try and work with the existing child devices.
If combined there is also no good way to then adjust the brightness of the white channel because the device has an overall brightness as well, on top of each channel has its own brightness. I would probably use setLevel to adjust brightness of the channels depending on which mode you are on, and have to make a custom command to adjust the overall device brightness in case anyone wanted to.
I really did plan to make it all under one device with no childs but due to the way to device is setup it really does make the most sense to separate it into two devices.
I will however work towards figuring out a way to get it all under one device, probably at first it will be a hybrid that has both the parent and child and then possibly after that I could add an option to disable the child devices totally.
You can do that with current driver, Turn on the allow RGB and White Simultaneously setting, then set the Color child to 255,255,255 (white) in the color picker. Then Set the white device to 100%.
I could add custom command where you can pick the channel and set the level from 0-255? Or it could be a separate command for each channel but I try not to create excessive amounts of commands as it clutters up the interface.
I am EE with many years of experience. Basically all my designs had LEDs with PWM Brightness Control options. My point is - Driver should provide an individual control for each LED. That is it. All that Color Setings should be moved to the Application level.
Just my opinion.
Not sure if I like the name of this command but I could not come up with anything. It is working though (not posted yet). You can pick from any of the 4 channels. Still working out some other things before I post an update.
So I am working on making the main device have full control. I am at the same dilemma that made me want to go to the child devices. What am I going to set to the "level" attribute. I could set the main device level as a new attribute, levelMain. If only RGB is on I could set 'level' to the overall RGB level. If only White it on, could be set to the scaled level of White based on its value. The problem is what if RGB AND White is on together... not sure what the heck to set the level to. You could possibly have RGB at full brightness in any color combo and white on at only 25. Maybe I just have to make white a separate attribute. I will have to see how this interacts with dashboard tiles as well.
Couldn't the main level be an adjustment on the RGB and W levels? That is the way it works on for some of the WS2812 libraries I have worked with over the years. So if someone wants pink, they turn on R and W at 50% and B & G are set to 0%. Then they could brighten and dim both using the overall setLevel. So if you set that to be 100% you get R & W on at a visual level of 50% and B & G at 0%. Set it for 50% and you get R & W looking like 25%... but the B & G are still off.
Yes, that means you will have 5 levels overall... but that setChannel you show makes that pretty easy. So you have:
level = overall device level
levelR (or level_R, or whatever nomenclature) = Red specific level
levelG = Green specific level
levelB = Blue specific level
levelW = White specific level
Ignoring all that and just having one overall level. You already need to be able to set each "color" (RGB+W) from 0 to 255 (or 0 to 100, I forget which the Zen31 prefers). So if someone sets R to 100 and W to 100, with B & G to 0, they are going to get a pink color. If they then adjust the overall "level" value you get from dim pink to bright pink (affecting both R & W). How much more is needed/possible? If they do not want it to be white anymore and shift to red, they can zero out the W value.
What is a resolution for the PWM value per channel?
Is it 8-bits or something else? For the LED lighting application 8-bits is more then enough. In all my designs I am using 24-bits for RGB and 32-bits for RGBW. Another words single hex value 0xRRGGBBWW represents full scale control for color/brightness. Behind the scene the SW (in my case HW) redirects correspondent 8-bits to the appropriate channel. So far all SW engineers I worked with lowed this very simple control for Color LEDs.
Yes your option 1 would work and what I am leaning towards right now. I think maybe I am just trying to hard t0o make this fit into the constraints of the defined Hubitat capabilities, and have this function like a RGBW bulb. Going to throw that out the window I think and just make it work good.
Yeah I get it but I am trying to work out how to display things to the user, needs to be something most people will understand. I had to look up what PWM was the first time you mentioned it myself. What complicates it more is that not only do you have the PWM value for each color channel, but then the device has an overall level of 0-100 like a traditional dimmer would have. The level is totally separate from the PWM values.
I like having the granular control of each channel, especially when it comes to the RGB vs the White. So at that point I could just get rid of the device level, and just force it to 100% all the time. BUT, if someone is going to use this more like a traditional RGB device, they may have it set to a certain color combo. and then simply want to dim it via a dashboard or voice command. For that to work the driver needs to take setLevel. I could at that point just take the current RGB, convert to HSV/L, adjust the level, then convert back to RGB and set it. BUT there is more, if the white is also going at the same time what do I do with that? Thats where it gets really messy. Everything is setup where you either run RGB or W, not both together.
Something will come to me... its good to talk thought it, gives me ideas sometimes.
Keeping it applicable to the users is a key trick. There are a LOT of users for Hubitat (and more all the time) that want it simple, easy to use, and easy to understand. There are also many users that love to tweak things and want the utmost in control. Finding the balance can be difficult.
Sometimes you have to go with the "easy mode" stuff first, then eventually add the more advanced stuff as time allows. You can even add them under a preference to "Enable Advanced Mode".
Speaking of keeping some things hidden... I think a lot of the preferences shown in the driver are of the "set it and forget it" variety. Maybe have a preference to hide/show most of them? That way when someone has set what they want they can hide them away and clean up the page a bit.
No, level simply scales PWM value. Something like PWM=2.55*LEVEL.
For LEVEL=0 ->> PWM=0; For LEVEL=100 ->> PWM=255;
0xRRGGBBWW gives you very granual control for each individual channel.
What is wrong with lightning RGB and W together?
I am using this left and right for increasing brightness. And because many (if not all) controllers (maybe not a HW but drivers) I tried are "too smart" not to allow lightning all channels at the same time all they are now in a drawer. I replaced all my RGBW LED Strips with Pixel LED Strips driven by Pixelblaze. The result is - now I have full control of each individual RGBW channel for each LED (Pixel).
I still have one RGBW LED strip (bathroom vanity) driven by ZEN31 with built-in driver. I did active what I wanted but I had a very hard time to do this.
100% agree with the above statement.
Actually providing individual full control for each channel is a simplest way to deal with Color LEDs. At the end all other methods produced individual PWM values for each channel but behind the scene.
I have not had a chance yet to install the driver but thought I would chime in about the colors. I don't know if this is handled by Hubitat (or maybe even Google) converting a color name to a pre-defined color range of if the driver is involved or not. I just want to make sure I can ask Google to set the color to blue or pink (technically they prefer the aqua and hot pink colors) or else my 3 and 5 year old would probably boycott bedtime
That totally gave me a chuckle and flashbacks. My youngest (at that age) was the same way. Less so now, but if the colored nightlight she has now dies I will definitely have to build my own as a replacement. She is just so used to it after the time of trying different colors until she found "the one".
I do not care about these features at all personally. But I did want to let you know that when using the stock driver, it seems to not follow what you have set. I've got them all set to disabled.
But I noticed in the log when I was watching it earlier it showed me after setting the level back to 100, the device is reporting 0.7W and then after turning it off was reporting 0W.
Just letting you know in case it's a situation like the Zen25 where you have to use the basic zwave driver to set a parameter not exposed by the stock driver to actually disable the reporting.
I don't know which parameter those option correlate to, but here is my State Variables list in case that's helpful.
I'm looking forward to trying your driver later this week. It's tough to test for me because it's in the kids bedroom and their bedtime is around 7:30 and I don't want to do anything to disturb their sleep.
This should still work, the external devices are going to convert the color you ask for into RGB or HSV values and send that to the hub via the setColor command. The setColor should work the same as it does on the system driver. So you should get the exact same colors.
This is also great because we have feedback from both ends of the spectrum. 1) I just want to tell my voice assistant a color and brightness and it works, and 2) I want to control each RGBW value precisely and separately via Rules. Hopefully I can satisfy the full spectrum of control all in one.
There is apparently now way to stop those specific reports, even with every power reporting parameter disabled it still feels the need to report the power when you turn it on and off.
Using this driver now, and it's mostly good so far. I did have one issue last night where I couldnt actually get my light to shut off from my Button controller Toggle. I havent had time to figure out why just yet.
this post
Support my work by clicking the Info & Purchase affiliate link below to buy!
Driver does not yet create its own child devices.
Beta Work in Progress:
Supported Products:
Features List:
Reporting Issues
Find on Hubitat Package Manager (HPM):
Zooz ZEN31 RGBW Advanced Driver 
Donations: ---->>>> PayPal.Me <<<<---- 
Never required, always appreciated!
