allow setting of duration/transition

[marcelveldt]

Is your feature request related to a problem? Please describe.
Looks like setting the light transition duration is not implemented yet.

Describe the solution you'd like
Be able to set transition duration value.

Explaining your use-case will go a long way in helping us understand.
Home Assistant integration

Thanks!

[AlCalzone]

What is the expected behavior here?

1. Let's say, a user sets a duration, then changes the target value.
2. The device later gets triggered physically and reports a different duration.
3. The user changes the target value again.

Which duration (if any) gets used for the set command?

[robertsLando]

The device later gets triggered physically and reports a different duration

Why should this happen? Does a trigger also report a DUration?

[AlCalzone]

Yes, some newer devices report current and target value as well as the remaining duration.

[robertsLando]

I think that the device should always use the user selected duration

[AlCalzone]

Currently, there's only one duration value ID, so that would get overwritten when we receive a report.
And looking at the confusion around current/target value I'm really hesitant to add another of these value pairs.

[marcelveldt]

I think it would be nice to be able to retrieve the current configured transitionDuration and must-have to set a transitionDuration. maybe adjust it the same so you'll have currentDuration and targetDuration ?

[AlCalzone]

I'm wondering if it is desirable not to have an extra value to set the transition duration and instead pass it somehow along with the set command?
I'm not very familiar with the MQTT API to determine if that is possible and makes sense.

[robertsLando]

I'm wondering if it is desirable not to have an extra value to set the transition duration and instead pass it somehow along with the set command?

This could be good but also setting a default value should be possible

[AlCalzone]

@marcelveldt we've been thinking - what's your take on adding another argument to setValue that specifies options for the set call? E.g.

setValue(/* targetValue ID */, 99, { duration: "2m" }); // transition to 99 over 2 minutes
setValue(/* thermostat setpoint ID */, 23, { scale: 1 }); // turn setpoint to 23 °C

These additional properties would be discoverable via setValueOptions: ["duration", ...] on the value metadata.

I'd prefer something like this, because it avoids littering applications with tons of single-purpose values. It would also allow you to define the transition duration, setpoint scale, etc. in a single location (e.g. once per node).

The remaining duration would still be reported as a value like now.

[marcelveldt]

That sounds nice!
The code we have in HA is now as following:

1. check current transitionDuration for the light
2. if user gives a transition parameter and the value is different than currently set on the light, submit it.
3. is user omits the transitionDuration, the light's default should be used (255)
4. send transitionDuration value to light if it differs.
5. send setValue to actually change brightness

So calls 4 and 5 could actually be combined and perhaps the check done at 3 too ?

[AlCalzone]

send transitionDuration value to light if it differs

Z-Wave does not have a concept of saving transition duration on a device. It can either get sent as part of the set command or left out.

I'm guessing you're doing it that way because OZW had a settable duration parameter? In that case, the new process would be:

1. send setValue to change brightness. Include transition duration if the user provided it.

If no duration was given, zwave-js automatically sends a command with the default duration.

[jcam]

Would changing the default duration be a separate setting, controllable through the API?

[marcelveldt]

@AlCalzone that sounds like a very valid approach and even an improvement over what we have now.

[AlCalzone]

Would changing the default duration be a separate setting, controllable through the API?

Nothing defined in the specs. If there's an option to do that for a device, it is a device-specific configuration value.

[kpine]

If no duration was given, zwave-js automatically sends a command with the default duration.

What does "default duration" mean in this context?

[AlCalzone]

It omits the duration field (so it sends a V1 command), which means a device should use the factory default duration - whatever that is.

Alternatively we could think about explicitly including the duration field and setting it to 255 (=default) if that is necessary.

[marcelveldt]

Give me a ping once this is implemented so we can adjust our code. We will only send the duration if the user explicitly defines it and we'll not send it otherwise.

[kpine]

It omits the duration field (so it sends a V1 command), which means a device should use the factory default duration - whatever that is.

Interesting, I hadn't thought of doing it that way. I suppose that will work as long as there are not any new versions of the Set command. Thanks for the clarification.

[AlCalzone]

There are. But the specs say (I know, who cares about specs - not the device manufacturers at least) to treat a V1 command (for Multilevel Switch at least) without duration the same as a V2+ command with a "default" duration.

[kpine]

I meant the Set command itself, no new version since V2. If a V5 comes along with a new field, you would be required to set duration in addition with the new field.

The specs say devices "should" (recommend) support V1. I wouldn't be surprised if there's some device that actually does take it as a "should" (or maybe the SDK handles it)! 😄

[jcam]

My Eaton dimmers are a great example of "should" taken literally. If no duration is set (i.e. they get a V1 set), then they use "0" instead of "default". Which mostly works (snaps instead of dims are a bit jarring), except when turning off. When told to turn off, they drop to about 8% and just stay there, instead of turning off.

[kpine]

And if it's a V2 set with duration 0xFF, they function as expected?

[jcam]

yup! 🤦

[kpine]

That seems like a good argument for generally using the V2 Set command for V2 devices. 😁

[matejdro]

Is there a workaround to this issue at the moment (maybe settings some raw z-wave value through mqtt)?

[AlCalzone]

https://zwave-js.github.io/zwavejs2mqtt/#/guide/mqtt?id=send-command
would work normally, but the set method expects a Duration class instance as the 2nd parameter - I don't think you can pass that via mqtt.

[matejdro]

Yeah it does not appear so 😞

From what I can see, Duration class is just a class with one field, _value, so this should work:

{
    "args": [
        {
            "nodeId": 16,
            "commandClass": 38,
            "property": ""
        },
        "set",
        [
            50,
            {
                "_value": 5
            }
        ]
    ]
}

But second parameter is ignored (value is set to 50% with the default duration).

[dlashua]

If it helps any, even setting the "duration" via the ZWaveJS2MQTT Control Panel doesn't work.

It results in this error in the logs:

2021-02-13 11:42:31.211 INFO ZWAVE: Calling api writeValue with args: [
  { nodeId: 9, commandClass: 38, endpoint: 0, property: 'duration' },
  { value: 10, unit: 'seconds' },
  [length]: 2
]
2021-02-13 11:42:31.212 INFO ZWAVE: Writing { value: 10, unit: 'seconds' } to 9-38-0-duration
2021-02-13 11:42:31.213 INFO ZWAVE: Controller status: Driver: Multilevel Switch: "duration" is not a supported property
2021-02-13 11:42:31.214 ERROR ZWAVE: Unable to write { value: 10, unit: 'seconds' } on 9-38-0-duration

This is for Device ID: 634-40962-40960 (0x027a-0xa002-0xa000), which is able to handle transitions just fine with OZWd.

[AlCalzone]

This is because the API expects a duration instance with the serializeSet method existing

[matejdro]

Would you be okay with accepting PR with little if in the sendCommand that would create duration object? This would of course be temporary and removed until proper duration support is implemented.