[SOLVED] Schlage FE599NX Node XML / PaperUI

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:

Looking at this page: https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/403#, it shows that it should have 2 association groups. The lock isn’t reporting to the controller when using the lock manually.

This is the node.xml I have for the device:

<associationGroups class="concurrent-hash-map">

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.


Group 2 has been added a month ago, so first thing to do is upgrade to the latest 2.5 Zwave snapshot binding and delete the Thing and readd it.

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.

Is there a way to view the alarm_raw data?

I’ve got the 2.5 snapshot installed. No luck on seeing any changes in the events.log.

Yes, it’s a String, so make an item and link it. You’ll see it get updated in your events.log.

This is from the post where you can see a linked String for the raw channel. You can either link it in the items as done here or via paper ui.

String 	                   Lock_EntranceFront_Alarm_Raw           "Lock (Front Entrance): Alarm Raw [%s]"       <shield>               {channel="zwave:device:55555:node5: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?

There is no alarm_raw Channel configured for your device… https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/403.

So there’s probably no way to log who’s coming in I guess?

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.

Just before I got the notification that you replied, I got this from Schlage (hopefully I can upload it).

BE369 and FE599 Z-Wave Abstract.pdf (322.7 KB)

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.

Thanks again for your help.

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.

Thanks Scott. I’ll take a look tonight but maybe will leave this as is…

(Just passing through a somewhat chilly Chicago)

Hey… you’re only 6 hours away… just head east!

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 :wink:

1 Like