I have existing Schalge BE469 zwave locks. These are the original versions from circa 2018. One is in my main house and works relatively well. Two are in a detached building and don’t work worth anything. Everyonce in awhile (could be days) they will get an updated status. There are multiple hard wired zwave devices between the hub and the locks that don’t work as well as multiple hardwired zwave devices after the locks. The locks are the only ones that don’t work.
I have not purchased brand new Yale Assure 2 Zwave locks. Upon replacing them, I can’t even get them included in my zwave network with things in their final places. The inclusion process sees that there is a device, but doesn’t get any node info at all. I’m reluctant to bring the hub to them just for inclusion.
I am correct in assuming that locks should relay through other zwave devices just like everything else, right? Do they relay during inclusion as well or is inclusion only direct to the hub? Are there any good options for me to try before I just suck it up and get the wifi versions of the locks?
These locks. (original BE469) are NOT ZWave plus and also use ZWave whisper mode S0 pairing.
Those two things together mean to successfully pair they must (yes must none of the following can be skipped)
Be literally right next to the coordinator during pairing (less than 6"/10cm)
ZWave exclude the lock then
Factory reset the lock with it’s program code. (ZWave pre-plus does not factory reset and reset does not exclude the lock you must do both manually (this was later fixed in the ZWave plus version)
THEN include the lock. It will probably work if you did those properly
But your lock is paired directly. So yiu need to move everything back to its final location and start ZWave repair of the lock node. If the repair fails move your coordinator halfway and attempt the repair again. Repaat until your lock and coordinator are back in final location and communicate successfully.
One of my 469s died last winter and it was replaced with the newer plus version. Included in place in seconds.
Ive never had to do a Yale personally but Yale has a little better ZWave compatibility on their module (Allegions ZWave module in the old Schlage is borderline out of spec but it’s a darned solid lock) if it’s the current ZWave plus version if your mesh is solid it should pair in place no issue.
ABSOLUTELY NOT. Never heal the entire network unless you have a specific reason - it’s noisy and will cause delays and hiccups for even up to a day on a large network with a lot of battery devices.
That seems to be correct. I’ve tried the default secure include, default secure include force s0, and the s0 include through zwave js. My controller is a 700 series, so it all should be supported. Every device on the mesh is zwave plus (either 500 or 700) except for the BE469 locks.
I don’t have any other secure nodes on my mesh, not sure if that’s the issue. I’m not sure what i’m doing incorrectly.
Here’s the log:
2023-06-03 06:32:59.514 INFO Z-WAVE: Calling api startInclusion with args: [
0,
{ forceSecurity: true, name: ‘Shop Lock’, location: ‘Shop’ },
[length]: 2
]
2023-06-03T10:32:59.521Z CNTRLR Starting inclusion process with strategy Default…
2023-06-03T10:32:59.560Z CNTRLR The controller is now ready to add nodes
2023-06-03 06:32:59.563 INFO Z-WAVE: Controller status: Secure inclusion started
2023-06-03 06:32:59.565 INFO Z-WAVE: Success zwave api call startInclusion true
2023-06-03 06:33:03.298 INFO APP: GET /health/zwave 200 2.485 ms - 2140
2023-06-03T10:33:05.255Z CNTRLR handling add node request (status = NodeFound)
2023-06-03T10:33:05.527Z CNTRLR handling add node request (status = AddingSlave)
2023-06-03T10:33:19.221Z CNTRLR handling add node request (status = ProtocolDone)
2023-06-03T10:33:19.223Z CNTRLR finishing inclusion process…
2023-06-03T10:33:19.277Z CNTRLR The inclusion process was stopped
2023-06-03 06:33:19.279 INFO Z-WAVE: Controller status: Inclusion stopped
2023-06-03 06:33:19.283 INFO Z-WAVE: [Node 034] Found
2023-06-03T10:33:19.285Z CNTRLR finished adding node 34:
basic device class: Routing Slave
generic device class: Entry Control
specific device class: Secure Keypad Door Lock
supported CCs:
· Basic (0x20)
· Door Lock (0x62)
· User Code (0x63)
· Manufacturer Specific (0x72)
· Version (0x86)
· Z-Wave Plus Info (0x5e)
· Security (0x98)
· Device Reset Locally (0x5a)
· Powerlevel (0x73)
controlled CCs:
2023-06-03T10:33:19.287Z CNTRLR » [Node 034] Assigning SUC return route…
2023-06-03T10:33:22.963Z CNTRLR [Node 034] The node did not respond, it is presumed dead
2023-06-03T10:33:22.977Z CNTRLR » [Node 034] pinging the node…
2023-06-03T10:33:26.405Z CNTRLR [Node 034] The node did not respond after 1 attempts, it is presumed dead
2023-06-03T10:33:26.413Z CNTRLR [Node 034] ping failed: Failed to send the command after 1 attempts (Status No
Ack) (ZW0204)
2023-06-03T10:33:26.414Z CNTRLR [Node 034] Security S0 bootstrapping failed, the node was not granted the S0 s
ecurity class
2023-06-03T10:33:26.415Z CNTRLR [Node 034] Cannot configure Z-Wave+ Lifeline association: Node does not suppor
t associations…
2023-06-03T10:33:26.418Z CNTRLR [Node 034] Beginning interview - last completed stage: None
2023-06-03T10:33:26.418Z CNTRLR [Node 034] new node, doing a full interview…
2023-06-03T10:33:26.419Z CNTRLR » [Node 034] querying protocol info…
2023-06-03 06:33:26.427 INFO Z-WAVE: [Node 034] Value added: 119-0-name => Shop Lock
2023-06-03 06:33:26.429 INFO Z-WAVE: [Node 034] Value added: 119-0-location => Shop
2023-06-03 06:33:26.431 INFO Z-WAVE: [Node 034] Added with security None
2023-06-03T10:33:26.483Z CNTRLR « [Node 034] received response for protocol info:
basic device class: Routing Slave
generic device class: Entry Control
specific device class: Secure Keypad Door Lock
node type: End Node
is always listening: false
is frequent listening: 1000ms
can route messages: true
supports security: false
supports beaming: true
maximum data rate: 100000 kbps
protocol version: 3
2023-06-03 06:33:26.486 INFO Z-WAVE: [Node 034] Interview stage PROTOCOLINFO completed
2023-06-03T10:33:26.490Z CNTRLR [Node 034] Interview stage completed: ProtocolInfo
2023-06-03T10:33:26.491Z CNTRLR » [Node 034] pinging the node…
2023-06-03T10:33:29.949Z CNTRLR [Node 034] The node did not respond after 1 attempts, it is presumed dead
2023-06-03T10:33:29.957Z CNTRLR [Node 034] ping failed: Failed to send the command after 1 attempts (Status No
Ack) (ZW0204)
2023-06-03T10:33:29.958Z CNTRLR » [Node 034] querying node info…
2023-06-03T10:33:29.959Z CNTRLR » [Node 034] pinging the node…
2023-06-03T10:33:33.387Z CNTRLR [Node 034] The node did not respond after 1 attempts, it is presumed dead
2023-06-03T10:33:33.395Z CNTRLR [Node 034] ping failed: Failed to send the command after 1 attempts (Status No
Ack) (ZW0204)
2023-06-03T10:33:33.396Z CNTRLR [Node 034] Interview attempt (1/5) failed, node is dead.
2023-06-03 06:33:33.396 ERROR Z-WAVE: [Node 034] Interview FAILED: The node is dead
2023-06-03 06:33:33.449 INFO APP: GET /health/zwave 200 2.200 ms - 2140
2023-06-03 06:34:03.611 INFO APP: GET /health/zwave 200 2.350 ms - 2140
I bought a 15ft active usb extension cable and was able to move my controller. Now the new lock has joined securely and is acting just fine. Also, the old lock is acting better too now…
You can also put your Z-Wave stick on a SBC (like a Raspberry Pi) and share it over the network.
I’ve just recently rewritten this part of the documentation: Z-Wave JS docs - Remote serial port over TCP
Also, with the newer versions of Z-Wave JS UI you can now set a “Priority route” when you click on the node in the Network Graph. I’ve used this to nudge a node to accept a route I knew had to be better and it’s worked quite well (-> set the route, heal the node, clear the route if desired or just leave it in).
