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?

The plugin is successfully sending the correct codes for Armed Zero Entry and Armed Stay to the EnvisaLink. If one is working and one is not, I have to believe it has something to do with your DSC Panel configuration (I know you won't believe that). Try Arming your system with Zero Entry from your alphanumeric keypad. Does it work? Does it ask for a passcode? If you arm for Stay or Away from the keypad, does it ask for a passcode then?

It looks like clicking the button in IoX is calling the correct piece of code, and the plugin is subsequently sending the right command to the EVL successfully. The recent update didn't change this particular piece of code, or any of the code for the partition node. Some things to clarify: 1. Do ALL of the other arming options work? 2. Have you recently updated your EVL firmware? 3. Have you set the logging level for the plugin to "Debug" and retried to see what additional info there is? NOTE: I believe the three, identical log entries is a bug in the PG3x front-end ("Dashboard") and not something actually being produced by the plugin. This can be confirmed if you are seeing every log entry repeated three times.

Ok, there are no errors starting the plugin in the PG3 log file. In fact, PG3 logs "2025-03-16 17:25:34.703 [pg3] info: startNs:: Schlage started." Yet it appears that the plugin is not starting. I am pretty sure I have seen this situation before -- I think with a different plugin -- but for the life of me can't remember how we debugged it. I will have to dive a little deeper.

Not that it matters here since you have no Else statements, but be aware that this program will also run every time the Gates_ProgON variable is changed.

The web pages on Paul Weilands site aren’t structured the best for sure, but for many that just follow the instructions from the beginning, it all goes off without a hitch. I think the fact that you were trying to Download the OTA binary instead of using the ESPHome firmware installation tool was throwing things off. Also, if you were getting shocked when touching the board, that means you were handling an unenclosed circuit board while it was powered up - not a good idea. In the “Installation Error” screenshot you posted, there were some troubleshooting steps. Did you try those?

@tjmeiner Can you send the log file for the plugin, not the PG3x log file. It is available in the PG3x Dashboard, under "Details" for the plugin by selecting the under "Log" button. That's also where you set the logging level to "Debug" for the plugin.

My Schlage plugin is working fine with my two locks on my production Polisy running IoX v.5.90.1 and PG3x 3.3.18. Please set the logging level for the plugin to Debug in the PG3x Dashboard, restart your plugin, let it run for 5 minutes or so, and then send me a log file. You may want to DM the log file directly to me because it may have your password in it.

I haven't upgraded my test polisy to see if the schlage plugin has an issue. I should be able to check it this weekend.

Sorry I can’t help with any of that. Perhaps others can share their experience.

I would suggest factory resetting your device and start again from scratch following the directions at https://paulwieland.github.io/ratgdo from the beginning. If you can open and close the door through the web interface but the plugin still doesn’t discover the device, we can go from there.