Replies: 3 comments
-
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 of |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Sorry @spudwebb 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, public enum NodeStatus
{
Unknown,
Asleep,
Awake,
Dead,
Alive
}
|
Beta Was this translation helpful? Give feedback.
-
If, for example, the
RefreshValues()
orSetValue()
methods are called for a node that is asleep, the method never return (unless the node wakes up)Shouldn't there be some sort of timeout in order to guarantee that the method will return within a certain time?
Beta Was this translation helpful? Give feedback.
All reactions