Same bulbs, start raising and start lowering dimmer via rule machine is broken due to a communication issue with the new Advanced Zigbee CT Driver. Basically, you can turn on the bulb via rule machine but the device driver has NO idea what the level is, hence it cannot start raising or lowering it. No refresh either on the driver. Ill turn off a bulb, and hubitat will tell me its on at 20% with some weird temperature. Hubitat usually releases 1 or 10 hotfixes after a release so crossing my fingers its a known issue. Going back to the Generic Zigbee CT (Dev) driver works as expected with correct bulb information shown.
Edit: If I manually set the bulb to 100% in hubitat, THEN start lowering it works sometimes, but then when the bulb turns off it still registers as on in hubitat. Old driver works as expected.
Well I have some light switches (zigbee wall mounted). I have rules set up for using them, Push On to turn on, Push off to turn off, hold 1 to start raising the dimmer, hold 2 to lower dimmer, of course, release action is stop dimming.
This works great with the Generic Zigbee CT (Dev) driver for my bulbs. I switched to the new Advanced CT Bulb Driver, and configured, that went smoothly, and all was good (I would say response times were a lot faster but maybe that's just because I had JUST rebooted). I try to raise and lower the dimmer, no luck. I check my device dashboard and what do I see? (Below is the light at 100% then turned off):
Now, this can say a lot of different things in my testing, none correct I switch back to the old driver (generic ct dev) and communication is restored, everything is back to normal.
Iāve never been able to ramp up/down a group. That capability isnāt presented on the device page which is why @aaiyar requested the ability to do this with zgm on the group device.
Unless bathroom lights group is an individual light.
I know the the driver works for this when individual bulbs are selected for raising and lowering the levels. I have quite a few set up like this with Sylvania and Sengled RGBWs.
I use the generic ZigBee RGBW light driver for my OSRAM LIGHTIFY A19 RGBW bulbs.
Would I be able to now use the new advanced OSRAM driver ?
What are the benefits ?
There are more options (preferences in the driver) and the communication to the bulb is likely more optimized, only sending commands it needs to or maybe in a different order than the Generic drivers. Mike can speak to that more. In my experience, these work reliably when you have a significant number of directly paired bulbs (controlling one at a time before rarely failed for me) when the Generic ones were not consistent for me.
You need to try it and you will see. I started with just one group of lights and decided it was worth it to lose the color prestaging š„². So I have switched over the rest of my Zigbee lights to it. Itās a lot more customizable and has power failure recovery options.
Is the āpreset levelā basically ālevel prestagingā that works? Iām glad to hear you have had good luck with these. Of course I have replaced half of my Sylvania A19s with Hue RGBWs at this point, but I probably would have anyway. Itās also nice to be able to ramp down the Sengleds without them shutting off (that was so annoying).
I have ways to avoid that already, but that definitely seems like a good use case for people who want to pre-set levels based on time of day or mode without relying on apps knowing whether prestaging is enabled! My thinking is with my LoMP app that dims lights before turning then off: now I can offload the work of remembering the "real" (pre-dim) level to the devide and not the app as I've long dreamed. Then it won't matter how they get turned back on again.
I switch back to the old driver (generic ct dev) and communication is restored, everything is back to normal.
Going to have to add this to my drivers, I think. I can think of some good uses for it.
