I’m running openHAB 2.4. I have 3 Schlage Z-Wave BE469 locks. They’ve been working fine for many months, but a few days ago one of them went offline and says “Node is not communicating with controller” in HABmin. I’ve tried restarting openHAB and rebooting the server - no change.
What to do next? Is it worth doing a factory reset on the lock? Since it doesn’t appear to be communicating, I don’t think I can exclude it. Will it include as a new device after a factory reset? Then I can try to remove the old one afterwards?
Should I try a later version of the binding? It seems like the lock is in bad state - I’m not sure if later versions can help with this or not. If it’s a hardware failure, then it likely won’t make any difference.
Is there anyway to know for sure this is a hardware failure?
The first thing to try are new batteries. My BE469s will drop sometimes before there’s a power management alert or being reported as 0%. And the locks still lock under their own power when pushing the outer button… with lights.
I thought that helped. At first it popped right back up after the batteries were changed, but then I tried a lock/unlock from the UI, and it’s back to non-communication. Any other ideas?
2019-05-20 21:46:52.015 [hingStatusInfoChangedEvent] - 'zwave:device:d09e64fb:node10' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE
2019-05-20 21:46:52.152 [vent.ItemStateChangedEvent] - Lock_EntranceFront_Battery changed from 99 to 100
2019-05-20 21:50:03.274 [ome.event.ItemCommandEvent] - Item 'Lock_EntranceFront' received command OFF
2019-05-20 21:50:03.276 [nt.ItemStatePredictedEvent] - Lock_EntranceFront predicted to become OFF
2019-05-20 21:50:03.284 [vent.ItemStateChangedEvent] - Lock_EntranceFront changed from ON to OFF
2019-05-20 21:50:14.535 [ome.event.ItemCommandEvent] - Item 'Lock_EntranceFront' received command ON
2019-05-20 21:50:14.537 [nt.ItemStatePredictedEvent] - Lock_EntranceFront predicted to become ON
2019-05-20 21:50:14.544 [vent.ItemStateChangedEvent] - Lock_EntranceFront changed from OFF to ON
2019-05-20 21:50:16.447 [hingStatusInfoChangedEvent] - 'zwave:device:d09e64fb:node10' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
If you haven’t done it in a while, shutdown the hardware running OH, pull out the controller (soft reset), plug it back in and start everything back up. Have you changed or moved any zwave devices, or are any others showing as offline?
Everything is just a guess without seeing the log from the binding. The log you posted is from the event.log, but you’ll find the good stuff in the openhab.log. Set the logging for zwave to debug (log:set DEBUG org.openhab.binding.zwave) and watch the log for anything is being sent from the lock.
Doesn’t look very healthy to me. I turned on debug, disconnected and reconnected the battery (same result as putting in fresh batteries). Then I sent an unlock and a lock command. What’s odd is that it appears to be partially functional: it is able to send a battery report of 100% and the current state. But it doesn’t seem to accept any commands.
At one point, I had a lock that behaved similar to this, and exclusion/reinclusion would get it back online. I finally called Schlage to report the issue and ask for a firmware update. Their solution was to send replacements for all of my locks with newer firmware. Now, if I let a battery go completely dead, they will occasionally be marked as not securely included and I need to exclude/reinclude them. Which firmware do yours have? Mine report 113.22 and are a couple years old.
I have one lock with 113.22 and two with 128.22. It’s one of the 128.22 locks that is having trouble.
How can I exclude if it isn’t communicating with the controller? I can try to disconnect/reconnect the battery and hope it stays connected long enough to exclude. If that doesn’t work, what else can I try? Should I factory reset it, and try to remove the old node in HABmin?
I’ve always needed the lock to be very close to the controller to include these locks, so exclusion was never an issue. But if it’s having that much trouble communicating, you might want to first try adding another mains powered device betwen lock and controller.
I have a mains powered switch within 2 feet of the lock. Also, the lock has worked well for a year or more. It just recently had this problem. That’s why I think I might need to factory reset it. If that doesn’t work, it may be a hardware failure internally.
Looking at the log above, it looks like it is not securely included - at least it is not responding to NONCE requests which is normal if a device is not securely included. If it is also able to send out battery data, then it would seem general communications is working, but security is not - and this will be required for commands.
Remember that it was working fine - it just stopped communicating on its own. So could it somehow degrade the inclusion by itself? Also, I see this in HABmin - is this where secure inclusion is indicated?
I’m not sure - if it lost the key somehow, then I guess it would not work securely. I’d just be speculating though as I don’t know what the device does
The device is a door lock deadbolt. I haven’t had a chance to work on this for a while. I’ve realized that it is sending reports. I get keypad and manual lock/unlock messages via the alarm_raw channel. The issue is that it doesn’t seem to accept communication initiated by the controller. When I get a moment, I’m going to factory reset it and try re-including.
Okay, exclude and re-include seems to have solved it. I’ll monitor it for a while to see if it goes bad again. Hopefully not as these are expensive locks.
