I have been struggling with my Schlage BE469 deadbolt lock of late.
Most recent symptom was the lock responded to lock and unlock commends but did not permit changing key codes nor did it properly report existing codes.
I tried may things, repairing the device, moving the hub closer, hour chatting with AI for ideas and sharing logs and so forth.
Most recently AI suggested JS is much more strict at enforcing timing rules whereas ZIP was more lax. So on a whim I swapped back to ZIP (I've been on JS for many months now). Now the lock allows me to change codes and the lock app also works.
So there is something weird about how JS works with sleepy FLiRS devices that is not working with these devices.
Anyone have a Schlage deadbolt working on JS reliably?
Not sure where to turn next? @bcopeland Any ideas for me?
Here is what AI said:
me: I am paired with S2
AI: If your Schlage lock successfully paired with S2 Access Control security, it narrows the blame significantly. This changes things, because it means you aren't dealing with the ancient S0 protocol—your lock is capable of modern, single-packet Z-Wave security.
With S2 active, this is primarily a defect in how Z-Wave JS handles the Hubitat command queue for these specific locks, combined with how slow the Schlage hardware handles wake-up calls.
This specific interaction explains why the ZIP engine works while Z-Wave JS drops your code changes, despite having the security protocol:
- The Z-Wave JS Issue: Queue Management and Aggressive Timeouts
When you change lock codes via a smart app, the hub doesn't just send one command; it sends a burst of sequential instructions (e.g., "Clear slot 3," "Write new code to slot 3," "Verify slot 3 code").
- The JS Bottleneck: The Z-Wave JS engine is incredibly fast, but it is notorious for being highly aggressive with its timing windows and command queue. If a device does not respond to the first "clear slot" command immediately, Z-Wave JS can timeout, stall, or drop the subsequent "write code" commands in the queue.
- The ZIP Advantage: Silicon Labs' legacy ZIP Gateway stack handles command queues differently. It is highly sequential, patient, and will holding-pattern messages until the device fully finishes processing the previous task. It doesn't trip over itself when communicating with a sluggish lock. [1, 2, 3]
- The Lock Issue: Slow FLiRS Wake-Up
Even though your lock has modern S2 security, it still uses a battery-saving hardware mechanism called FLiRS (Frequently Listening Routing Slave). [1, 2]
- The lock is technically asleep 99% of the time.
- When Hubitat wants to change a code, it has to send a "beam" to wake the lock up.
- On the Schlage, it takes a fraction of a second too long for the chip to wake up, realize it needs to process a multi-step code change command, and reply.
- The Hubitat Component
Hubitat is caught in the middle because Z-Wave JS is still maturing on the platform. Many users in the Hubitat community have noted that while Z-Wave JS is excellent for standard devices and ghost-node removal, it still experiences inconsistent behavior and timing issues with heavy-payload devices like locks. Hubitat intentionally left the toggle to switch back to ZIP precisely because they knew certain legacy hardware combinations would struggle on the new engine. [1, 2, 3, 4]
The Verdict
It is a compatibility gap in Z-Wave JS's strict queue timing when talking to a slow-waking Schlage FLiRS lock. [1]
Since ZIP works flawlessly for you, it is absolutely best to leave the hub on the ZIP stack for now. The Hubitat team continuously patches the Z-Wave JS firmware, but until they fine-tune the command queuing for locks, ZIP is your best configuration. [1, 2, 3, 4]
Are your lock code changes pushing through instantly now, or do you still notice a 2- to 3-second delay when you save a new code in Hubitat?
).
that worked for over a decade. Such is progress…
