I just got the Schlage FE599NX lock. It seemed to add quite easily to the controller. One thing I’ve noticed, is that I only have 1 association group in PaperUI / Habmin:
Under association group 2, it shows 0 max nodes vs 1 on the device page mentioned above and 5 max nodes for group 1, vs 0 in the XML.
I can control the lock via openhab, and it will report in the events log, but not when using the lock itself. I’ve also read about using alarm_raw and json, but have no idea where to view it. I’d like to record events when the lock is used manually but one thing at a time I guess.
Strangely, not all updates are sent directly by the lock (at least for my Schlage BE469NX). If you look closely at @5iver’s post here, you’ll see that it uses the alarm_raw channel to update the lock status. I don’t know why the lock doesn’t report directly, but the alarm_raw rule works for me. Look for the “actionItem.postUpdate()” lines in the rules. Maybe group 2 will help you, but if not, try the rule for the alarm_raw.
I put this bit in yesterday when I added the lock to the system, the alarm_raw is already in there:
Switch FrontLock "Front Door Lock [MAP(lock.map):%s]" <lock> (gLock) {channel="zwave:device:4d64ad4b:node46:lock_door"}
Switch FrontLockAlarm "Front Door Lock Alarm [%s]" {channel="zwave:device:4d64ad4b:node46:alarm_general"}
String FrontLock_Alarm_Raw "Front Door Lock : Alarm Raw [%s]" <shield> (gLock) {channel="zwave:device:4d64ad4b:node46:alarm_raw"}
Number FrontLockBat "Front Door Lock Battery [%d %%]" {channel="zwave:device:4d64ad4b:node46:battery-level"}
The following is only when it’s controlled by openhab. No entries at only when using the actual lock.
tail -f -n 50 /var/log/openhab2/events.log | grep FrontLock
2019-02-05 12:19:36.166 [ome.event.ItemCommandEvent] - Item 'FrontLock' received command OFF
2019-02-05 12:19:36.171 [nt.ItemStatePredictedEvent] - FrontLock predicted to become OFF
2019-02-05 12:19:36.181 [vent.ItemStateChangedEvent] - FrontLock changed from ON to OFF
2019-02-05 12:19:36.183 [GroupItemStateChangedEvent] - gLock changed from ON to OFF through FrontLock
2019-02-05 12:20:44.180 [ome.event.ItemCommandEvent] - Item 'FrontLock' received command ON
2019-02-05 12:20:44.185 [nt.ItemStatePredictedEvent] - FrontLock predicted to become ON
2019-02-05 12:20:44.186 [GroupItemStateChangedEvent] - gLock changed from OFF to ON through FrontLock
2019-02-05 12:20:44.189 [vent.ItemStateChangedEvent] - FrontLock changed from OFF to ON
There were no entries in events.log for FrontLock_Alarm_Raw at all.
Would it matter if there isn’t a (Front Entrance) between the parentheses?
Not currently, but alarm_raw can be easily added. There are also no configuration parameters in the db. We need to find a technical manual for the device, with zwave info. If you get that, I can add them.
It looks like there is another command class (MULTILEVEL_SWITCH) too. But haven’t been able to find the configuration parameters. Also, this lock only uses ALARM V1, so some changes would be needed to use the rule I’d posted. Schlage support has been very nice to work with. They actually sent me new locks when I asked them for a firmware upgrade, and let me keep the old ones! So, try contacting them for the configuration parameters. Their webiste provides them for the BE469.
I’ve tried touching base with Schlage support, and hadn’t had much luck with them. They first sent me a PDF of the installation instructions, and when I replied to that to see if they had anything more technical, I haven’t heard back. The lock is sending out info when a code is entered into it. I’ve tried comparing logs with different codes to see if I can see any differences, but it’s all beyond me. Would the logs help in figuring out alarm_raw?
I went ahead and changed alarm_general Channel to alarm_raw for you, so this should show up in a snapshot build of the binding in few days. If you get hold of the config params, they can be added later. They will likely be similar to the BE469, maybe identical. I actually called in to Schlage and spoke to someone, and got great support, so you may want to see if that gives better results. If you do, ask them if the lock reports it’s state through zwave, and maybe what the other command classes are used for.
Some of the other locks require using alarm_raw to figure this out. But yours has other command classes, so your lock may report the lock state all on it’s own. A debug log may help to determine this. This log will contain security info though, so you may want to PM it to me. In the log, include manually locking and unlocking, as well as locking and unlocking from the keypad.
The lock is now reporting it’s state to the controller. There is an alarm switch that had to be turned on for it to start reporting it. Thankfully it works, since sometimes the dog will hit the unlock switch with his paw when he looks out the window beside the door. I’ve had to create a rule to relock it in case this happens. What I’m still looking for are events when the door is opened using the code and which code was used (hopefully). I will grab some debug code to hopefully help with that.
Interesting… so it has the same board as the BE369. There is possibly an updated version of the lock though, based on the info provided by Zwave Alliance, since they list a couple more command classes. As I mentioned, log may show if they could be useful. This is the info needed, so I will add it in for both locks.
@chris, if these two locks (FE599NX and BE369) are in fact the same, should we keep them as separate entries, or combine them? The additional CCs may be due to an updated firmware, but we haven’t identified what the versions may be, or what they actually do.
Since the Schlage document seems to indicate they are the same, then it probably makes some sense to only have a single database entry.
I haven’t checked that the channels are the same (I’m travelling all day today) but if they are then it should be as simple as changing the IDs and marking one as deleted.
The document from Schlage shows them as identical, except for the product ID. However, I didn’t notice before that the BE369 is a deadbolt and the FE599 is just a lock, so the images are different. Maybe to avoid confusion, these should just be left in the db? I’ll leave it up to you… I’ve updated both.
Yeah - I couldn’t quite remember if you were here or somewhere a little further out, but this was all a little short notice and I only had a short stop.
It’s a nice day, but I wasn’t quite prepared for the temperature with the 10 minutes wait for a bus to change terminals
