Goose66

The teleperiod should be the periodic telemetry messaging for all tasmota devices, right? In other words, the periodic updates in state sent to the Telemetry "tele/" subtopic. But shouldn't the device send state changes to the State "stat/" subtopic as well when state changes? For example, with switches, you get telemetry messages every 90 seconds or so, but you get state messages instantly. Perhaps we need another MQTT Explorer log output watching one of these things to inventory the messages. And if the device doesn't send state messages on state change by default, it seems like it would be easy to set a Tasmota Rule to send a state message upon state change for each state you want reported right away. Also, there appears to be an "Occupancy Delay" parameter that can be set through the plugin (via Admin Console). What is that set to? Is it possible that is where the 10 second delay is coming from?

Just to be clear, this is a problem with the sensor device, not the Tasmota plugin, I assume.

Right. That’s exactly what it was. I also have that USB interface board for loading the flash module. I didn’t remember all the details.

There’s an SSD (not SD card) on the board. Don’t remember the actual interface protocol(s). NVMe? PCIe? eSATA?

Sounds like an SSD card problem. Hope not, but I went through something similar. IIRC, UD had to send me a new module.

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?