I am trying this: service light.turn_on
{
“entity_id”: “light.living_room_light_switch_level”,
“brightness”: “15”,
“transition”: “3”
}
But the light turns on immediately. It is a brand new GE Jasco 12724 dimmer switch. Has anyone gotten theirs to fade on and off?
I have a GE Z-Wave Plug-in Smart Dimmer 12718 and I just tried it. It doesn’t work with that either. Looking at the zwave code, it will print out a debug message to the log if the dimmer does not support transition times. Here’s what I see in my log after trying it:
2018-04-25 21:02:54 DEBUG (Thread-11) [homeassistant.components.light.zwave] Dimming not supported by light.family_room_lamp.
The interesting part is, if I don’t specify a transition time, it actually fades on and off, taking about a second or so each way. But if I specify BOTH a transition time AND I a brightness_pct, the light actually goes on immediately. Weird!
Edit: After some more experimenting, and code browsing, I realized the transition parameter had nothing to do with it. It was whether or not I used a brightness level that mattered. See (WAY) more detail below. 
Lucky you, mine don’t fade with the light.turn_on service call. I don’t know why. They fade with the actual switch toggle, here:
Because I have this:
But not with the service call or scene
My lights do their transitions I think. I have a couple automations that tell lights to go on at certain brightnesses. then again, the light.turn_on service with brightness might actually tell the light to go to that brightness immediately.
You might want to check the actual dimming step parameters of the dimmer. There are 3 sets of 2 parameters. the sets of two are for remote command (z-wave), local command (physical switch), and an “all” command. the two parameters for each set tells the light how many levels per step (1-99) and how long each step should last (1-255) in 10ms increments. for an almost immediate on/off you set the levels per step to 99 and the step time to 1. this means the light will toggle in 10ms. conversely, if you set levels per step to 1 and step time to 255 you can have the light transition take ~252 seconds (99 steps x 2.55 seconds per step).
Same results here!
I set all 3 sets of 2 to be the same:
Step: 3
Rate: 7
It makes no difference.
My goal is to create a scene where I go into movie mode…you know, the lights go dim. Not…immediately drop to 15% brightness.
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:
(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.)refresh_value: true and delay: xx to your configuration.yaml, where xx is big enough to account for the values picked above.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.
So does anyone have any info on any zwave switches that DO support transitions? I can go the script route to get long fades, but I’d like to avoid it if possible.
Since I wrote that post (which I believe is all still true and valid), I now have newer Z-Wave Plus models of both a GE/Jasco switch and a plug-in dimmer. I just checked supported_features of the newer dimmer, and it’s value is 33, meaning both brightness and transition! I haven’t tried using transition when turning it on, but in theory, it supports it. It is a GE model 28167. I can give it a try and let you know if you like.
Yes please do! I would like to get some plug in dimmers as well, so that would be helpful information. Still looking to see if I can find an actual in-wall dimmer that supports it as well though.
Thanks!
It does work.
The problem is updating the entity. Per the discussion above, I have polling disabled and a refresh time of 3 sec. So, although the light actually transitions per the turn_on service parameters (i.e., brightness and transition), the entity is not updating when it’s done. E.g., if I set the transition to 10 sec, the entity updates after only 3 sec (i.e., refresh delay), so it only sees an intermediate value and never updates (automatically) again when the transition is complete (i.e., another 7 sec.)
I suppose this can be compensated for by enabling polling so that it does eventually update. The other way is to call the zwave.refresh_node service (using the node_id of the light.)
It’s kind of disappointing that the zwave code is given a transition time, but isn’t smart enough to force a refresh when that time has completed. 
Anyway, I would think any of the newer GE/Jasco Z-Wave Plus dimmers (including in-wall models) support this feature, although I can only vouch for the 28167.
Great, thanks for the info. I actually just bought the GE 14294, so I guess those just don’t support transition 
.
Regarding the issue you were reporting, I had that same issue with the Homeseer HS-WD100+ switch I was using, and was able to fix that by adding this to my config:
zwave:
device_config: !include zwave_device_config.yaml
And then including this in the zwave_device_config.yaml file:
light.homeseer_switch:
refresh_value: true
Maybe try that and see if it helps?
I have refresh_value enabled, but with a delay of 3. I think the default is 5, but I’m not sure. As long as I don’t use transition, it works fine (even when using the default, internal transition time of 2.97 sec as explained previously.) So the problem only happens if I specify a transition in the turn_on service that is longer than the static refresh delay specified in the config.
Why do you say the 14294 doesn’t support transition? Do you have it connected to HA, and is there a light entity for it? If so, check its supported_features attribute. That will tell you if it should work.
Ah gotcha. Yeah I agree that as “smart” as these devices are supposed to be, I wish they would just know to force a refresh.
Yes I have the 14294 added to HA and it has supported_features: 1.
Does your GE/Jasco in-wall switch support transitions?
I only have in-wall switches, not dimmers. Only dimmers would support transition (since it doesn’t make sense for a switch.) The only dimmers I have are plug-ins – one older that doesn’t, and the one newer that does that I was talking about above.
So I’m trying to figure out how I can figure out before buying any more switches which ones support transition.
It seems like what you said is true; only those that implement index 5 for command class 38 do. But how would I know which ones do ahead of time? I figured it was just based purely on the command class/version number, i.e. all COMMAND_CLASS_SWITCH_MULTILEVEL_V4 would support it. But it seems like that’s not the case?
Looking at a site like THIS tells me what command classes a device supports, but that doesn’t really do anyone any good if those command classes are not the same for each device.
Also @pnbruckner if it’s not too much trouble, for my own troubleshooting, would you be willing to take a look at your zwcfg_xxxxxxxx.xml file for me and see what you have for your GE/Jasco 28167? I’m curious what version your COMMAND_CLASS_SWITCH_MULTILEVEL is.
For reference here is what I have for one of my switches I’m testing:
<Node id="16" name="" location="" basic="4" generic="17" specific="1" roletype="5" devicetype="1536" nodetype="0" type="Multilevel Power Switch" listening="true" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete">
<Manufacturer id="c" name="HomeSeer">
<Product type="4447" id="3036" name="HS-WD200+ Wall Dimmer" />
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" mapping="38">
<Instance index="1" />
</CommandClass>
<CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="4" innif="true">
<Instance index="1" />
<Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="22" />
<Value type="button" genre="user" instance="1" index="1" label="Bright" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
<Value type="button" genre="user" instance="1" index="2" label="Dim" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
<Value type="bool" genre="system" instance="1" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
<Value type="byte" genre="system" instance="1" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
</CommandClass>
I’m starting to wonder if it’s an issue with openzwave not currently supporting COMMAND_CLASS_SWITCH_MULTILEVEL v4.
No problem:
<Node id="9" name="Master Bedroom Nightstand Lamp" location="" basic="4" generic="17" specific="1" roletype="5" devicetype="1536" nodetype="0" type="Multilevel Power Switch" listening="true" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete">
<Manufacturer id="63" name="GE">
<Product type="5044" id="3038" name="28167 Plug-in Smart Dimmer" />
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" mapping="38">
<Instance index="1" />
</CommandClass>
<CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="2" innif="true">
<Instance index="1" />
<Value type="byte" genre="user" instance="1" index="0" label="Dimmer" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
<Value type="button" genre="user" instance="1" index="1" label="Bright" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
<Value type="button" genre="user" instance="1" index="2" label="Dim" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
<Value type="bool" genre="system" instance="1" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
<Value type="byte" genre="system" instance="1" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
<Value type="byte" genre="system" instance="1" index="5" label="Dimming Duration" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
</CommandClass>
Looks like it has index 5, Dimming Duration:
<Value type="byte" genre="system" instance="1" index="5" label="Dimming Duration" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
Excellent thank you!
Yep, and I am getting more confident that it’s because that switch (only) supports v2 of COMMAND_CLASS_MULTILEVEL. I think only those devices that have v2 or v3 will work.
Looking at the github HERE makes it seem as though it sets the indexes based on the version of command class, and there is nothing for v4.
There is also an open ticket to add support for v4 HERE. Looks like it was merged into dev but still not live in HA maybe???