Goose66

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"

It was my understanding that turning ON a Program setup in the Alexa integration runs the "Then" branch and turning OFF the Program runs the "Else" branch (see, e.g., https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#Programs). The "trigger" (really a condition) is not considered. But if that's not the case, then try a condition that is always true, e.g. "If From 0:00:00 to 23:59:59" and then disable the program so that the ISY won't trigger the program on the condition's boundaries. Alexa should be able to Turn that ON (run the Then branch).

You say you don’t have a “logical trigger” to start the program. But there must be at least one controller device for the scene, right. Otherwise, what triggers the scene? Or if you are just manually triggering the scene from the Admin Console or UD Mobile, then you could similarly just run the program from the Admin Console or UD Mobile (Run Then Branch).

I can add that to the to-do list. However, I do not have this alarm panel any more so I will have to release a version with this feature untested. The next time we find a bug or something that needs to be fixed, I will add this feature.

I see no Bond trial option - just the purchase option. The submission was from a long time ago so it would have been something that was there, and is now gone. But more specifically, he is saying he selected Bond trial and got MyQ trial. When the Bond PG3 node server was initially released there was a trial and a purchase option. I can’t say for sure that I kept the trial option over subsequent releases, however. It is certainly possible that the OP thought he was installing a trial of Bond when he was really installing a trial of MyQ. But if that’s the case it’s mighty coincidental that such a mistake was made between two node servers from the same developer.

I don't see a Bond node server Trial option in the Node Server Store either. I see that when I first released the PG3 version of the node server I noted there was a 1-month free trial. And IIRC when I uploaded the latest version to the Node Server store, I uploaded it for both the Trial and the Purchase options. As far as the missing Trial option for the Bond node server and you getting the MyQ node server trial when you selected the Bond node server trial, those sound like database corruption problems in the Node Server Store to me, which we node server developers have no control over. That is a @bpwwer issue/question.

2. The "Thermostat Online" state basically reports the success or failure of the last polling call (updated every short poll).

1. The Venstar node server does not maintain a connection* to the thermostat where it can get real-time status updates. Instead it relies on polling to retrieve the latest status every short poll interval. However, unlike the MyQ or iAquaLink node servers, the poling takes place on your LAN directly to the thermostat and doesn't utilize a cloud service as a go-between. Accordingly, the polling call is not very expensive network-wise, and can be done frequently (defaults to 15 seconds). Therefore, there is no need for a "Force Update" command. If the 15 seconds is not real-time enough, you can set the short poll interval to 10 seconds or less. Note that the node server also updates the remote sensor states, the system runtimes, and the alert states every long poll interval. * technically it does maintain an HTTP session so that subsequent calls to the thermostat after the initial call are more efficient. But there is no two-way connection allowing the thermostat to update the node server with current status values in real-time, like the EnvisaLink-DSC or Bond node server.

3. If the EnvisaLink is not firewalled and can connect to the EyezOn web service, then you don’t need the “disablewatchdog” setting. This is also documented in the node server "More Info."

2. The “Alarm Panel Connected" reflects the status of the connection between the node server and the the EnvisaLink device. It is really only updated to True when the node server logs into to the EnvisaLink device and to false when the node server disconnects or attempts to send a command to the device and it fails. It’s not updated in real-time. The node server does have a heartbeat functionality, however. It sends an AWAKE command to the ISY on a periodic basis based on a periodic communication received from the alarm panel. The heartbeat functionality is documented in the node server "More Info."

1. Some background: If you “Query” a node from the Admin console, the node server will generally just respond with all of the current status values for the node. The node server doesn’t necessarily query the device for the latest values unless the node server programmer specifically overrides that functionality and adds the device query. The EnvisaLink DSC node server uses the default query approach. Further, the EnvisaLink-DSC node server generally doesn’t poll but instead listens for status update commands from the EnvisaLink device. Other than initial startup functionality, the only thing that the node server does on the short poll interval is update the zone timer values. What the Force Update command does is cause the node server send a command to the EnvisaLink device to resend all its status reporting commands with current status values, similar to what happens on startup. The node server then processes the commands as received. After a Force Update command it may take several seconds for the EnvisaLink to send all the status reporting commands and for the node server to update the ISY.

<rant> A “node” is an individual item (“leaf”) in the tree structure in the left panel of the ISY Admin Console. Nodes have states (“driver values”) and send and/accept commands. Each node usually represents a device, but a node may represent a group of devices, a gateway or hub, a connection to a cloud service, or even a node server instance. The thing you install, upgrade, and configure in PG3 is a “node server.” A node server creates and supports nodes in the ISY. Every node in the ISY that’s not native (Insteon, Zigbee, Zwave) has an associated node server managing the corresponding device. </rant> Thank you for your time.

I have looked at the API available for Schlage Encode lock and feel like it will be possible to build a node server for it. I started it about 3 months ago but, as I said, it fell off the radar. What I can't tell you is 1) will it definitely support Encode Plus (e.g., since it's homekit compatible may it be purposefully limited in what other APIs it supports) or 2) how long will it last (e.g., they could change or withdraw the API). Overall, many of my home automation projects have been pushed to the back burner since I moved last August and have since been waiting to see how Matter shakes out before diving in at my new townhome. I've also been working remotely at my vacation home a lot. I return from an extended absence in the second week of June and will try and look at it then.

From what I can tell, the API that the node server would us should work for any of these Schlage locks that use the mobile app and connect over Wi-Fi.

I installed a Schlage Encode Wi-Fi lock some months back and played with the API a little in preparation for developing a node server, but it just fell of the to-do list. Hopefully can circle back to it in a couple of weeks.

Looks to me like the ISY has lost connection to the node server and/or PG3. Did you just update your Admin Console (firmware)?