Description
Is your feature request related to a problem? Please describe.
I turned on a light to level 75 with a transition duration of 10 seconds. When zwave-js refreshed the value it read back as level 72, but I would expect 75. When I manually refreshed the value a few seconds later, it was the correct 75.
Describe the solution you'd like
When a transition duration of N seconds is specified, instead of scheduling the refresh at exactly N seconds later, perhaps add a small additional delay, e.g. N+0.5 seconds or N+1 seconds, so that refreshing the value might be more reliable. I presume there is some delay after the refresh timer is started that causes it to expire before the device finishes the transition. If there is enough delay, presumably zwave-js will refresh before the transition has completed. Adding some extra time to account for this delay might make the refresh more reliable.
I'm sure it does get tricky to figure out a good time that would always reliable. Maybe N + 1s still fails 1/100 times.
I would say this is a low priority request.
Describe alternatives you've considered
Refresh manually.
Additional context
zwavejs2mqtt logs:
2021-10-23 22:12:00.875 INFO ZWAVE: Calling api writeValue with args: [
{ nodeId: 2, commandClass: 38, endpoint: 0, property: 'targetValue' },
75,
{ transitionDuration: '10s' },
[length]: 3
]
2021-10-23 22:12:00.877 INFO ZWAVE: Writing 75 to 2-38-0-targetValue
2021-10-23 22:12:00.932 INFO ZWAVE: Node 2: value updated: 38-0-currentValue 25 => 75
2021-10-23 22:12:00.934 INFO ZWAVE: Success zwave api call writeValue undefined
2021-10-23 22:12:10.973 INFO ZWAVE: Node 2: value updated: 38-0-currentValue 75 => 72
2021-10-23 22:13:04.164 INFO ZWAVE: Node 10: value updated: 113-0-alarmType 13 => 13
2021-10-23 22:13:04.166 INFO ZWAVE: Node 10: value updated: 113-0-alarmLevel 255 => 255
2021-10-23 22:13:26.511 DEBUG SOCKET: Event ZWAVE_API emitted to 11aMM41khRnvs8pnAACr
2021-10-23 22:13:26.513 INFO ZWAVE: Calling api refreshCCValues with args: [ 2, 38, [length]: 2 ]
2021-10-23 22:13:26.552 INFO ZWAVE: Node 2: value updated: 38-0-currentValue 72 => 75
Driver logs:
transition.txt
I'm a little fuzzy on the logs as to the exact times where the driver sends and receives messages, and the controller ACKs. But it looks like the Set command first gets sent at time 05:12:00.901, and the refresh reply is seen at 05:12:10.970, so that leaves less than 69 ms of tolerance for any kind of delays that could have happened during the process. Maybe 69 ms is a really long time, for all I know.