MQTT: currentValue of slow switch_multilevel jumps to target value before reporting real values

zargony commented 4 days ago

Checklist

[X] I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.

Deploy method

Docker

Z-Wave JS UI version

9.14.4.40080a1

ZwaveJS version

12.12.1

Describe the bug

When setting targetValue of a device with switch_multilevel command class, currentValue is set to target value even before the device reports an updated real current value. I observe this behavior with (relatively slow) window blinds (Fibaro Roller Shutter 2 FGRM-222). I assume that zwave-js-ui might set currentValue to targetValue to provide faster responses. While this works e.g. with lights, it gives strange effects with slowly moving devices like window blinds.

E.g. if currentValue is 99 and setting targetValue to 70, you can observe currentValue:

currentValue: 99
set targetValue to 70
(with no visible delay) currentValue: 70
(~5s delay) currentValue: 84
(~5s delay) currentValue: 70

This causes strange effects when software tries to derive the direction of movement by looking at currentValue, e.g. when using MQTT values to feed Node-RED's HomeKit integration with a window blind position, it sees currentValue changing from 70 to 84 and shows an opening animation even though the blinds are closing.

zwave-js-ui log (unrelated lines about http requests, lastActive and power level reporting stripped):

2024-07-02 11:16:38.275 INFO MQTT: Message received on zwave/rollo_buero/switch_multilevel/endpoint_0/targetValue/set: '70'
2024-07-02 11:16:38.278 INFO Z-WAVE: Writing 70 to 4-38-0-targetValue
2024-07-02 11:16:38.386 INFO Z-WAVE: [Node 004] Value updated: 38-0-targetValue 99 => 70
2024-07-02 11:16:38.382 DEBUG MQTT: Publishing to zwave/rollo_buero/switch_multilevel/endpoint_0/targetValue: { time: 1684293578956, value: 70 } with options { qos: 1, retain: true }
2024-07-02 11:16:38.393 DEBUG MQTT: Publishing to zwave/rollo_buero/switch_multilevel/endpoint_0/currentValue: { time: 1719911798390, value: 70 } with options { qos: 1, retain: true }
2024-07-02 11:16:38.396 INFO Z-WAVE: [Node 004] Value updated: 38-0-currentValue 99 => 70
2024-07-02 11:16:43.513 DEBUG MQTT: Publishing to zwave/rollo_buero/switch_multilevel/endpoint_0/currentValue: { time: 1719911803510, value: 84 } with options { qos: 1, retain: true }
2024-07-02 11:16:43.516 INFO Z-WAVE: [Node 004] Value updated: 38-0-currentValue 70 => 84
2024-07-02 11:16:50.987 DEBUG MQTT: Publishing to zwave/rollo_buero/switch_multilevel/endpoint_0/currentValue: { time: 1719911810983, value: 70 } with options { qos: 1, retain: true }
2024-07-02 11:16:50.991 INFO Z-WAVE: [Node 004] Value updated: 38-0-currentValue 84 => 70

Actually, this log looks like the device is reporting 99=>70, so I'm unsure about the root cause. I initially suspected zwave-js-ui to do this (because why should a device report an estimated value while it knows the real current value).

To Reproduce

Using an mqtt client, locate and watch currentValue of a slowly moving device with switch_multilevel command class
Set a new targetValue via MQTT or web ui
Watch currentValue jump to the new target value immediately, then jumping back to the real current value while the device keeps reporting the current position until the target position is reached.

Expected behavior

I'd expect the currentValue to report the current value only, not the expected target value.

Additional context

I'm using Settings -> Gateway (probably unrelated to the issue, but explains the log):

Topic type: Named topics
Payload type: JSON Time-Value
Ignore Location: on

kpine commented 4 days ago

That's the intended behavior. See driver option disableOptimisticValueUpdate.

AFAIK there's no simple way to disable that, you have to use ZUI's hidden settings.

robertsLando commented 4 days ago

@AlCalzone wondering if it could make sense to add a dedicated ui option for this? Is it usual this to create problems?

zargony commented 3 days ago

I see. Thanks for clarification. So the driver is always sending optimistic value updates unless you set this option, which disables it for all devices, I assume. For most devices, optimistic value updates are probably a good idea, e.g. with any switch_binary and fast moving switch_multilevel like lights. However with slowly moving devices like window blinds, garage doors and gates, this can cause strange effects like described above.

Having a UI option for this would be nice indeed. However I think it'd be most useful on a per-device basis. Optimistic value updates should be the default of course, but being able to disable it for a device makes a lot sense imho (even better if it would be disabled automatically for devices known to move slowly, like rollershutters)

robertsLando commented 3 days ago

About this I need to ask to @AlCalzone as I don't think that's possible yet

AlCalzone commented 2 days ago

See https://github.com/zwave-js/node-zwave-js/issues/3892

robertsLando commented 2 days ago

@zargony if you agree I would close this one and let you follow updates in linked issue? Or would you like to make the flag available on UI anyway?

zargony commented 2 days ago

I'm fine with tracking the upstream issue. Thanks again for the help! Depending on how zwave-js/node-zwave-js#3892 turns out, it would probable be nice to have a flag available in UI anyway. Either to switch it on/off if the driver keeps it a manual setting, or to override the automatic choice of the driver. But we can look into this in a separate issue (feature request) once such a setting is available if you prefer.

zwave-js / zwave-js-ui