What does your OZW_Log.txt say about the network key? Should be in the first 3-5 lines of the log.
I fixed it! I’m still learning and forgot to put the network key in the options.xml file.
THIS!! I too have been trying to get the lock paired in secure mode. I had the network key set in my configuration.yaml, brought the HA and stick within 6’ of the lock, set to pair, and still no luck. Checked my OZW.log and sure enough I was still not in secure network mode. Checked my options.xml file and find that the network key line is excluded out. I enabled it, set the same key in that file, reboot the HASS Pi and paired instantly, (even with the Pi and zwave stick back in its original location 20+ feet away)!!
Wish I saw this post 3 days ago, ha!
Spent most of the weekend on this and I still can’t get it to work. Worked fine on SmartThings but this transition has taken over a week now.
- HA Version: 0.86.4
- Lock Model: Schlage BE369 (Zwave manual deadbolt with keypad and codes)
- Controller: Silicon Labs Z-Wave Static Controller (Works the same as Aeotec have one of those too)
- Proximity: Removed the lock and put it next to the controller after spending time back and forth
- Battery: Replaced both kinds (AAx2, 9v)
- NetworkKey: Enabled Z-Wave integration and copied over the key from core.config_entries to config.xml
- OZW Line 2: “Info, Setting Up Provided Network Key for Secure Communications”
Lock pairs after doing a secure pair. I see the capabilities flow by on the OZWLog and it settles down. It shows up as a lock on lovelace that has the LOCK button. Clicking on it does engage the lock and allows me to move the deadbolt from the outside as if I had entered a correct code.
I have even managed to change a usercode using the ZWave config, so COntroller to Lock seems to work fine.
However the state never changes in the UI. Locking/unlocking it manually has no effect either. The LOCK button works as a shortcut to engage the lock but no states are propagated back when I lock or unlock it. This lock worked fine in SmartThings.
Return messages not encrypted?
There is a very suspicious line that complains that a Clear Text Message was sent to a secure commandclass:
2019-02-04 00:21:03.206 Detail, Node072, Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x48, 0x03, 0x20, 0x01, 0xff, 0xb6, 0x00, 0xd3 2019-02-04 00:21:03.206 Detail, 2019-02-04 00:21:03.206 Warning, Node072, Received a Clear Text Message for the CommandClass COMMAND_CLASS_BASIC which is Secured 2019-02-04 00:21:03.206 Warning, Node072, Dropping Message
This is odd since I’ve tried adding the lock as an unsecured node which pairs it but the lock blinks red instead of green and nothing works. I tried adding and removing locks and unsecure and secure as per various posts but no luck.
Spelunking using the public ZWave SDK tools
Another data point: I’ve been slowly moving over my ZWave house over to HA from ST and I’ve been using the new open Z-Wave SDK PC Controller 5 to view the USB Controllers view of the network when HA doesn’t use it. When securely adding node from HA, the Controller 5 reports it as added non-securely. I did some major surgery to test where I added the lock from the PC Controller 5 and then it does report as added securely as an [S0] node. I modified all entries in HA (ozwconfig and .storage files) to make HA recognize the node. Everything stays the same. I can engage the lock but no state changes.
This is some of the geekiest stuff I have ever done and I do embedded development for a living. I thought Z-Wave would be the right choice since each device was certified. Now, looking under the hood and absolutely amazed what a jungle of poorly implemented command classes it is. Devices just simply lie about their caps. Anyway I’ll stop ranting and focus on the locks.
So what am I missing? Any ideas? Would love to help making HA+ZW better since this is messy (love the HA framework, just bleeding a little from the ZW integration)
I dont have a BE369, but I do have a 469, and 599. The 599 had some weird config issues that caused it to not report instantly, maybe the 369 is similiar.
Check this out
Did you have to unpair and repair?
I too got the node to show up in home assistant but got the red x on the keypad.
Anyone having luck with this? I’ve got my lock showing up in the entities, but it absolutely will not work. Cannot loc or unlock it. I’ve got the network key in my configuration file but when I look at Zwave node values for the lock, I get 3 lines that say “null(Instance: null, Index: null)” Node configuration options start at 3 instead of 1 also. Please help me make this work.
I also have a BE369. I cannot get it to pair with HA 0.94.4 with the aeotec zstick s2. I have another aeotec multisensor paired just fine. I did add a network key.
At the lock, the lock programming code enters ok, it blinks orange like it should. The directions say it should blink green once it pairs, but this never happens. I checked the logs in configuration->zwave, but I see nothing.
I struggled for the longest time to add my lock only to realize I forgot to keep the lock in the locked position when running the pairing… Make absolutely sure you’re doing everything as stated in the pairing guidelines.
When you click on Add Node Secure (or just Add Node), should you see something in the log? Anything? I get nothing at all. Basically identical to @senorsmile except I’m on 0.95 now and I’ve tried with two DIFFERENT z-wave USB sticks (Zooz and Nortek). It’s possible that the door is out of range, but before I go to any extremes I want to see if there’s a software issue since nothing is getting logged when I try to add nodes.
Okay, so I probably spoke too soon. I didn’t realize you had to issue a Cancel Command to invalidate any prior add node requests. This is my first attempt at pairing a z-wave device period, and the z-wave interface in HA is, well, confusing and the protocol itself seems convoluted. Uugh! Anyway, I’m wondering now if it is out of range. Maybe I need a repeater…sigh…
@ptyork You probably need a repeater. I just went through this a few weeks ago. Bought a ZWave stick and the Schlage Connect. The lock constantly would become unavailable or only partially work - even though my stick and lock were only about 15’ away, but with walls and central air ductwork in between. ZWave biggest benefit is in its meshing between (AC powered, not battery) devices. I got a ZWave plug in module to put half between stick and lock and no issues since. Will just use the plug in module for Xmas tree at Christmas time since it’s exactly where we usually setup our tree - I have no other use for it.
Thanks, @glassbase! I think you’re likely right. The door is 50+ feet away and through walls and floors. I’ve hacked it together for the time being by adding a SmartThings Hub I had sitting around. But I don’t really want to use that as a long-term solution since it adds another ecosystem to the already confusing muck and is cloud-dependent. So I’ll probably invest in some plugs and switches to serve as repeaters when I see a deal pop up.
I tried turning the handle to the locked position to no avail. I also see nothing in the logs. There is nothing in between the zwave stick and laptop… about 15 feet away (closest power adapter to front door).
A few bits on programming user codes, in case it helps anyone else who finds this thread.
I’m currently using 0.101.3 and 2 x BE469ZP, with Aeotec Gen 5 Z-stick. Pairing as a secure node worked first try for both locks.
Programming the user codes through Configuration -> Zwave GUI in Home Assistant does seem to work but doesn’t seem to be that reliable for a couple of reasons:
Home Assistant does seem to be able to retrieve the user codes from the lock and they are readable. There appears to be a
\xa\xd after the code. To me this looks like there is a New Line, Carriage Return sequence which possibly should be getting trimmed out before display.
when you set the new value, be sure to delete the
\xa\xd. For me, the set seemed to fail silently, if you left those in there. I though they might be needed.
When setting the codes, I saw different behaviors in the “Node user codes” dialog box.
- the new code would be displayed as you’d hope.
- the value would change back to what ever it was previously either:
It is helpful to tail
OZW_log.txt when doing this so you can see the Zwave transactions and get an idea of what’s going on.
This usually indicated that setting the code failed:
OZW_Log.txt:2019-11-24 08:16:43.878 Info, Node007, Received User Code Report from node 7 for User Code 6 (Not Available)
When setting the code correctly, I’d see:
OZW_Log.txt:2019-11-24 08:39:32.673 Info, Node007, Received User Code Report from node 7 for User Code 6 (Occupied)
At least once after setting the code, the response came back as
Available instead of
Occupied. Trying to set the code again seemed to work.
It also seemed like occasionally the previous value for the user code was cached and displayed, so it was making me think setting the code did not work, when it actually had. It seems like it didn’t query the lock and just used the old value.
Hope this helps.
getusercodes is only called on start up of the zwave network. If I recall it is not recommended to use the “Usercodes” section to manage your codes, but instead use scripts/automatons.
Use quality Alkaline, not Lithium, and not rechargable. Lithium last longer but die suddenly, no warning.
Expect to get > 1 year, even with a WiFi lock.
Thanks for the info! After trying a few times to admit unsuccessfully, this did the trick!
Thanks to OP for the post at the top. Was helpful for making sure the secure key was in the configuration.yaml. After some button pressing of “healing” the network and adding / removing the node, got it finally working.
You should take a look at this thread if you have your lock connected. You can manage everything about this lock now from HA
I am about to add a 2nd Schlage Connect lock, I have been super impressed with my current lock. It works flawlessly and the original batteries lasted nearly 14 months