startLevelChange rate of change

Is there any way to change rate at which dimming or brightness increases when using the startLevelChange option for drivers that provide it?

I have a variety of bulbs and I find that the rate of changes is faster than I prefer. I am coordinating some hubitat controlled bulbs (Ikea, Inovelli) with some zigbee2mqtt controlled bulbs (Ikea). I find that zigbee2mqtt allows me to control the rate of change for the equivalent commands. For a situation where there is are a mix of bulbs, it would be nice to have the same level of control over all bulbs.

Maybe I am missing it, but I suspect that I may really be asking for driver customization that unless someone else cares I may have to do myself (which will mean a long wait).

I hope someone can point me in the right direction. At the moment the bulbs are using the following drivers:

  • Inovelli Bulb Multi-Color
  • Inovelli Bulb Multi-Color (custom driver from Inovelli)
  • Generic Zigbee Bulb
  • Generic Zigbee CT Bulb (dev)

Increase the transition time:

which type of bulb is this and which driver as I am not seeing transition time in my view.

The Zigbee CT driver should have it. I don't know about the others. I have mostly Zigbee RGBW bulbs. You could try the Sengled element classic for the Generic Zigbee bulb.

1 Like

I see it in Zigbee CT driver, but it doesn't seem to modify the actual behavior. Thanks for the suggestion.

Do you mean transition to on/off, or dimming up/down? If you mean on/off, you might try the Sengled element classic for the white zigbee bulb, and the Element plus for the CT zigbee bulb.

Some drivers provide an option for this. I had a hard time remembering a stock driver that did, but eventually found the RGBGenie Zigbee Micro Dimmer, which does:

Screenshot of "Start level change" rate driver option

It's usually called something to do with "level change rate" and I think was something they were contemplating adding to more drivers where the devices also supported these options, but I'm guessing it isn't/wasn't super-high on the priority list. There may be more devices with similar options. (I know I added it for Hue bulbs in my custom Hue Bridge integration, for example; I'm not sure what other community integrations have done anything similar.)

There is often a lot of confusion about what some driver options do. The "Transition time" option usually just provides a default transition time (duration) for the "Set Level" command, which has two parameters: the desired (destination) level and the transition time. The transition time, however, is optional, and the default will be used if not specified as part of the command. That's the extent of the effect of this preference; it does not affect on/off or "Start Level Change" commands, or at least I'm not aware of any stock drivers where it does. The convention above seems to be the one Hubitat has started (but definitely not finished) establishing for the latter command. If it's not there and you don't have (or want to write) a custom driver, there is likely nothing you can do about this--all assuming the device supports it in the first place, which is the other concern.

1 Like

Thanks for the very thoughtful reply. Unless someone comes along and contradicts you, you have confirmed what I suspected. That is that first the device itself must support what I want. In the case of Ikea bulbs I know it does because it is implemented on zigbee2mqtt. And then second, if the driver doesn't support it, then create a driver that does support it.

For the second point, just like anyone else that could write a driver, I would have to decide if the capability is worth the time and effort to write such a driver.

I guess an alternative option is deciding what are the important capabilities/attributes for my situation and ensuring the device/driver supports it before purchasing that item.

I think it is ironic that all platforms have to set priorities on what to focus on and that this capability is supported by a competing zigbee platform and will likely only become a Hubitat priority if many people start choosing it over Hubitat (very unlikely) and yet the mismatch in capabilities is one of the few things that might drive someone like me to consider the competition (to the extent an free, but not zero-friction to work with platform is competition).