Current/Future Functionality

[Goose66]

This topic was create to discuss current and future functionality of the Schlage Node Server in order to pull some conversations from elsewhere on the forum into this space.

[hart2hart]

Thanks again, @Goose66 . I would like to see the user name or number available when the lock is unlocked and/or locked. I would use it to disarm the security system.

[Goose66]

9 minutes ago, hart2hart said:

Thanks again, @Goose66 . I would like to see the user name or number available when the lock is unlocked and/or locked. I would use it to disarm the security system.

The challenge with the last user functionality is that the library I am using, and I believe, in fact, the non-public API that library is accessing, provides log entries with a GUID (which is a very long string of hexadecimal characters) and a name (a text string) to identify the user. It also provides a timestamp for the log entry. None of these (GUID, text string name, timestamp) are values that are supported by UD's Node Server API. It only supports integers and floating point values.

In some other node servers, such as the Envisalink-DSC node server, the device (DSC Panel) provides an integer index, e.g. "02" for the last user or disarm/unlock code. That integer index can be passed to IoX as a status value for the node labeled, e.g., "Last user code" and then it's just up to the IoX administrator/programmer to know who or what that index means based on the configuration of the device itself. In the case of the Schlage locks, however, neither the GUID or the name text string can be passed to identify the last user. There are some workarounds (hacks, if you will) but these require a lot of coding and dynamic modification and frequent reloading of the "Profile," which is not an attractive option.

Similarly the timestamp value is tricky to deal with. In the case of MyQ, I take the timestamp of the last action on a garage door opener and turn it into an (integer) duration in seconds since the last action. This works but generates a lot of "chatter" in the communication between the node server and IoX, which is not really desirable.

It may take some time to come up with a viable strategy and implement it, unfortunately, but it is certainly on the roadmap.

 

Edited July 15, 2023 by Goose66

[Goose66]

In regard to comments about polling intervals and updates: there are no pushed state updates from Schlage available here - it is 100% polling. Like in MyQ and iAquaLink node server, the concern is that frequent polling using a non-public API may alert Schlage of the the use and they may make moves to cut it off. So the Schlage node server uses the same strategy as those other node servers to have active polling (short poll interval) for around five minutes when any activity is detected, and otherwise have non-active polling (long poll interval) for the periods between detected activity.

Unfortunately, in the case of wanting to turn on lights or disarm alarm systems when the door is unlocked, this may not work well unless the long poll interval is set to a potentially unacceptable short duration. Setting the long poll interval to a short duration could result, however, in constant frequent polling of the Schlage cloud service, which may create other problems (such as Schlage locking us and/or the pyschlage library out).

The "Force Update" is also implemented to deal with this sort of thing. Sending the "Force Update" not only results in an immediate status update request sent to Schlage (with all state values being returned to IoX regardless of change), but it puts the node server into active polling mode. So, for example, if you had a program that sensed motion in your driveway or activity at your front door, e.g., via a motion sensor or ring camera, you could have that program do a Force Update to the appropriate Schlage lock(s) putting them in active polling mode. Then, coupled with a frequent yet hopefully acceptable short polling interval of, say, 5 or 10 seconds, you could detect unlocking by a user and then disarm alarms and turn on lights in a relatively timely fashion.

We will have to wait and see how the pyschlage library usage unfolds over the coming months to see what's possible here.

Edited July 15, 2023 by Goose66

[hart2hart]

The challenge with the last user functionality is that the library I am using, and I believe, in fact, the non-public API that library is accessing, provides log entries with a GUID (which is a very long string of hexadecimal characters) and a name (a text string) to identify the user. It also provides a timestamp for the log entry. None of these (GUID, text string name, timestamp) are values that are supported by UD's Node Server API. It only supports integers and floating point values.
In some other node servers, such as the Envisalink-DSC node server, the device (DSC Panel) provides an integer index, e.g. "02" for the last user or disarm/unlock code. That integer index can be passed to IoX as a status value for the node labeled, e.g., "Last user code" and then it's just up to the IoX administrator/programmer to know who or what that index means based on the configuration of the device itself. In the case of the Schlage locks, however, neither the GUID or the name text string can be passed to identify the last user. There are some workarounds (hacks, if you will) but these require a lot of coding and dynamic modification and frequent reloading of the "Profile," which is not an attractive option.
Similarly the timestamp value is tricky to deal with. In the case of MyQ, I take the timestamp of the last action on a garage door opener and turn it into an (integer) duration in seconds since the last action. This works but generates a lot of "chatter" in the communication between the node server and IoX, which is not really desirable.
It may take some time to come up with a viable strategy and implement it, unfortunately, but it is certainly on the roadmap.
 

Thanks for the explanation.

Is there anything we as users of the NS could do to make it easier? Pure spitballing here but could we “see” the GUID Name string in the NS log and then create a custom parameter to map it to an integer “user number”?

[hart2hart]

In regard to comments about polling intervals and updates: there are no pushed state updates from Schlage available here - it is 100% polling. Like in MyQ and iAquaLink node server, the concern is that frequent polling using a non-public API may alert Schlage of the the use and they may make moves to cut it off. So the Schlage node server uses the same strategy as those other node servers to have active polling (short poll interval) for around five minutes when any activity is detected, and otherwise have non-active polling (long poll interval) for the periods between detected activity.
Unfortunately, in the case of wanting to turn on lights or disarm alarm systems when the door is unlocked, this may not work well unless the long poll interval is set to a potentially unacceptable short duration. Setting the long poll interval to a short duration could result, however, in constant frequent polling of the Schlage cloud service, which may create other problems (such as Schlage locking us and/or the pyschlage library out).
The "Force Update" is also implemented to deal with this sort of thing. Sending the "Force Update" not only results in an immediate status update request sent to Schlage (with all state values being returned to IoX regardless of change), but it puts the node server into active polling mode. So, for example, if you had a program that sensed motion in your driveway or activity at your front door, e.g., via a motion sensor or ring camera, you could have that program do a Force Update to the appropriate Schlage lock(s) putting them in active polling mode. Then, coupled with a frequent yet hopefully acceptable short polling interval of, say, 5 or 10 seconds, you could detect unlocking by a user and then disarm alarms and turn on lights in a relatively timely fashion.
We will have to wait and see how the pyschlage library usage unfolds over the coming months to see what's possible here.

Thanks. Based on description, it felt like it was pure polling.

I do have a Ring camera (mapped to the Ring NS) in the garage that I could use to detect motion and then Force Update just before lock entry so I’ll keep that in mind as future unfolds.

[Goose66]

Just now, hart2hart said:

Thanks for the explanation.

Is there anything we as users of the NS could do to make it easier? Pure spitballing here but could we “see” the GUID in the NS log and then create a custom parameter to map it to a integer “user number”?

That is one possible solution. Or map names to indexes in custom parameters. Another solution is for the node server to somewhat arbitrarily but reproducibly map the names to index numbers (e.g., a short integer hash) and then the IoX user/administrator/programmer would just have to learn the index number through observation. Or the node server could generate these indexes into profile entries and update the profile for the node server, and then send a notification for the user to reboot IoX. These are all possibilities.

The UD folks have functionality on their roadmap that could make this easier. It would allow the node server to send the state value of the last user with both an (arbitrarily assigned) index values as well as the user name from Schlage. Both would be displayed in the Admin Console. From that, the IoX user could learn what index values went with what user names, and setup programs accordingly. I think this functionality is coming in the near term, but I don't have a date yet.