Pass the "transition duration" parameter to a dimmer device, especially (only ?) the Qubino mini Dimmer (ZMNHHD)

[rezzalex]

Is your feature request related to a problem? Please describe.
Problem described here : #2226 (comment) and initially partially treated here : #2305

Describe the solution you'd like
A "native" integration in ZwaveJsUI to make a sustainable Configuration Option : "Transition Duration", allowing the dimming duration, when activated form any software gateway, to be decorrelated from the parameter [66] - Dimming Duration (physical switch Held)

Describe alternatives you've considered
The previous implementation required additionnal developpements in DZ, knowing this is not a parameter we would like to change each time we dim the light. In fact, the more common usecase, would be to be able to set it once and for all in ZwavejsUI, as any other standard manufacturer parameters. Also, this is a specific manufacturer setting, like any others already implemented in ZwaveJsUI
It would then allow DZ or HA to be careless about this feature. even maybe make it discoverable and usable out of the box by DZ and HA.
The idea is that the parameter can be set and used for any futures sofware commands, unless changed again, from ZwavejsUI but most of all, for ANY command that reach ZwavejsUI (from MQTT)

Additional context
Add any other context or screenshots about the feature request here.

[robertsLando]

@AlCalzone Thoughts on this?

[AlCalzone]

This, but for MQTT?

[robertsLando]

That's already implemented, what he wants (if I have understand him correctly) is a 'virtual' configuration value id on the device where you can set the transition duration of that device so you don't have to pass it every time you send a set command

[AlCalzone]

So just make that value configurable via MQTT? Isn't it stored somewhere?

[robertsLando]

Isn't it stored somewhere?

Humm nope, where should it be stored? In the broker?

[rezzalex]

Hello,

any news on this one ?

If that could help, the raw command given by the manufacturer is that one :

26 01 63 00 the value 63 is the dimming value and the 00 is the speed (all values are in hexadecimal)
​
0x26 COMMAND_CLASS_SWITCH_MULTILEVEL
0x01 SWITCH_MULTILEVEL_SET
0x63 Value (
0x00 Dimming Duration

#2226 (comment)

[robertsLando]

Hi alex, you can already do that, see: https://zwave-js.github.io/zwave-js-ui/#/guide/mqtt?id=set-with-options

Anyway what you are asking here is different, you would like to have a 'virtual' valueId where you set a fixed transition duration for a specific device and then, when you send a command, use that duration by default. Correct? If so there is no easier way to implement that

[rezzalex]

That's it, it was already identified on my side, but thanks for mentionning it in the Wiki and with the video, it helps.
I am not using MQTT explorer as an "end-user" tool, and currently, I can't use it from Domoticz.
That is why I would like to have a fix (virtual ?) parameter in ZwaveJSui. it wont be changed every morning, but would allow to have a specific transition time for both usage from Domotic and usage from the physical switch (long press to dim)

[robertsLando]

Dunno if your device already supports a configuration value for that?

[rezzalex]

no, they only provide the "raw command" as described in the link an "citation" already provided.
The manufacturer said

Until now we didn't find the gateway that uses that. It will be good that it would be possible to use it as like this the customer can use it in the buttons or in the automations.

[robertsLando]

@AlCalzone thoughts on this?

[AlCalzone]

The driver already supports 2 ways to do this:

a) the CC API, can be accessed using a driver function for example
https://zwave-js.github.io/node-zwave-js/#/api/CCs/MultilevelSwitch?id=set

The above "raw" command would be:

const node = driver.controller.nodes.get(  nodeID  );
node.commandClasses["Multilevel Switch"].set(
  99, // or whatever target value
  "0s", // or any valid duration string, like "17s" or "1m10s", ...
);

b) The aforementioned setValue option

I'm not going to simulate values just to add a 3rd way. I guess adding properties on the ZWaveNode class to use as a fallback if no setValue option is passed for b) would be fine.
But in the end, if these should be configurable, the application would have to provide access anyways - so why not solve it there in the first place?

[rezzalex]

@AlCalzone,
unless mistaken by ignorance, the first 2 ways are not manageable from Domoticz

. I guess adding properties on the ZWaveNode class to use as a fallback if no setValue option is passed for b) would be fine.

could be fine yes

If i understand correctly your the last sentence, this is pefectly the point of discussion here : this option wont' be changed often, almost never once set to a satisfactory value. This is why it does not necessary needs to be implement in the final application, but somewhere where the value persists for every call.

[robertsLando]

@rezzalex I spoke about this with @AlCalzone and the solution we have think is to add default set value options (like transition) to the node object and those will be persisted on driver nodes cache, on ui you will be able to set those default values (each node must be configured with its ones) and then when sending a command those options will be used if no options are specified

[rezzalex]

hello @robertsLando , sounds good. thank you

My understanding is that the setting will persist, but how it will look like in the UI and if we can change it how we want, that is unclear to me.

[robertsLando]

My understanding is that the setting will persist, but how it will look like in the UI and if we can change it how we want, that is unclear to me

In the ui you can already set those options, I will simply add a button near to them to store them as default

[rezzalex]

Hello.

Any planned implementation ?

Thank you

[robertsLando]

AFAIK there was a plan on adding them on zwave-js side. @AlCalzone Do you have an open issue for this?

[AlCalzone]

I don't think I had one. There is one now: zwave-js/node-zwave-js#6107

[AlCalzone]

Will be supported in the next release of node-zwave-js