@Goose66 , this node server is great. I've been using open action of Schlage lock to disarm my security system for a few months and with Force Update, its great! There is a "flaw" in my programming that I recognized with my scheme, so I always make sure the last message is locked by handle on the door. Without describing it completely, with scheme I'm using if last message was a disarm with code. and I forgot to actually lock the door then just opening the door would result in a security disarm. Now that Apple Key is working, I want to expand auto disarm to four other locks but not with the flaw that requires me to confirm contents of last message each time security is armed at all locks

Methods I've considered:

1) Get last message time and confirm it was in the last say 10-15 seconds. Issue is I can't locate how to manipulate current time into epoch time with eISY program (also couldn't find a node server that does it) to do the math. On one of Jimbo Automates node servers, he added seconds since last update element so someone could monitor the device had not changed. Would that we possible with this node server? It feels this would be the best option. to control and feel good about not hosing security. EDIT - I just located how to set variable to current epoch time so evaluating how that might help.

2) Another possibility would be if there was a way for me to request node server to clear the last message and user code fields at the time security is armed. Flaw here would appear to be would the fields get set again at time I did Force Update.

3) Finally, at the time the security system is armed, store and persist the current value of Last Update epoch time in a variable and then when using mostly my current scheme add to the If to say current last update time is not same as the value stored in the variables. Easy enough it appears, does it sound reasonable to prevent what I described as the flaw. What do you think? Example programs using this method:

Security:Store Last Update Times for Locks at Armed

If

$Security_Armed is 1

Then

$Security_Armed_Garage_Deadbolt_Last_Message_Time_I = 'Garage / Garage Door' Last Message Time Unix Timestamp

$Security_Armed_Garage_Deadbolt_Last_Message_Time_I Init To 'Garage / Garage Door' Last Message Time Unix Timestamp

Garage:Deadbolt Entry Delay Disarm With Schlage Code

'Security System / Security System:Partition' Partition State is Entry Delay

And 'Security System / Zone:Garage Door' Zone State is Open

Then

Wait 1 second

Set 'Garage / Garage Door' Force Update

Action of Short poll (10 seconds) or the Force Update from above triggers following programs

Garage:Deadbolt Unlocked By Paul

If

'Garage / Garage Door' Last Access Code Used is '$Security_Code_Paul_I User Number'

And 'Garage / Garage Door' Last Message Time is not '$Security_Armed_Garage_Deadbolt_Last_Message_Time_I Unix Timestamp'

Then

Set 'Security System / Security System:Partition' Disarm (it uses the user code to disarm but that doesn't show in the program copy to clipboard)

Garage:Deadbolt Unlocked By Wife

If

'Garage / Garage Door' Last Access Code Used is '$Security_Code_Wife_I User Number'

And 'Garage / Garage Door' Last Message Time is not '$Security_Armed_Garage_Deadbolt_Last_Message_Time_I Unix Timestamp'

Then

Set 'Security System / Security System:Partition' Disarm (it uses the user code to disarm but that doesn't show in the program copy to clipboard)

Edited December 6Dec 6 by hart2hart

...a bit more, the fields for the deadbolt from node server appear to only support Status and not Control so this means if field happens to have same value as last time, it will not trigger -- correct? If that is the case, should I put in an additional If like IF the epoch date is > 0 to ensure it always triggers program when it changes? Can the field be defined so it triggers with Control or Status? It feels like the IF section for comparing Old stored and current event epoch times may always force a trigger as the new date changed.

Edited December 7Dec 7 by hart2hart

Still researching and testing. There are three messages in last message list without a description. They are:

o Unknown

o Unknown (both unknowns show at the top of the drop-down list)

o 31

Also, there is a message type called "History Cleared" in the drop-down list. Does that imply the node server could have a command that would clear all history. If so, I could run that command when security is armed to make it simpler as I suggested in option 2 of original post.

Edited December 8Dec 8 by hart2hart

What is expectation for the data to update after the Force Update command is issued?

I'm getting odd results but when trying to debug I realized the fields like last message, access code, and last time are not flowing into the general eISY logging system.

The following programs trigger based on the last way the deadbolt was unlocked without the code from above that does a Force Update even running. I could see that last message is "Locked by Schlage Button" so I'm lost.

Garage:Deadbolt Unlocked By Apple Key - [ID 01F6][Parent 0124]

If

$Security_Allow_Schlage_To_Disarm_I is 1

And 'Garage / Garage Door' Last Message is Unlocked by Apple key

And 'Garage / Garage Door' Last Message Time is not '$Security_Armed_Garage_Deadbolt_Last_Message_Time_I Unix Timestamp'

And 'Garage / Garage Door' Last Message Time > 0.0 Unix Timestamp

Then

Set 'Security System / Security System:Partition' Disarm

Send Notification to 'JPaulText' content 'Security Disarmed Via Schlage Message'

Else

- No Actions - (To add one, press 'Action')

Garage:Deadbolt Unlocked By Paul - [ID 0125][Parent 0124]

If

$Security_Allow_Schlage_To_Disarm_I is 1

And 'Garage / Garage Door' Last Message is Unlocked by keypad

And 'Garage / Garage Door' Last Access Code Used is '$Security_Code_Paul_I User Number'

And 'Garage / Garage Door' Last Message Time is not '$Security_Armed_Garage_Deadbolt_Last_Message_Time_I Unix Timestamp'

And 'Garage / Garage Door' Last Message Time > 0.0 Unix Timestamp

Then

Set 'Security System / Security System:Partition' Disarm

Send Notification to 'JPaulText' content 'Security Disarmed Via Schlage Message'

Else

- No Actions - (To add one, press 'Action')

Edited December 9Dec 9 by hart2hart

Any possibility that recent Polyglot upgrade could have contributed to this?

I've confirmed as much as I can that it is triggering programs based on "old" message data that I cannot see in AC and UD Mobile because the last message data I see should not be triggering the programs. I'm going to test by increasing short and long polling as I think that is when the program is triggering with what appears to be stale data to me.

@Goose66 Without Plugin writing to log, I've done about as much as I can. I had iPad with UDM running so I could watch Schalge last fields.

When I increased the short poll, the issue of immediately disarming went away so short poll was causing the trigger.

With short poll being longer, I closed and locked deadbolt and last message did not change so I press Force update on iPad UDM. This seemed to keep it from "false" triggering based on old data. Program that would have disarmed security did not trigger but this was mangled around the issue with the DSC plugin not working properly after power failure reboot.

It's hard to be certain but it appeared there was a time when Force Update from program only updated the last message time but not the message, so program triggered based on message time change. However, it still had message from the last time i unlocked the deadbolt vs message where i just locked the door to do the test.

Sorry for all the typing and conjecture on my part, how can I/we debug?

Thanks

Edited Saturday at 10:26 PM2 days by hart2hart

There's a lot of information here and I have to admit I am not following a lot of it. Two responses after a quick review:

1. As far as the plugin not writing to the log, I am not aware of any change in PG3 that would prevent a plugin from writing to the log file. The log file viewer in PG3, though, has always been a little squirly (or just broken depending on how you look at it). Generally, once a plugin is running, you should go back to the Dashboard and then drill down to the plugin log file to see the latest log entries. Or better yet, download the log and view in a text viewer.

2. As far as what you are trying to accomplish, it seems to me you are trying to get the Schlage plugin to do something it is not designed to do. The plugin uses a third-party API that accesses the same cloud-based service as the Schlage app. Accordingly, the capabilities of the plugin are limited to what is possible/implemented through the third-party API. Most notably, there is no "push" functionality for state in the API - it requires periodic polling for state update. And, as you noted, some items like messages don't update every poll interval and require the plugin to force an update in the API. So using this plugin to trigger realtime events is just not contemplated in the design. What the plugin is good at is locking and unlocking the locks, because those commands are executed substantially immediately. Now, there is an "official" Schlage API and it does have push functionality for state. But that API requires subscription by the HA vendor (UD in this case) and associated fees be paid, and while we tried to get them to grant us access to the official API, they were unwilling to do so, presumably because the number of users involved didn't meet their standards.

   On the other hand, the EVL-DSC plugin does have realtime status updates. So one thing to look at would be triggering your programming on disarm of a partition at an alarm keypad, and based on the user code used to disarm, unlock the deadbolt. Of course, that would require external alarm keypads.

   Also, I believe there are ZWave and Matter deadbolts that operate locally with realtime status updates. They may be more suited for your purpose.

Edited Sunday at 11:16 PM1 day by Goose66

Thanks, @Goose66 I'm completely down with your thoughts and that's why I'm trying to engineer the timing to get this done. Clearly, it's a first world problem to automate unlocking deadbolt as signal to disarm security a few seconds later. However, I'm not sure where to see log updates from the plugin other than the one place and I can't find mention of any of the fields being updated in that log like say the weatherflow NS that generates a ton of them.

Okay a little more thought on it and I think I'm closer...

I'm using lock status, last message, last message time, and last access code used. When the short poll or force update is executed, what order (or is it an atomic transaction and all the fields are being updated and then committed at once like database multi record update atomic transactions) are the fields updated from node server to the eISY environment? Theory is that last update time is being "sent" to eISY first and it triggers program. It then is seeing older data from other fields as those fields have not yet been "sent" from node server. For this to be a credible theory, it would mean there is a bit of a time gap between fields being sent to eISY if the change is not atomic as I suspect.

Make any sense?

1. Make sure the logging is set to debug level to get full logging of communications between the plugin and the pyschlage API. As far as state updates from the plugin to ISY, these should be logged in both debug and info logging levels. If they’re not showing up, it’s likely a PG3 thing and not a plugin thing. Open a ticket with UD.

2. The state updates are individual and not “atomic.” Because of the threading implemented in PG3 and the nature of the RESTful interface between PG3 and ISY, the order of the state updates may further be non-deterministic.

   I’m not 100% sure how or when you are forcing updates with the UPDATE command, but you could consider having two programs: a first that is enabled and triggers on last message time (guaranteed to change) that would wait for 1 or 2 seconds and then run the if branch of the second program (disabled), which checks the last message and last access code used and unlocks the lock accordingly

Also, because of the nature of the unauthorized API usage, if you poll too frequently, you could cause your ip address (or even the entire pyschlage access) to be locked out.

Thanks @Goose66 The queueing information is very helpful and confirms what I came to understand but I wasn’t thinking that way in original post.

I’ve got test programs in the multi step method like you mentioned and some kinda like ones I posted above. I’ll keep at it and will post final results including limitations. Others may find it useful to automate other things based on the locks The encode plus locks are great and I really like using iPhone and Apple Watch to contactless unlock them especially after a run.

I am now going to create programs to lock any door that is showing as unlocked when security is armed

Thanks again for the node server and advice

Paul

Edited yesterday at 12:27 AM1 day by hart2hart

4 minutes ago, Goose66 said:

Also, because of the nature of the unauthorized API usage, if you poll too frequently, you could cause your ip address (or even the entire pyschlage access) to be locked out.

I followed your thought and short poll is set at 10. Is that still reasonable?

@Goose66 , thanks for your insights. I believe I have success again. The issues were:

1. I was completely overthinking LOL

2. I, for some reason, was thinking of fields coming over from plug-in as multiple fields like an atomic database transaction when they are clearly coming over serially and can't fully tell order they will be posted to eISY.

Solution was to remove all the other fields as trigger part of IF. The fields last message and last unlock user are all that are needed. They function as a IF Status so they only trigger when that field changes. I'll test more but looking great now.

Once I'm a little surer of solution as a way to use the cloud polling with associated timing issues, I'll create another thread with the core programs and description for others to provide feedback and potentially use and refine.

Again, thank you, @Goose66 .

EDIT: AS I recall, all programs are effectively disabled in early part of restart/reboot to prevent a fire storm of program activations. Is this right and does it include during plug in initialization?

Paul

Edited 36 minutes ago36 min by hart2hart