Do you still see alarm_raw events? If so, what log entries from the rule do you see? There is a log entry at the second line of the rule, so you should at least see this, or it would appear as though the rule is not triggering. It would probably be helpful to see what modifications you’ve made to the rule.
Sorry Scott, i just updated my post. Yes,I see the raw events. The rule is posted above.
21:59:26.416 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock_Alarm_Raw changed from {"parameter-4":"1","notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","level":"251","type":"ACCESS_CONTROL","event":"6","parameter-1":"99","parameter-2":"3","status":"255","parameter-3":"251"} to {"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"2","type":"ACCESS_CONTROL","event":"1","status":"255"}
21:59:26.427 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'Lock: Update lock states after alarm_raw event': cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.persistence.HistoricItem.getState() on null
Are you using MapDB? You’ll need to use something that has historical data, or change this…
if (transform("JSONPATH", "$.event", triggeringItem.previousState(true).state.toString) == "11" && transform("JSONPATH", "$.event", triggeringItem.state.toString) != "11") {
… to…
if (transform("JSONPATH", "$.event", triggeringItem.previousState.state.toString) == "11" && transform("JSONPATH", "$.event", triggeringItem.state.toString) != "11") {
At least, I think that was what fixed it for MapDB users. 
1 Like
Yes, I’m using Mapdb. It was set to influx, but ive changed it to MapDB as default. I modified the rule to remove the single occurance of
(true)
And that has removed the error but I dont see any item updates
22:27:21.831 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock_Alarm_Raw changed from {"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"2","type":"ACCESS_CONTROL","event":"1","status":"255"} to {"parameter-4":"1","notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","level":"251","type":"ACCESS_CONTROL","event":"6","parameter-1":"99","parameter-2":"3","status":"255","parameter-3":"251"}
22:27:46.056 [INFO ] [smarthome.event.ItemStateChangedEvent] - AtticVoltage changed from 237 to 236
22:27:46.059 [INFO ] [smarthome.event.ItemStateChangedEvent] - AttickWhToday changed from 1.024 to 1.032
22:27:46.060 [INFO ] [smarthome.event.ItemStateChangedEvent] - AttickWhTotal changed from 30.544 to 30.551
But what do you see in the openhab.log? There should be log entries from the rule… possibly more errors. Your alarm_raw data also seems odd… I’ve never seen parameter stuff in mine.
If you still have Influx up, and are persisting the locks to it, then you coud also just specify the persistence type, like (this is from memory though)…
if (transform("JSONPATH", "$.event", triggeringItem.previousState("influx", true).state.toString) == "11" && transform("JSONPATH", "$.event", triggeringItem.state.toString) != "11") {
Readded the true, removed the (true)
Nothing at all in the logs, openhab.log. No errors in the console. Just the raw event!
Using the above with influx, true gives this error:
22:48:23.897 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'Lock: Update lock states after alarm_raw event': An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.persistence.extensions.PersistenceExtensions.previousState(org.eclipse.smarthome.core.items.Item,boolean,java.lang.String) on instance: null
With this persist file:
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
default = everyChange
}
Items {
// persist all members of gInfluxDB Group on: everyChange, everyHour, everyDay
gSNMP* : strategy = everyChange, everyHour, everyDay
gInfluxDB*,gSpotify* : strategy = everyChange, everyHour, everyDay
gPowerUsage* : strategy = everyChange, everyHour, everyDay
gPowerUsage : strategy = everyChange, everyHour, everyDay
FibaroEye1Temp : strategy = everyChange, everyHour, everyDay
AtticTemp : strategy = everyChange, everyHour, everyDay
AtticHumidity : strategy = everyChange, everyHour, everyDay
CarportTemp : strategy = everyChange, everyHour, everyDay
CarportHumidity : strategy = everyChange, everyHour, everyDay
UPS_Battery_Runtime : strategy = everyHour
FrontDoor_DoorLock_Alarm_Raw : strategy = everyChange
}
I looked it up… it should be…
if (transform("JSONPATH", "$.event", triggeringItem.previousState(true, "influx").state.toString) == "11" && transform("JSONPATH", "$.event", triggeringItem.state.toString) != "11") {
Thanks Scott
Made those changes.
Sigh!
I changed “influx” to “influxdb” and that appears to have done the trick. No more errors BUT… it doesnt work using the keypad, only using PaperUI. When I say doesnt work, I see no log updates or item updates.
HOWEVER, when using PaperUI to lock or unlock, the logs and items update. This appears onyl related to using the keypad to lock or unlock
07:23:31.839 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'FrontDoor_DoorLock' received command ON
07:23:31.842 [INFO ] [arthome.event.ItemStatePredictedEvent] - FrontDoor_DoorLock predicted to become ON
07:23:31.844 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock changed from OFF to ON
07:23:31.846 [INFO ] [home.event.GroupItemStateChangedEvent] - gLock changed from OFF to ON through FrontDoor_DoorLock
07:23:36.614 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock_Alarm_Raw changed from {"notification":"ACCESS_CONTROL__REMOTE_UNLOCK","level":"1","type":"ACCESS_CONTROL","event":"4","status":"255"} to {"notification":"ACCESS_CONTROL__REMOTE_LOCK","level":"1","type":"ACCESS_CONTROL","event":"3","status":"255"}
Where are the logs from the rule? Note, they are logDebug, so you may need to change the logging level (log:set DEBUG org.eclipse.smarthome.model.script) to see them. Changing them to logInfo may work too. Then, what do you see in the log when you manually lock/unlock to door? There should be stuff from alarm_raw (events.log) and the rule (openhab.log)… and maybe an error.
Hi Scott
I changed all logDebugs to logInfos, unlocked with the keypad and this appears:
07:51:15.801 [INFO ] [del.core.internal.ModelRepositoryImpl] - Refreshing model 'frontdoor.rules'
07:51:28.665 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock_Alarm_Raw changed from {"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"2","type":"ACCESS_CONTROL","event":"1","status":"255"} to {"parameter-4":"1","notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","level":"251","type":"ACCESS_CONTROL","event":"6","parameter-1":"99","parameter-2":"3","status":"255","parameter-3":"251"}
07:51:29.074 [INFO ] [.eclipse.smarthome.model.script.Rules] - Lock: Alarm events: FrontDoor_DoorLock=[{"parameter-4":"1","notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","level":"251","type":"ACCESS_CONTROL","event":"6","parameter-1":"99","parameter-2":"3","status":"255","parameter-3":"251"}]
07:51:29.078 [INFO ] [.eclipse.smarthome.model.script.Rules] - Lock: FrontDoor_DoorLock was unlocked with
unlocked with… and it didnt finish the sentence
Two minutes later
07:53:35.707 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock changed from ON to OFF
07:53:35.708 [INFO ] [home.event.GroupItemStateChangedEvent] - gLock changed from ON to OFF through FrontDoor_DoorLock
And doing it again, looks ok??
07:54:14.152 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock_Alarm_Raw changed from {"parameter-4":"1","notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","level":"251","type":"ACCESS_CONTROL","event":"6","parameter-1":"99","parameter-2":"3","status":"255","parameter-3":"251"} to {"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"2","type":"ACCESS_CONTROL","event":"1","status":"255"}
07:54:14.158 [INFO ] [.eclipse.smarthome.model.script.Rules] - Lock: Alarm events: FrontDoor_DoorLock=[{"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"2","type":"ACCESS_CONTROL","event":"1","status":"255"}]
07:54:14.162 [INFO ] [.eclipse.smarthome.model.script.Rules] - Lock: Alarm events: FrontDoor_DoorLock updated to ON (locked)
07:54:14.163 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontDoor_DoorLock changed from OFF to ON
07:54:14.164 [INFO ] [home.event.GroupItemStateChangedEvent] - gLock changed from OFF to ON through FrontDoor_DoorLock
The first use of a rule will always take longer than the second run. You must be using a Pi, because that took a long time!
Also, you used code slot 99, so will need to change the rule to match your lock code slots. Although, I remember someone else reported that they always got code 99, but I think that was fixed.
@chris, was this ever resolved?
Kris, you’re on at least 2.4, right?
Hi Scott
Im not using a Pi, Im using a Cisco UCS blade, quad core Xeon, 8 GB ram, RAID1 15K SAS drives 
I’m on 2.4 stable with the latest 2.5 snapshot zwave binding. I have defined no codes at all. Just the master
It appears to lock and display fine, but unlocking isnt updating the item (PaperUI shows ON) when unlocked. Not sure what you mean about updating the rule to match my lock slot?
Just added a code in slot 1, it unlocks fine, but has the same message with ‘unlocked with’ and the Code is 99. Im assuming that should be 01, or 1
Wait a minute… lol. Something is missing from the rule! There’s no postUpdate to change the switch state after using a user code! I use Jython, and have it in there, and it’s also in my backup of my DSL rules, so I must have accidently deleted the line at some point. I’ll put it back in… sorry! [Edit: I know when I did it… in my rule, I use the lock codes as a backup for our presence detection, so I had a Thread::sleep in there to make sure the door unlocking didn’t set off an alarm. I had removed that, and must have deleted too much!]
Now, how did Front_DoorLock change without the rule? If your lock reports it’s own states, then you might not need the rule at all. Hmmm. Two minutes does not sound right though, either way.
Definitely shouldn’t be 99, so sounds like this is still an issue.
hey Scott all good! ill do a compare to see where it was added in post #5
no doubt @chris will need a debug so ill provide that this morning to look at the code 99 stuff.
It is… but you will need to modify the rule. Look at “level” in the alarm_raw data.
Nevermind @chris!
Hi Scott
Im not really familiar with how the rule works, what do each of the case numbers refer to?
Im assuming this is the bit I need to modify:
case "6" : {
actionItem.postUpdate(OFF)
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")
}
}
So the alarm level corresponds to the user slot,
is Case 1, Slot 1, Case 2, slot 2 etc?
