Zwave.entitiy exists but lock.entity does not

Configuration Z-Wave
1

I had to restart HA a few weeks ago to install a couple more DIMMs in the box and ever since I booted it back up my lock.schlage_be469_touchscreen_deadbolt entities don’t exist anymore. The zwave.schlage_be469_touchscreen_deadbolt entity exists and seems fairly happy, plus I can see it in the Z-wave control panel just fine and also the Z-wave graph add-on. Any ideas? I’d rather not exclude and re-include the lock unless someone is sure that’s the fix, its quite a pain to do so.

node_id: 19
node_name: Unknown Node 19
manufacturer_name: 
product_name: 
query_stage: Complete
is_awake: true
is_ready: true
is_failed: false
is_info_received: true
max_baud_rate: 40000
is_zwave_plus: false
capabilities: routing,frequent,beaming
neighbors: 3,5,6,7,8,10,11,12,13,14,15
sentCnt: 12
sentFailed: 0
retries: 0
receivedCnt: 8
receivedDups: 0
receivedUnsolicited: 0
sentTS: 2019-03-22 10:41:11:692 
receivedTS: 2019-03-22 10:41:13:669 
lastRequestRTT: 1910
averageRequestRTT: 1790
lastResponseRTT: 1977
averageResponseRTT: 2369
battery_level: 97
friendly_name: Front Door Deadbolt
2

In the Z wave panel, see if a Heal Node works. Select the Node and the option will show up. Id also try power cycling the lock (unplug/replug batteries). I seem to have to do this periodically on one of my locks to keep them updating properly.

3

Tried that. I believe that resolves OZW issues. As far as I can tell OZW is plenty happy with the node, I can control the lock and read data from it in the OZW control panel. It’s the HA integration that’s not happy. I’ve read about deleting the XML file and letting HA rebuild it but that sounds a bit risky unless I can get some confirmation that its the right thing to do.

4

Dont know if itll work or not, but worth a try to let it rebuild the xml. Just back everything up first then restore if it doesn’t work as expected. The pairings in the z wave stick itself will not be affected.

I know you said everything worked previously, but it sure sounds like you didn’t do a secure add or let it “talk” for long enough before moving the lock further from your hub.

5

I didn’t move it further from the hub. The devices have been in the same position for months. All that changed was that I had to reboot HA for an un-related hardware change. Since booting it back up all of the rest of the Z-wave devices came back but the lock.entity did not. As I mentioned OZW can communicate bi-directionally with the lock just fine so I don’t think its a Z-wave issue (like not including in secure mode). It’s just that HA isn’t doing whatever it does behind the scenes to turn the matrix of devices that OZW talks to into light/switch/lock entities in the HA side of things. I’ll try the deleting the XML file option the next time I get bored.

6

did you ever find a solution to this? I just rolled out zwave2mqtt and can’t get it to return a lock entity.

7

I don’t know if this will help but I had a similar issue with my garage door opener not having a cover entity… maybe some of the things @firstof9 had me do/check will help you out.

I know it’s a long post but just check around 1000 on that should be some pertinent stuff about checking version of openzwave and ultimately the purge command referenced around there found an errant copy of Ozw… which ha ultimately reinstalled its proper version of ozw after purging the extra…

EDIT: try from this post on… this is how We found the extra ozw stuff … Linear NGDZ00-4 Garage Door - #1035 by freshcoast