search

zwave-js / node-zwave-js

Z-Wave driver written entirely in JavaScript/TypeScript
https://zwave-js.github.io/node-zwave-js/
MIT License
755 stars 608 forks source link

Better allow for node transition from S0 to S2 #3227

Open blhoward2 opened 3 years ago

blhoward2 commented 3 years ago

The zwave spec does not provide for a way to migrate an already included device from S0 to S2. To do so you'd have to exclude/include, which would change the node numbering, device naming, etc. You can't just reset the device and replace the failed node, because many devices will remove themselves from the database when they are reset locally.

In consultation with @AlCalzone, we propose to add a property to the node/driver that would ignore the next DeviceResetLocallyNotification from that node. That would allow the UIs to present a workflow similar to:

  1. User selects a node to migrate (or nodes, this could be done more than one at a time)
  2. UI disables removing the device on next local reset using the proposed property
  3. If they exist, reset instructions are displayed from the device config file
  4. User resets device locally following the instructions
  5. UI checks for if the node is failed
  6. If the stick marks it failed, UI initiates replace failed node and prompts user to reinclude the device
  7. If the device responds to the IsFailed after being reset (an edge case I saw with one Leviton device), prompt the user to power off the device and check if failed again with the device powered off.
  8. Repeat 6

In addition to adding the property, we need to modify this routine to skip it if the property is set.

https://github.com/zwave-js/node-zwave-js/blob/b1f0bce76ece13506f4b68c4df5478f780d188da/packages/zwave-js/src/lib/driver/Driver.ts#L2375-L2394

Note: In the interim, an eager user can power down zwavejs, reset the device, power back up, then check failed node, and replace failed node.

Separately, this same property/workflow can be used to allow a user to force replace a node while maintaining the same node numbering. The driver wipes out everything it knows about a node when doing the reinterview, but the UI would need to gracefully handle the device type/endpoints changing, which can actually happen now if a user does the power down/isFailed.

blhoward2 commented 3 years ago

@robertsLando @cgarwood @raman325 @marcus-j-davies Thoughts?

raman325 commented 3 years ago

seems like a reasonable approach to me, I am not familiar with DeviceResetLocallyNotification but your explanation makes sense

robertsLando commented 3 years ago

I could add this to the nodes manager dialog in my case. It's ok for me

marcus-j-davies commented 3 years ago

Seems simple enough. Might be one of those that will become obsolete quickly however, but sure, this will be helpful.

robinsmidsrod commented 3 years ago

Note: In the interim, an eager user can power down zwavejs, reset the device, power back up, then check failed node, and replace failed node.

This workaround mentioned actually doesn't work (for me on Heatit ZDim). It goes along until you type in the DSK, and then it just ends up hanging, and eventually time out on S2 negotiation and then reverting to None security. If I unpair and re-pair properly it correctly manages to use S2_Authenticated security.

AlCalzone commented 3 years ago

Have you tried resetting it twice before re-including? I remember that some locks need that.

robinsmidsrod commented 3 years ago

@AlCalzone I have not tried double reset, but now I have done the tedious work of getting all my S2-compatible devices excluded and re-included, so I'm not really inclined to test it out... Thought I'd just mention it, for future reference.