Goose66

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.

@MrBill and @hart2hart Guys, let's move the discussion to the forum below in order to make the info more accessible:

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.

I don't know what to tell you. It's been there for a while for me: Perhaps @bmercier will come up with something this evening. Sorry for the issues.

@bmercier Uh, oh. Now it's there twice. I won't fool with it anymore.

Ok, it's there again. Let's see if it sticks this time. 😬

Got it. Thanks. Truth is, I wanted to tag @bpwwer, but for some reason I can never remember his handle. I try "bpau..." and "pb..." and "bob..." but can never get it to come up. 🙂

Ok, now it's gone for in me in just the last two minutes. @GeddyWhat's up?

Hmmm, I show 117. @Geddy Is there some reason a newly submitted Node Server would not be showing up in other's Node Server Store? Also, @MrBill are you on Polisy or eISY (PG3 or PG3x)?

Try refreshing your store. I just checked again after being away for a couple of hours and I still see it in the store.

I have released an initial version of the Schlage node server. See here: Right now just locks with lock and unlock. The one thing I can see adding in the next version is last action from the log (time, action, and MAYBE user number or name).

I have released an initial version of the Schlage node server for PG3 (v3.0.1 - the v3.x.x convention kept for PG3 node server conversions). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/schlage-pg3.md. There is a 1-month trial period and then the node server is $10.95 for perpetual license. Unfortunately, after installing a FW update, my Schlage Encode lock will not lock or unlock, either through the node server, app, or keypad. It just jams. A lesson in "if it ain't broke..." Anyway, please test locking and unlocking from the node server and let me know if there are any issues. Also, this node server uses a third-party library pyschlage that itself has a lot of dependencies. With several disparate versions of PG3 and PG3x floating around on two different platforms (Polisy and eISY), there may be some installation issues, so let me know what problems you have.

You say you tried it in Chrome, do you mean you typed it into address bar and it worked? If so, then change your HTTP command here to GET.

I usually code node servers for retrieving and updating state, and leave configuration (properties) changes to the native app. What's a use case for managing access codes (specifically if it turns out that you can just see them in a list and delete them) from the ISY vs. just using the Schlage app?

@MrBill sorry I misread your posts above regarding the capabilities (or lack thereof) of this API. Let me look into the code and license model.

The API options I have looked at are Yonomi and Seam. Both of these companies are IoT platform companies offering a single (web-based, unfortunately) API across a variety of devices. Yonomi is owned by Schlage or the same company as Schlage, and as an IoT platform supports Schlage, Honeywell, Ecobee, Philips Hue, Resideo, Kasa, Sonos, and more. Seam has an even longer list of supported devices and manufacturers. Both of these companies also offer "developer" accounts that allow limited access and/or limited device counts. I guess it would be possible to develop a node server that integrated with a developer account, and then require each person to establish a developer account at the company in order to utilize the node server. I believe that is how the Honeywell Thermostat node server works today. But I have to admit that being web-based and all the rigamarole is a bit de-incentivizing to making a good node server. The other possibility would be to try and establish a paid account with one of these platforms (they both allow multiple user accounts to segment devices), but I doubt the node server sales income would cover the costs. I'll keep looking and let you know what more I find out. BTW, this is exactly the sort of BS I am hoping Matter eliminates.

It's also possible this is a PG3x thing and not a PG3 thing, so that may narrow down where to look.

@bpwwer, AFAIK from the two attached node server log files, both node servers are running along swimmingly, and then udi_interface logs this message: 2023-06-21 13:05:54,611 MQTT udi_interface.interface INFO interface:_disconnect: MQTT Unexpected disconnection. Trying reconnect. rc: 16 About 10 seconds later, the udi_interface throws this error: 023-06-21 13:06:09,269 MQTT udi_interface.interface ERROR interface:_disconnect: MQTT Connection error: An exception of type timeout occured. Arguments: ('_ssl.c:1117: The handshake operation timed out',) Traceback (most recent call last): File "/var/polyglot/pg3/ns/0021b90261c8_1/.local/lib/python3.9/site-packages/udi_interface/interface.py", line 460, in _disconnect self._mqttc.reconnect() File "/var/polyglot/pg3/ns/0021b90261c8_1/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1073, in reconnect sock.do_handshake() File "/usr/local/lib/python3.9/ssl.py", line 1310, in do_handshake self._sslobj.do_handshake() socket.timeout: _ssl.c:1117: The handshake operation timed out It then appears that the node server is "restarted," or at least all of the initialization routines are performed again. Another 10 seconds, the udi_interface throws the same "handshake operation timed out." The node server continues to run and attempt to update the node driver values (it's initializing) but gets dozens of warnings and errors like these: 2023-06-21 13:06:37,775 MainThread udi_interface.interface WARNING interface:send: MQTT Send waiting on connection :: {'config': {'version': '3.0.8'}} 2023-06-21 13:06:40,782 MainThread udi_interface.interface ERROR interface:send: MQTT Send timeout :: {'config': {'version': '3.0.8'}}. That goes on for a few minutes and then the user evidently pulled the plug. These events are almost exactly the same in both node server log files as well as having similar timestamps. Note that my node server (EnvisaLink-DSC) doesn't rely on or have a connection to an Internet service - just a direct connection to the Envisalink device over the local network. It appears to me that it was PG3x (or the MQTT broker) that yacked when the Internet connection went down and the node servers (specifically, udi_interface) were never able to reconnect. Perhaps you can get @GTenchto give you a PG3 log file.

The log file contains the same errors here as in the EnvisaLink-DSC log file you posted earlier. Again, this appears to be a PG3/PG3x issue. I suggest you post a message with the log file(s) in the PG3 or PG3x support forum regarding this issue.

All those errors are from the udi_interface (the PG3/PG3x) side of the node server interface. @bpwwer would be the man to investigate here.

How short? Also, are you talking about Internet outage or local network outage? Do you have a log file where the disconnect happened?

Turns out you would need to make the Bridge discoverable again to discover new devices added to the bridge if the Bridge was originally discovered by the automatic discovery (i.e., not specifically identified by hostname in the "hostname" Custom Configuration Parameter). I consider this a bug (or an oversight) however, and I have marked it for change in the next version. The Zeroconf module allows the node server to broadcast a query to the devices on your network and then listens for responses from compatible devices (in this case Bond bridges and SBB devices). It is the same mechanism as Bonjour that Apple uses to discover Apple devices (printers, phones, macs, etc.) across your network. The error you are getting suggests that some other process on your Polisy (and, specifically another user) has the Zeroconf socket connection open and listening for responses. Since I am unaware of any such native process on the Polisy, I am assuming it's another node server. One of the changes implemented in PG3x is that node servers each now run under their own user ID. So if another node server is utilizing Zeroconf (and holding it open), other node servers will fail to initialize Zeroconf since they are now running under different user IDs. I have noted this bug and will have to do further analysis to figure out a fix. In the meantime, a workaround for you should be putting the hostname and token values for your current bridge in the "hostname" and "token" Custom Configuration Parameters for the node server (see the instructions under the "Configuration" tab in the PG3 Dashboard). This should cause the node server to skip the automatic discovery of new bridges through Zeroconf and just look for new devices on the bridge(s) you specify in the Custom Configuration Parameters. Note that, based on the "bug" discussed in the first paragraph of this post, if you don't specify the "token" configuration parameter value for your bridge, then the bridge will have to be discoverable (power cycled) for this to work properly. Let me know if you need any additional help with this, and hopefully I can get these bugs fixed and get a new version out soon.

Also, have you tried restarting the node server?

What other node servers do you have installed and have you installed something else that may have a Avahi/Zeroconf listener running?

Looks like some type of error in the Discover code when the connection is already established. Is it possible you press the button multiple times in a row? Please set the logging level to DEBUG and rerun the Discover command - "One [press] only, Vasily"