[BUG?] Association not sending 'duration' parameter with MultilevelSet(value,duration) commands

Lighting Firmware Discussion
1

I believe this is a bug in all existing versions of Red Dimmer firmware

When a z-wave association is set up with Groups 3-4 (dimming events) and the Source (master) dimmer is issued a MultiLevelSet(value,duration) command with the optional ‘duration’ parameter it appears to only send MultiLevelSet(value) without the duration to the associated dimmers. The Destination (slave) dimmers adjust to the value level at their own default rate, not the duration that was issued on the master.

2

The dimmers are actually sending a duration value, but the value is always “255” which instructs the device to use its own default level.

Ideally, the dimmer would send a duration value based on the dimming speed parameter (when controlled locally or when a duration value of 255 is received via zwave), or based on the duration value received (when the value received via zwave <> 255)

3

Thats good info, but also begs the question: why is it sending 255? Are you seeing that with a zniffer (zwave sniffer)? I could see that the slaves (associated destinations) were not using the duration issued on the source. But I did not know it was sending 255 since it was behaving the same as if no duration was sent at all (uses its own default duration)

Agreed, and that is not what appears to be happening (bug).

4

Yep, whcn controlling the dimmer locally or via zwave, it is passing the information to associated devices using a duration value of 255:
image

1 Like
5

I know this thread is a couple months old. But I’m quite conviced this is a bug in the firmware and would like to get an official response from Inovelli @Eric_Inovelli @EricM_Inovelli @JasonL_Inovelli . I believe it an easy fix since its simply the wrong value being passed in the association command.

In summary, with Group 3 Association, If the Source device is sent a zwave command to set the dimming level with a duration, that command should the also be sent via association from Source device to Destination device with the same ‘level’ and ‘duration’ values as in the original zwave command. Currently the Inovelli firmware sends the correct ‘level’ but always sends ‘duration’ as ‘255’ instead of sending the duration value that was commanded.

Flow chart of what CURRENTLY happens:

  1. Hub sends MultiLevelSet (0,120) to Dimmer#1.
    (This tells it to slowly fade off over a 120 second duration)
  2. Dimmer#1 sends MultiLevelSet(0,255) to Dimmer#2 via association
    (this tells it to slowly fade off using default duration - typically 3 seconds)
  3. Master and Slave are no longer in sync.

Flow chart of what SHOULD happen:

  1. Hub sends MultiLevelSet (0,120) to Dimmer#1.
    (This tells it to slowly fade off over a 120 second duration)
  2. Dimmer#1 sends MultiLevelSet(0,120) to Dimmer#2 via association
    (this tells it to slowly fade off using 120 second duration - same as Master)
  3. Master and Slave remain in sync

I believe Inovelli has a github tracking system for issues, but I don’t know if its publicly accessible. I’m happy to log this issue there if that is needed to make this an offical bug report. Just let me know how to access it. Either way, I believe this is a legitimate bug that needs to be fixed in the next firmware release

2 Likes
6

This makes sense. I will add it to the firmware “queue”.

1 Like
7

I believe a similar issue exists with the multilevel start command (it uses the default duration value instead of the value the switch is configured to use)

image

This can cause the switch to dim locally at a different speed than associated devices.

2 Likes
8

Thanks, I will add that to the issue info.

1 Like
9

@EricM_Inovelli what sort of timeframe might we expect to see a firmware fix for this?

The changes and delays with the Inovelli Aux Dimmer (Project Golden Rule) make this issue more important since many of us are using Associations instead of a wired Aux .