Zwave - Yale YRD220 Lock

z-wave
Tags: #<Tag:0x00007f51e08e0ab0>

(Scott Rushworth) #131

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.


(Kris K) #132

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


(Scott Rushworth) #133

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


(Kris K) #134

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


(Scott Rushworth) #135

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") {

(Kris K) #137

Readded the true, removed the (true)
Nothing at all in the logs, openhab.log. No errors in the console. Just the raw event!


(Kris K) #138

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
}


(Scott Rushworth) #139

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") {

(Kris K) #140

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"}


(Scott Rushworth) #141

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.


(Kris K) #142

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


(Scott Rushworth) #143

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?


(Kris K) #144

Hi Scott

Im not using a Pi, Im using a Cisco UCS blade, quad core Xeon, 8 GB ram, RAID1 15K SAS drives :slight_smile:

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?


(Kris K) #145

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


(Scott Rushworth) #146

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.


(Kris K) #147

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.


(Kris K) #148

@5iver post #82 suggests the code 99 thing is fixed


(Scott Rushworth) #149

It is… but you will need to modify the rule. Look at “level” in the alarm_raw data.

Nevermind @chris!


(Kris K) #150

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")
                        }
                    }

(Kris K) #151

So the alarm level corresponds to the user slot,

is Case 1, Slot 1, Case 2, slot 2 etc?