pyschlage library expanded?

[hart2hart]

Good morning @Goose66  I was just reading about the plugin issues related to library version and supporting python version required to run it.  That prompted me to look at the public documentation for pyschlage.  I notice some methods that may have been added at some point.  With these methods (if I read correctly -- big if) could we possibly now detect unlock events and quickly get the user that unlocked it?  for example method below.  Thanks!

lasspyschlage.log.LockLog(created_at: datetime, message: str, accessor_id: str | None = None, access_code_id: str | None = None)

A lock log entry.

access_code_id: str | None= None

Unique identifier for the access code that triggered the log entry.

accessor_id: str | None= None

Unique identifier for the user that triggered the log entry.

created_at: datetime

The time at which the log entry was created.

message: str

The human-readable message associated with the log entry.

[Goose66]

Unfortunately the newer versions of the pyschlage library require Python 3.12 or better. The latest eISY/Polisy firmware has Python 3.11. I don’t believe we can use the newer versions of the pyschlage library.

[hart2hart]

Unfortunately the newer versions of the pyschlage library require Python 3.12 or better. The latest eISY/Polisy firmware has Python 3.11. I don’t believe we can use the newer versions of the pyschlage library.

Thanks. @Goose66 I suspected that it would not be until python was updated on eISY. However, once/if that occurs, would the newer library provide features like detection of who just unlocked the door?

Going into an area I don’t know, do you think/guess will it be possible to use the updated library from another box like rpi or on eISY once the HomeAssitant extension is released to leverage those features?

[Goose66]

I don't think retrieving the log entries is new - it appears available in the version of the API we are using. What is new since the last time you and I talked about adding this feature is the ability to pass both timestamp values and a string value to IoX with state (driver) changes to display in the Admin Console and the UD Mobile app. So we could conceivably parse the latest log entry from the API and add these two states to the node in IoX.

However, this would be for display only. You couldn't really write programs for this, unless the "unique identifier" for the user could be reduced to a, say, 8 digit hash value that you could compare in program code?

Edited Sunday at 09:47 PM by Goose66

[hart2hart]

I don't think retrieving the log entries is new - it appears available in the version of the API we are using. What is new since the last time you and I talked about adding this feature is the ability to pass both timestamp values and a string value to IoX with state (driver) changes to display in the Admin Console and the UD Mobile app. So we could conceivably parse the latest log entry from the API and add these two states to the node in IoX.
However, this would be for display only. You couldn't really write programs for this, unless the "unique identifier" for the user could be reduced to a, say, 8 digit hash value that you could compare in program code?

Thanks. If we get to that point, does it look like access_code_id could be used in programs to identity the code used to disarm?

[Goose66]

Not the access_code_id itself, but maybe a short hash of it - like 8 digits.

Edited Monday at 11:11 AM by Goose66

[Goose66]

So something like this:

Last Access Time: 2024-12-26 08:05:56
Last Access #: 63824331
Last Access Message: Unlocked by Access Code

You would have to do some testing to learn what hash codes go with what access_ids, unfortunately. The Last Access Message may contain the text name associated with the access_id, but it seems like we looked at this before and that wasn’t the case. Perhaps I can retrieve the text name and append it to the message, e.g.:

Last Access Message: Unlocked by Access Code: Goose66

Edited Monday at 11:58 AM by Goose66

[hart2hart]

That sound good! As we discussed in the past (can't find thread or DM but recall the exchange), the ability to catch the unlock event and the Access Code (not the actual number but a representation) would be a great feature for me. 

 

With the Schlage ZWave locks these WiFi versions replaced I used a UserNumber and with that via a program then sent a Disarm security command via Envisalink (likely using NodeLink at that time).  I had a user on the lock with the Distress Code so that code could be entered on the lock to send through as Distress code to alarm monitoring.  This was a big plus when having hands full coming in door located near alarm keypad and even greater to allow entry though doors not near the keypads.

[Goose66]

You must remember that the state here is refreshed by polling of a cloud service like every 20 seconds or so, or every minute if there’s been no activity for a while. Your not going to be able to disarm an alarm system on unlock unless it can be disarmed up to a minute after the code is entered in the lock.

What’s more, if you turn up the frequency of polling, Schlage may end up rate limiting requests or even blocking access for all users.

[hart2hart]

Thanks. I recall that now. Was there something called Force Update you had added that could be used to effectively lower polling interval?

[Goose66]

If you had something that triggered your program in real time, like the alarm panel or a motion sensor, the you could call the Force Update command on the lock  before checking the last access user.

[hart2hart]

Thanks. I could use the alarm open zone via envisalink-DSC because the doors I open are entry delay so could catch that to force update and then get the user.