My question regarding the issue with lock.clear_usercode not working for others is does the workaround of setting the usercode to 0000 cause the lock to allow entry with the usercode 0000? I wouldn’t want to change it to such an easy code even though no one necessarily knows it. Or does it disallow entry?
I have to use that workaround to clear codes on my schlage connect. It does clear the code- 0000 does not become a valid code.
I can’t get this to work. When I use lock.clear_usercode it doesn’t work at all, and when I set the usercode to 0000 I actually can enter the door using 0000 as a code which is definitely not what I want.
I keep getting “invalid json” when I use your code in the Services section. Any idea what I’m doing wrong?
I looks like the forum software converted the quotes to unicode quotes. Replace with regular quotes and see if that works for you.
That worked! Thanks!
does anyone know how to change the name from lock.locked to something else? Maybe lock.front_door for example.
Change the name in the entity_registry.yaml file.
lock.front_door:
platform: zwave
unique_id: 19-72057594362494976
Has any one gotten the reporting of the user code used to unlock the door working. I really need to be able to trigger automation based on the user code that was used to unlock the door. The lock that I am trying to accomplish this with is a Schlage Z-Wave Home Keypad Lever FE599NX
1 Like
I’ve never had any luck with the FE599NX (Lever) reporting anything on it’s own (yes, it was added as a secure node and I do indeed have a network key set). I poll it every minute to make sure I catch it if it’s unlocked with the button at the door. Locking and unlocking works fine within home-assistant though. I’ve watched the z-wave logs and all I ever see are actions initiated by home-assistant.
I’ve been using it for over a year now and it works fine for locking/unlocking but I’ve never been able to use the added functionality.
I had it included on my ISY994i/zw for a short period and it did report user codes with the ISY but it never has while included with home-assistant and my the Aeotec Z-Stick dongle.
Also, I can set user codes via home-assistant but I’ve never been able to clear them using any of the methods in this thread.
At this point I’ve conceded that the fe599 lever is just a bit of a different beast and I’m just glad I can use the basic functionality of the device.
You need to get your device added to Open Zwave so you can use the rest of the functionality. If you pull in those config changes you will be able to use your lock the way it is meant ot be used. Without support from open zwave all you will get is lock/unlock functionality.
@tobas
You need to add your controller (node 1) to the the 2nd association group on the lock. In the Z-Wave settings for that node, it’s under “Node group associations.” Add your Z-Stick/controller to group 2 as the “node to control” and remove it from the 1st group. You should then get real-time status updates.
Note: I believe this is fairly specific to the FE599 and BE369 locks from Schlage, others shouldn’t require this.
4 Likes
No idea how you figured out that whole 2nd association thing @david202 but thanks for posting about it. I have the FE599 and always wondered why it reported things pretty well under Vera and so crummy under HA. I was able to add my Z-stick to group 2, but have been unable to remove it from Group 1. Even with restarts, etc. The good news is that instant update of lock status seems to be working fine even with the Z-stick in both groups. I’m using hassio so I only have the Z-wave management within that.
I used to have alarm_type and alarm_level sensors for this lock which I hid in HA because they were fairly useless, I removed the hiding customizations but they seem to be gone for good. I was hoping to see if I could get any new info out of the lock (like which code unlocked it) but alas the only improvement I’ve seen so far is instant update when the lock or unlock button (on the inside of the door) are pressed. Still nothing when a code is used on the outside of the door to momentarily unlock.
@david202, You’re awesome! Adding the controller to group 2 was downright magical as it reports status instantly now so I was able to remove the polling! I haven’t dug into the Alarm Type, Alarm Level reports yet but it’s at least reporting something for those values now.
Thank you so much!
There seems to be something weird going on with removing node 1 from group 1 in HA. The right message is getting sent and it looks like it is actually removed but HA doesn’t seem to be updating correctly to show it was removed. Doesn’t really matter, the critical part is adding it to group 2. I’m not 100% sure if this is something that needs to be fixed in HA or OpenZWave. As a reminder for future readers, as far as I know the FE599/BE369 locks from Schlage are the only devices that have this odd group 1/2 behavior.
I’m working on setting up automation triggers based on user codes entered at the lock (which I have working with the newer Schlage Connect locks). In this case, the Alarm Type is 16 and the Alarm Level is the user code slot that was used. The problem is that this only triggers a state change in HA when you enter in a different code, in other words if you re-enter the same code a few times, you’ll only get one trigger. The state is updated/refreshed each time though, so I’m hoping to use that combined with the alarm values to create a sensor to trigger from. The force_update entity parameter also looks interesting (causing an entity to trigger a state change on any update) but I’m either doing it wrong or it isn’t implemented for Z-Wave devices. I’m planning to dig in more and start another thread here for some help.
I decided to bring my RPi closer to my door to do remove node and re-add the node in order to try to get alarm_level and alarm_type back, but after booting it up closer to the door, those are now showing even without going through that exercise.
What I’m seeing now is that alarm_level shows 1 or 2 based on which user code I enter at the keypad (we only use 2) or 255 if I enter an invalid code too many times. Alarm_type shows 16 if I entered a valid code or 96 if I enter an invalid code too many times. Neither one of these sensors change if I lock or unlock the door from the inside buttons.
Another change I’m seeing is that where I used to have a slider to lock or unlock the door (and show current status), now it just has the word Locked or Unlocked and I can’t actually actuate the lock:
Edit: rebooted again, the slider came back but doesn’t work - it shows the lock status accurately but if I manually slide it, it just slides back to where it was.
@kap That’s the correct behavior for the alarm type/level. The alarms you’ll see are:
- Alarm type 16, alarm level is the user code used
- Alarm type 96, alarm level is 255 to show that the keypad was locked due to incorrect code entry
Neither of those will change based on locking/unlocking, those are different messages (at least on FE599/BE369). I haven’t seen any issues with locking/unlocking from HA, that works fine for me.
I have the lock reporting correctly the user code that was used to unlock the door and can trigger an automation based on the user that unlocked the door but I can not figure out how to set the “Door Lock Alarm Level” back to 0 after the trigger. The problem that I am having is if I unlock the door with my code which is “user code1” the “Door Lock Alarm Level” reports 1 which is correct but if I unlock the door again the value still remains 1 and will not activate the automation. If I unlock the door with “user code 2” then it reports “Door Lock Alarm Level” 2 which is correct and then use “user code1” the automation will trigger. I need to find a way to set the “Door Lock Alarm Level” back to “0” after the automation runs so that if the same user unlocks the door in a row the automation will still trigger. sure hope this makes sense and someone can help
How many sensors should we be expecting from this device (Schlage Connect)? When I first did the secure pair, I had 7 sensors and a lock. After restarting home assistant and waiting there are only 2 sensors now (alarm_type and alarm_level).
Also, this device (Node ID 39 in my case) doesn’t show up in my zwcfg xml file. Should it be in there? Every other zwave device is in that file. This is the first secure device I have added though.
I finally got things working after several frustrating hours. It seems that renaming the new sensors before restarting home assistant was the culprit.