Reproducible Evidence that Zen31 Driver is broken. PLEASE fix this driver?

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:
image

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:
image

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 :slight_smile:

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

image

The one under the bookshelf I have not power cycled specifically because I wanted to look at this data. It looks like this.

Screenshot

image

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.

  1. A Dimmer
  2. An RGB "bulb"

So in this though how would you control the white in Button controller like "ToggleColor"?

You mean two separate devices where one is the dimmer for the white channel and the other device is the RGB? That is the intention of the two child devices but maybe not executed fully.

Probably no easy way to do that, thats where the child devices are handy and why I will probably keep them as an option.

I have 2 of these devices. One under a bookshelf and one under a dresser.

I have the color child device from each set as a group so I can control both strips at the same time. I don't use the parent devices or the white child devices at all.

Ok I missed that part about 2 separate devices. You could potentially switch to controlling it from the parent instead with the next version I am working on, but I don't think it would offer any benefit, possibly would make things more complicated.

One of the options I have on the driver will reset the master level back to 99 every time you turn it on, so that should eliminate the problem of it degrading and having to be reset.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.