So I spent quite a bit of time yesterday looking into all of this (and related topics.) I’ll try to summarize what I found.
First, for a z-wave light/dimmer that can take a while to turn on or off it’s a good idea to add an entry like the following in configuration.yaml:
zwave:
usb_path: /dev/zwave
network_key: !secret zwave_network_key
device_config:
light.family_room_lamp:
refresh_value: true
delay: 3
The important part for this discussion is refresh_value and delay.
Basically, when turning a light on or off, after HA sends the “set level” command to the z-wave device it immediately sends a “get level” command, which is what it uses to update the entity’s state. (In my case there was about 30 msec between these commands.) If the device doesn’t change immediately, you’ll see the wrong (i.e., stale) data (which will “stick” if you don’t have polling set up for the device.) So setting refresh_value to true (the default is false) tells HA to send another “get level” command after a delay to update the entity’s state (& attributes, like brightness.) The default for delay is, um, well, the documentation says 2 seconds, but the code seems to have it as 5 seconds. If you need a longer or shorter delay, then add the delay parameter with a value (in seconds) that will work for your device.
Next, only some light devices support the light.turn_on service’s transition parameter. For z-wave lights, only the ones that implement index 5 (INDEX_SWITCH_MULTILEVEL_DURATION) for command class 38 (COMMAND_CLASS_SWITCH_MULTILEVEL) do. In any case, you can tell by looking at the light entity’s supported_features attribute. If transition is supported the bit corresponding to 32 will be set. In my case, supported_features is 1 (for supporting setting the brightness level.)
So now for the device’s z-wave node config parameters. For at least these GE/Jasco devices, 7 & 8 (and maybe 11 & 12) are the important ones for z-wave control. I won’t go into the details, because @squirtbrnr already provided a very good explanation above.
Now, taking these parameters into account, you can figure out what delay you should put in configuration.yaml for the device. Using the default config values of 1 & 3, this translates to a turn on/off time of 2.97 seconds.
Lastly, to explain the “in some cases the light takes the expected time to ramp from off to on or from on to off, but sometimes it changes immediately” behavior:
Well, normally when you turn the light off, or turn it on while specifying a brightness, HA translates the light component’s concept of brightness (0 to 255), or brightness_pct (0 to 100), to z-wave’s concept (0 to 99.) But when turning the light on while NOT specifying a brightness, HA sends a special level value of 255. This tells the light to come on to the level it was the last time it was on.
Now, with that in mind, when you turn the light off, level 0 gets sent to the z-wave device. At least in the case of my specific GE dimmer, it implements that by ramping to off using the step/rate config parameters. And when you turn the light on without specifying a brightness level, 255 gets sent, and (again, in the case of my dimmer) it implements that by ramping to the last on level using the step/rate config parameters.
Now here’s where the different behavior comes in. If you turn it on while specifying a brightness level, the corresponding value between 1 and 99 gets sent, and in this case, the dimmer implements that by immediately changing to that level! I can only assume they chose to implement it this way so you can control the turn on by sending a sequence of levels. If it ramped to those levels instead of changing to them immediately, it might mess that up. Anyway, that’s how it seems to work.
Now, finally, @nateybobo, I think what you need to do is:
- Pick step/rate values that cause the dimmer to change in the time you’d like. The last values you mentioned (3 & 7) are almost equivalent to the default values (1 & 3): i.e.,
(99/3)*7*10msec = 2.31 sec which is about the same as (99/1)*3*10msec = 2.97 sec. If you want a time of, say, 10 sec, then maybe pick values of 1 & 10 ((99/1)*10*10msec = 9.9 sec), or even 9 & 91 ((99/9)*91*10msec = 10.01 sec.)
- Add
refresh_value: true and delay: xx to your configuration.yaml, where xx is big enough to account for the values picked above.
- Only turn the light/dimmer on WITHOUT a brightness level, or off. Otherwise, if you turn it on WITH a brightness level, unfortunately, the delay won’t happen (assuming your device works the same as mine.)
But, assuming you DO want to use a brightness level, then I’m not sure what you can do to smoothly make the dimmer transition to that level. I suppose you could try calling the turn_on service a bunch of times in a row with varying brightness values, but I’m not sure how smooth that will end up.
P.S. Sorry for the long winded explanation, but it turns out this was a bit more complex than expected and I wanted to document what I found, at least for myself. 
.