Goose66

Manually yes, but if I went to the device in UD Mobile or Admin Console and turned it on, then the keypad light wouldn’t turn on. And if the device is in other scenes and is turned on or off via those scenes, then the keypad light wouldn’t be updated. The only way to keep them in sync is with a key state update program.

Problem with Techman’s approach is that if something ever turns the device on or off directly, e.g. a user in UD mobile, or if it is also in other scenes, the keypad light won’t track with the device state. By having separate programs that update the key light state, they should stay in sync.

You can put the key light state in a scene and your program can turn the key light scene on or off based on change in state of the associated mini module.

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.

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.

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

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

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?

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.

Hmmm... Well the fix of specifying the specific version of the pyschlage library didn't work, obviously, but I was afraid that would be the case. We may need some help from UD on determining why the plugin won't start, despite the PG3 log file saying it's starting fine. I think there is a file called "crash.log" that may contain the information we need, but there is no way to access it without SSH to your device. Even if we did know exactly why it wasn't starting, I don't know that we could fix it without also using complex commands via SSH. Can you open a ticket with UD on this and maybe they can point us in the right direction?

Actually, forget the PG3x log file. We need to get SSH access to the eISY. Let me know if you can set that up.

Installed in a different slot number, right?

A new version of the Schlage plugin is available in the Plugin Store. Try uninstalling and reinstalling the new version in a different slot number and let me know if that fixes your problem. You'll have to change any programs.

Yes. It appears that newer versions of the pyschlage library utilized by the plugin require Python 3.12 or newer (3.12 Released October 2023; latest release is 3.13). The current version of Python on the eISY is Python 3.11. I'm trying to figure out how to fix it. Setting the install script to install the correct, older version of pyschlage is easy, but that won’t fix current installs, potentially even if you uninstall and install again (once the updated plugin with a new install script is uploaded). Can you SSH to your eISY? Ironically, this is the only plugin I have written that uses a third party API library. I’ve always written my own because I was afraid of this exact problem.

Are you sure the ratgdo has a reliable wi-fi connection in the garage? Especially sitting on top of the GDO motor? I have a wi-fi extender in my garage (for my Tesla and wall charger - not specifically for my ratgdos) but I know my regular wifi is not accessible there. Is access to the onboard webpage and operation of the doors from that page reliable?