Hi@spudwebb

All calls to a node will wait until the node responds, as that is how the driver behaves. the reason there is no timeout here or driver side, is due to the fact the set could fail once awake, if a value is outside the range for the device for example

There is the method ofZWaveNode.WaitForWakeup() but in reality there is no difference into just allowing the calls to complete once a node is awake.

Hi@marcus-j-davies

I understand the rationale behind this, but from a practical standpoint I don't see how any application could use such command methods without implementing some kind of timeout themselves: any application that has user interaction or needs to run a command within a certain timeframe can't wait indefinitely for the method to return.

That's why I wish most of command methods in ZWaveNode would have an optional timeout parameter (or an optional CancellationToken parameter) and would return an error saying something like "No response received from the driver after X seconds. The command may or may not succeed"

For now I will implement something like this on my side.

Sorry@spudwebb
Have been down with a winter virus since Tuesday, still recovering.

I do get it, and will keep it in mind for the future, I think its my stubbornness with wanting to keep the lib to near native API as possible with the JS counterpart, I don't have to write masses amount of documentation that way, as users can follow the Native Driver docs 😄

Example, most Driver methods are a javascript promise, so it feels right to follow that Trend with Tasks.

With that said,
You can checkZWaveNode.status before deciding if you should wait for an action to "resolve"

publicenumNodeStatus{Unknown,Asleep,Awake,Dead,Alive}

Alive,Awake is only different in that, the node can also sleep (Asleep) ifAwake