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 
1 Like
My daughter lives in Chicago. Good thing you weren’t there a couple weeks ago. She said the wind chill of 42 below was unreal…
@5iver if you’re still around
Got the new snapshot installed earlier this morning. We are now getting some alarm_raw data in finally. I am using a version of your rules I found in an old post to get me started, wanted to see if you could help out a little.
rule:
import org.eclipse.xtext.xbase.lib.Functions
rule "Lock: Update lock states after alarm_raw event"
when
Item FrontLock_Alarm_Raw received update
then
val actionItem = gLock.members.findFirst[ item | item.name.toString == triggeringItem.name.toString.replace("_Alarm_Raw","") ]
logInfo("Rules", "Lock: Alarm events: {}=[{}]",actionItem.name,triggeringItem.state.toString)
switch (transform("JSONPATH","$.type",triggeringItem.state.toString)) {
case "ACCESS_CONTROL" : {
switch (transform("JSONPATH", "$.event", triggeringItem.state.toString)) {
case "1", case "3", case "5" : {
actionItem.postUpdate(ON)
logInfo("Rules", "Lock: Alarm events: {} updated to ON (locked)",actionItem.name)
}
case "2", case "4" : {
actionItem.postUpdate(OFF)
logInfo("Rules", "Lock: Alarm events: {} updated to OFF (unlocked)",actionItem.name)
}
case "6" : {
val StringBuilder message = new StringBuilder(actionItem.name)
message.append(" was unlocked with")
switch (transform("JSONPATH", "$.code", triggeringItem.state.toString)) {
case "1" : {
message.append(" user code 1")
}
case "2" : {
message.append(" user code 2")
}
}
logInfo("Rules", "Lock: {}",message.toString)
//SMS_Notification.sendCommand(message.toString)
//Kodi_Notification.sendCommand(message.toString)
}
case "11" : {
logInfo("Rules", "Lock: Alarm events: {} is jammed, so setting lock to OFF (unlocked)",actionItem.label)
actionItem.postUpdate(OFF)
//SMS_Notification.sendCommand(actionItem.label + " is jammed")
//Kodi_Notification.sendCommand(actionItem.label + " is jammed")
}
case "16" : {
val String message = actionItem.label + " keypad is disabled due to too many failed codes"
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
//Kodi_Notification.sendCommand(message)
}
default : {
val String message = "Unknown door lock Event, " + triggeringItem.state.toString
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
}
}
if (transform("JSONPATH", "$.event", triggeringItem.previousState(true).state.toString) == "11" && transform("JSONPATH", "$.event", triggeringItem.state.toString) != "11") {
val String message = actionItem.label + " is no longer jammed"
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
//Kodi_Notification.sendCommand(message)
}
}
case "BURGLAR" : {
//gSiren.sendCommand(ON)
val String message = "Intruder at " + actionItem.label
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
//Audio_Notification.sendCommand(message)
}
case "POWER_MANAGEMENT" : {
val String message = "Power Management alarm for " + actionItem.label + ", " + triggeringItem.state.toString
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
}
default : {
val String message = "Unknown Type in alarmRawParser, " + triggeringItem.state.toString
logInfo("Rules", "Lock: Alarm events: {}",message)
//SMS_Notification.sendCommand(message)
}
}
/*
{"notification":"ACCESS__MANUAL_LOCK", "type":"ACCESS_CONTROL","event":"1","status":"255"}
{"notification":"ACCESS__MANUAL_UNLOCK", "type":"ACCESS_CONTROL","event":"2","status":"255"}
unlocked with zwave? event 3
locked with zwave? event 4
{"notification":"ACCESS__KEYPAD_LOCK", "code":"1", "type":"ACCESS_CONTROL","event":"5","status":"255"}
{"notification":"ACCESS__KEYPAD_UNLOCK","code":"1", "type":"ACCESS_CONTROL","event":"6","status":"255"}
{"notification":"ACCESS__LOCK_JAMMED", "type":"ACCESS_CONTROL","event":"11","status":"255"}
{"notification":"ACCESS__KEYPAD_LOCK", "type":"ACCESS_CONTROL","event":"5","status":"255"}
{"notification":"ACCESS_CONTROL__KEYPAD_TEMPORARILY_DISABLED", "type":"ACCESS_CONTROL","event":"16","status":"255"}
{"notification":"BURGLAR__TAMPER_UNKNOWN", "type":"BURGLAR","event":"2","status":"255"}
{"notification":"HOME_SECURITY__INTRUSION_UNKNOWN", "type":"BURGLAR","event":"2","status":"255"}
{"notification":"POWER__REPLACE_BATTERY_SOON", "type":"POWER_MANAGEMENT","event":"10","status":"255"}
{"notification":"POWER_MANAGEMENT__REPLACE_BATTERY_SOON", "type":"POWER_MANAGEMENT","event":"10","status":"255"}
*/
end
events.log - only getting alarm_raw for codes entered on the keypad (codes 10, & 11)
@openhab-v2:~$ tail -f -n 50 /var/log/openhab2/events.log | grep "FrontLoc*"
2019-02-26 02:39:26.554 [ome.event.ItemCommandEvent] - Item 'FrontLock' received command OFF
2019-02-26 02:39:26.555 [nt.ItemStatePredictedEvent] - FrontLock predicted to become OFF
2019-02-26 02:39:26.558 [vent.ItemStateChangedEvent] - FrontLock changed from ON to OFF
2019-02-26 02:39:26.559 [GroupItemStateChangedEvent] - gLock changed from ON to OFF through FrontLock
2019-02-26 02:39:48.360 [ome.event.ItemCommandEvent] - Item 'FrontLock' received command ON
2019-02-26 02:39:48.362 [nt.ItemStatePredictedEvent] - FrontLock predicted to become ON
2019-02-26 02:39:48.365 [vent.ItemStateChangedEvent] - FrontLock changed from OFF to ON
2019-02-26 02:39:48.371 [GroupItemStateChangedEvent] - gLock changed from OFF to ON through FrontLock
2019-02-26 02:44:51.903 [vent.ItemStateChangedEvent] - FrontLock changed from ON to OFF
2019-02-26 02:44:51.904 [GroupItemStateChangedEvent] - gLock changed from ON to OFF through FrontLock
2019-02-26 02:44:53.977 [vent.ItemStateChangedEvent] - FrontLock changed from OFF to ON
2019-02-26 02:44:53.977 [GroupItemStateChangedEvent] - gLock changed from OFF to ON through FrontLock
2019-02-26 02:45:02.146 [vent.ItemStateChangedEvent] - FrontLock_Alarm_Raw changed from NULL to {"type":"16","value":"10"}
2019-02-26 03:32:17.596 [vent.ItemStateChangedEvent] - FrontLock_Alarm_Raw changed from {"type":"16","value":"10"} to {"type":"16","value":"11"}
openhab.log:
2019-02-26 02:45:02.261 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Alarm events: FrontLock=[{"type":"16","value":"10"}]
2019-02-26 02:45:02.309 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Alarm events: Unknown Type in alarmRawParser, {"type":"16","value":"10"}
2019-02-26 03:32:17.600 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Alarm events: FrontLock=[{"type":"16","value":"11"}]
2019-02-26 03:32:17.603 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Alarm events: Unknown Type in alarmRawParser, {"type":"16","value":"11"}
Any thoughts on getting the rule modified for:
Unknown Type in alarmRawParser, {"type":"16","value":"10"}
Thanks.
Your lock has an older version of the ALARM command class, so alarm_raw comes in with different data. There are some posts with examples of the rule that will work for your lock… or at least get you headed in the right direction. Here’s a start…
1 Like
I’ve just installed and added to my z wave network Schlage FE599NX lock. The only three channels I see are Door Lock, General Alarm and Battery level. Is there a way to add/activate alarm raw channel? I have the newest version (2.5 ) of openhab and addons, update was done two days ago.
Thanks
Welcome to the forum!
The device database has the alarm_raw Channel… https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/403. What is returned when you type this into the console? Maybe you manually installed an older version of the binding at some point?
list -s | grep zwave
Here is the output from the console:
openhab> list -s|grep zwave
254 x Active x 80 x 2.5.0 x org.openhab.binding.zwave
Thanks
Here is listing from addons directory
pi@rpi2:/usr/share/openhab2/addons $ ls -l
total 190268
-rw-r–r-- 1 openhab openhab 190203584 Dec 15 17:56 openhab-addons-2.5.0.kar
-rw-r–r-- 1 openhab openhab 4621449 Jun 12 2018 org.openhab.binding.ipcamera-2.3.0-SNAPSHOT.jar
-rw-r–r-- 1 openhab openhab 70 Dec 15 17:56 README
Should I try to uninstall ad install again zwave binding ?
Thank you
You have the 2.5 version of the binding. What’s making you think the alarm_raw Channel isn’t there?
Here is the screenshot from PaperUI:
The channel type is Switch and the only item I can link to this channel is Switch.
Thank you
I corrected the issue by
- Uninstalling zwave binding
- restarting openhab
- installing zwave binding
- removing thing for lock
5 adding thing back
Now the alarm channel has type string and the name “Alarm (raw)”
Thanks
Others would know better, but the only explanation I can think of is that you had created a Thing for the lock with a previous version of the binding. That does not seem possible though, since you had said that you had only just added it.
Glad you got it working!
1 Like