Nice, good to know – thanks for being on top of things lol!
I have a message out to the manufacturer to see where the discrepancy lies.
EDIT: Just confirmed with the manufacturer – apparently there is a mistake on the Z-Wave Alliance website as this was not included in their firmware. Apologies for the mixup.
I had figured this was the case but wanted to check if there was something I was missing. Glad to see others had found it too.
This functionality would be nice to have since we have experienced some long power outages lately. This has resulted in lights that use the “Restore Last State” option turning on in the middle of the night when power is restored.
We can certainly create this firmware – it should be an easy fix. I’ll talk about it with the team tonight!
Hey Eric! Have you had a chance to discuss this one with your team by chance?
Are there any plans to add an adjustable ramp time to the bulb? I love the bulbs but I hate that they turn on soo… veryy… slloooowwwlyyyyyy…
Which hub are you using? The SwitchMultiLevel command has a duration option that can dynamically adjust the speed of the bulb turning on / off. For example you can send a SwitchMultiLevel command with a duration of 0 and it will be instant. You can send it with a duration of 30 and then truly see how slowly they can turn on. 
HomeSeer. There’s an option for dim speed and I assume that’s what it does (SwitchMultiLevel duration) But most of my control (95+%) happens from Inovelli Red dimmers via Z-Wave association. And they don’t appear to send a duration- if the light is on and I tap the bottom paddle, the Red has finished its fade down animation and is at idle (whole bar dim blue) a good second before the bulb hits 0%. Same thing with tap and hold to dim- the Red switch hits the end of its dimming range long before the bulb does.
The option to adjust the on/off dimming speed in the firmware would be nice so we could match the dimmers when using association between the bulb and switch.
Agree and third the cause here!
I’m using Hubitat and the bulbs do not report the current states back properly. Has anyone else had this issue? Great example, for Halloween, I had one of my outside bulbs red. The color state never stated red. I don’t remember the name honestly, but it was…horizon maybe. Just wondering if its me or a known issue.
Which driver are you using (and which firmware)? Firmware 2.30 does not report the color status unless requested. The driver should request the reports if firmware 2.30 is installed.
@EricM_Inovelli Any chance we can get an alternative firmware to help with insecure joining these bulbs?
Join Inovelli Lzw42 insecure - Support - Hubitat
TLDR: Hubitat defaults to the highest supported security per the Z-Wave SDK. There is no option to avoid S0 use without a hacky timing workaround.
An updated firmware with S2 support or without S0 support would solve this problem. Pretty please 
Yeah, we have asked the manufacturer to provide a firmware that does not have S0, but they have been busy on other projects.
To make sure, the prompt that pops up when you include a z-wave device with the C-7 does not pop up with the bulbs?
@EricM_Inovelli Correct. My understanding is that only opens for S2 devices. The hub automatically selects S0 if that’s the highest supported encryption.
I’ll migrate my bulbs back to the C4 hub pending an updated firmware release. The response times with S0 have been affecting WAF scores…
Yeah, I think there are some issues with S0 & the C-7. Hope that they get them resolved.
My understanding is the z-wave sdk or something requires it be implemented in this manner. @bcopeland could likely explain it better.
The C7 is my first hub, and the S0 only bulbs have been the reason I can’t get my gf onboard with more automations. A “no security” or an S2 option is the only thing that will let me take all my bulbs back out of the box.
@jebowers I used a method I found on the Hubitat forums to pair my bulbs with no security on a C7. If you start the inclusion timer and turn the bulb on for 3-4 seconds, then off for 2-3, then back on for 3-4, then off for 2-3 and repeat until the device starts to initialize it should pair the bulb but fail the security handshake. Worked for all 3 of mine, it may take a few times to get the timings right but it was pretty easy for me.
@EricM_Inovelli I’m having the same problem. LZW42 dimming speed is fast when controlled directly from the hub, but is very slow when controlled by the dimmer via direct association. In my case, if I start with the dimmer at 100% and hold down to dim to about 10%, it takes the bulbs another ~3-4 secs after I release the dimmer to reach that level. I currently have this setup on Smartthings and Hubitat C7 (I’m mid transition to C7) and behaviour is identical on both hubs. Bulb and dimmer firmware are both the latest (2.30 & 1.48).
Is there any possibility of a dimmer firmware update that allows the bulb speed to match the dimmer when using direct association?