I’m curious about the range of values for Dimming Speed and Ramp Rate. The allowed range is 0-100 with a default of 3. Lower numbers are faster fades and higher numbers are slower fades.
The factory default value of 3 is pretty low in the scale of 0-100 which should still be a relatively fast fade if 1=fastest and 100=slowest. However, 3 seems pretty slow to me and from many comments in other topics it seems like people generaly set it faster (values 1 or 2) but never slower (higher than 3).
I experimented setting it to higher numbers like 25 or 50 and they seemed like eternity. Even 10 was painfully slow. So I’m very curious what is the use case for a range of 1-100 when 1-3 seems to be the only practical range. It makes me wonder if there is a scaling or ‘factor-of-10’ error in the firmware. There is not much granularity in rates from 1-3. Basically we only get 4 settings 0=no-fade, 1=fast, 2=medium, 3=slow; even though there are a possible 100 different settings.
Bottom line, something just seems off here and I’m wondering what others think about this.
I don’t think the zwave specifications allows for partial-second resolutions on dimming speed or ramp rates. I totally understand your point (who would possibly want a 100 second dimming speed?), but Inovelli might not have a choice in the matter.
You know @mamber, I’m actually glad you brought this up – I’ve never understood why we have this at all lol.
@EricM_Inovelli – if we’re able to free up some memory here, could this be an area that we cut (ie: maybe we go up to 5 tops)?
@jtronicus is always on point with his answers, so my hopes are not high that we can do anything, but I’m glad this was brought up. It was one of those things that I thought of a long time ago, but forgot about it tbh.
Yeah, I agree with you here. The programming behind this is likely factor based. So once the programming is in place, any integer can be put into place 0-100 to get different results. @Eric_Inovelli that means changing this setting won’t really free up any space. In the future we can explore having the setting be in 100 milliseconds. So:
This will allow for more precision and be more useful to more customers. Although I know there will be at least one guy mad at us because he liked to have his bulb fade over 100 seconds.
It would need to be verified if that restriction applies to default dimming and ramp rates at the physical switch versus commanded fades via the z-wave MultilevelSet command. I did notice that the device driver has some code to enforce the duration encoding for the SetLevel WITH duration parameter. But this is different than how the switch ramps on/off or dims up/down via physical control at the switch. We know that different brands have different ramp rates, and some (most?) of the others are not settable like the Inovelli, so I’m not convinced this zwave specification applies to these rates. I think it only applies to zWave commands WITH a duration parameter. In other words, this zwave command:
zwave.switchMultilevelV2.switchMultilevelSet(value, duration)
Agreed, The restriction might not apply to the physical button presses. However, that could mean it causes problems when the switch is controlling another device via association. Ideally, the dimmer would be sending duration values to associated devices so that the dimming speed/level on the associated device stays in sync with the dimmer itself.
In addition, the Switch Multilevel Report v4 Command Class has a duration value. I am not sure if the dimmer is using v4 of this command class or an earlier version, but if it does support v4 it should be sending the duration value to the hub when controlled locally.
Im not saying what you are asking about cannot be done though (Inovelli/the developers would be the experts here). This is just my educated guess from looking through the Software Design Specifications. If it can be done, that is great, but we need to be careful about causing other downstream issues.
I can’t believe the timing. I was just saying last night to my wife how it would be SO NICE to have some resolution (meaning options) that are between 1 and 2. Alas I don’t know z-wave standards, but worth asking FOR SURE.
I like the milliSecond increments idea and that should be relatively easy to implement. Since its a 1-byte value it could go up to 254 (255 may be reserved) which would be 25.4 seconds. The one guy that wants 100 second fades can still do that via the switchMultilevelSet(value, duration) command.
+1 on the idea of changing the units of the dimming and ramp rate parameters from seconds to deciseconds, if it can be done without breaking other things. This is something I thought would be a nice improvement as soon as I was setting up my dimmers, but I never mentioned it here. If you can’t do it on the red series dimmers for whatever reason, perhaps you could do it on the blue series?
If you do implement this, you’ll definitely need to tell people to change their configuration after updating the firmware, since otherwise the lights will start fading 10x faster.
Years ago I worked as a theatrical lighting technician and light board operator. Most fade times would be set to a whole number of seconds, but sometimes you just needed something in between. Fortunately most professional light boards would let you set a fade time of 1.7 seconds or similar.
I know this is an old thread, but I just came across it and figured I would chime in with my use case to advocate for much longer dimming speeds.
I have two properties, one with Leviton DZ6HD dimmers and the other with Red Series dimmers. The Leviton dimmers include instant on (0), 1-127 seconds (1-127), and 1-126 minutes (128-253) dim speeds.
My Leviton dimmers are set at a 2 second dimming speed, BUT I do use the longer dim speeds in scripts. For example, I have “dumb” warm dim recessed LEDs installed throughout the house. During the day the family room lights might be on at full brightness, but as we approach sunset we want the lights to dim to 50% for a warmer color temp.
In order to make the transition less noticeable I run a script at sunset that:
Sets the default level from 99 to 50.
Checks if the family room light are on.
If the family room lights are on, temporarily sets the dimming speed to 45 minutes.
Sets the family room lights to 50%
After a 1 second delay, returns dimming speed to 2 seconds.
Once the script runs at sunset, the family room lights slowly dim from full brightness to 50% over the course of 45 minutes. I love it and wish I could do the same with my Inovelli dimmers.
Z-Wave and Zigbee allow you to send the command with a dimming duration. So if I am reading that correctly you could replace steps 3, 4, & 5 with this:
SetLevel(value: 50, dimmingDuration: 2700)
That should work, but I haven’t tested a duration of that long.
When the 800 series switches are available, one of the ones I plan on buying will be put in my bathroom. I plan on setting the ramp rate so my lights slowly come up while I’m taking a shower in the morning to make the adjustment easier for my eyes. I’m not sure just how long it should be, but probably 2 to 3 minutes.
I’ll see if we can change the value to 2 bytes and make it 0 - 32767. That would make it able to go up to 3276700ms, which would be 3276 seconds (or 54 minutes).
Or another option is to do something like:
0-40 in ms, (0-4000 ms)
41-100 in seconds, (1-59 seconds)
101 - 127 in minutes (1-27 minutes)
Or even a combination of the two. Just thinking out loud . . .
Curious why 7 bits (currently) and 15 bits (proposal) are being used. Any reason not to use all 8 or 16 bits? With the new proposal you would have 65535*100ms (~109 minutes).
Anyway I came here to say I use long transitions time for wake up in the morning.
Another option would be to use scripts to set levels over time every minute or 5 minutes.
I use Adaptive Lighting integration with Home Assistant and it does this really well. Levels to 100, then color to high Kelvin, then color to low Kelvin, then reduce dim level.
I use this for both “on” lights and default z-wave and local settings.
We are using signed integers which the first byte is used to indicate negative vs positive. This is for backwards compatibility with older hubs that are expecting that. I’ll check with the Z-Wave engineer though to see if that matters anymore.
