Goose66

Also, PG3x hosts “plugins.” They are no longer called “node servers.” And they were NEVER CALLED “NODES.” A node is an element in the node tree in IoX/ISY/Admin Console that represents a device. There are nodes representing Insteon and Zwave (and now Matter) devices in the node tree created and managed natively by IoX. A plugin interfaces with other devices and creates nodes in IoX to allow the devices to be controlled and statuses to be obtained. /rant 🤪

Those are indeed the zone timers (“Timed Closed”) status reports. Don’t know why they aren’t properly named in IoX log. If you’re not using the timers then just turn them off. It will not affect any other functionality.

I am assuming that the DSC-EnvisaLink events you are referring to as overwhelming your IoX log file are the Zone Timer values. As is shown in the plugin Release Notes available here: https://goose66.github.io/nsdocs/evldsc-pg3.html, the "zone timer values ('Time Closed') represent the time since the last closing of the zone, in seconds, and are calculated in 5 second intervals." While the plugin can't control if or how often IoX logs the zone timer value updates, you can change the frequency at which updates are sent by the plugin using the "zonetimerdumpflag" Custom Configuration Parameter. Again, from the Release Notes: If you add/change this Custom Configuration Parameter while the plugin is running, the change should take place immediately.

I put in a ticket and UD confirmed it was a bug. They asked me to make an adjustment in a file to debug, but I haven't done it yet. I will try and get back to them today. But there is an easy workaround (IP address) so I imagine they will just wait to the next point release to address it. My point in this post is, even if they fix mDNS in the Polisy/eisy, will UD Mobile no longer allow us to use hostnames in the connection, i.e., is the user interface (in conjunction with Apple Transport Security, evidently) limiting the value here to IP Address. I will note that the name of the field is, in fact, "IP Address." Don't know if it's always been that but in hindsight it's pretty clear that's what UD Mobile user interface wants in this field (albeit with an "http://" in front of it).

So IP address only? Polisy.local worked for years.

@guyhamelin However, I am pretty sure you can install the plugin again in another slot and just set it up for your second panel. It shouldn't charge you again since you already have a license. It won't make any difference on the IoX side, and only a minor resource hit on the PG3x side in running two plugins.

The plugin only supports one panel node via a single EnvisaLink. Perhaps in a next version.

There is a plugin for Nest thermostats, but you have to create your own developer sandbox and Device Access project at Google to use it. It’s free and in the Non-production store. A production version of the plugin was finished but not rolled out because using it with more than a couple of users requires a complex verification process (including security audits) with associated costs that are just not worth the effort. Also, it was cloud based and Matter support should be local - much better solution.

My Polisy upgraded fine except for it stopped responding to polisy.local. But everything else went smoothly. PG3x and all the plugins seem to work fine as well.

The Local Connection Settings for my Polisy in UD Mobile was set to "http://polisy.local" and worked fine for literally years. After the 5.9.1 upgrade the Polisy is no longer responding to "polisy.local" so I substituted "http://polisy.lan" for the hostname in Local Connection settings. ".lan" is the default DNS extension on my local network and all devices that have a hostname respond to <devicename>.lan whether they have mDNS capability or not. However, with "http://polisy.lan," it says "ERROR: Could not finish Synchronization. The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." But if you try and set the hostname to "https://polisy.lan," it says "URL must be fully qualified starting with http:// for local connection (not https)." Simply using "http://<ip address>" works, but requires fixed or assigned IP addresses (like we are all college geeks running Ethernet between our dorm rooms in the 80s). Is this the intended functionality or do I have something set incorrectly?

I will log it. I know getting mDNS to work in the first place came in fits and starts. Could just be a missed configuration setting in the updated package. Also could be something that works fine on eisy but not on Polisy. I will upgrade my eisy next.

Yes, it appears that the updated Polisy (5.9.1) will no longer respond on the network to "polisy.local", but my non-updated Test-Polisy (5.8.4) still responds to "test-polisy.local". Are you saying they know about this problem? EDIT: non-updated eisy still responds to "eisy.local".

@Guy Lavoie Do you have your local connection set to an IP address or hostname, e.g., "polisy.local?"

Updated and IoX (via Admin Console) and PG3 all appear to be working correctly. However, now UD Mobile cannot connect to the controller. Just says "Attempting Connection" in the header, and if I attempt to manually synchronize I get a "Error: Could not finish Synchronization. The request timed out." error. Tried shutting down and restarting UD Mobile on my iPhone.

May be a memory corruption problem in the offending T7900. Maybe a factory reset and reconfiguration?

Both thermostats are T7900s, and one's working and one is not, correct? Are they showing the same firmware? Can you rollback the T7900 with the problem to a previous firmware version?

The problem is with the API on your stat. But according to hart2hart it’s working on other stats, so we can’t just patch it. You may want to see if there is a firmware update available for your stat that you could try.

@xgfreon Do you have the Venstar Skyport app? What does it say about humidifier active and dehumidifier setpoint?

The only thing the plugin does is set the Humidifier Active (GV2) driver from the "hum_active" variable in the query response from the Venstar API: self.setDriver("GV2", int(thermoState.get("hum_active", 0))) That's the sole line of code that touches the GV2 driver. If no "hum_active" is present in the API response, the GV2 value defaults to 0. The GV2 driver is defined in the profile as a Boolean (0-false, 1-true). Here's the API documentation description of the "hum_active" value: hum_active Humidifier active 0: Off 1: On The only way a value of 99 could show up here is if 1) something in the Venstar API is broken, or 2) something in IoX or the ISY Node Server API is broken. I'm betting it's the former.

Uh, yeah. Sorry about that. The event was originally supposed to be alarm restoral (thus the name), but the disarm was really the only way to accomplish that. The new Partition Disarmed event is specifically for disarming events. To differentiate the two, we now only send the Alarm Restoral event if the panel was in alarming state when the user code was typed in to disarm. But I can see that breaking changes like this are annoying.

In this version, Alarm Restored is only triggered when the panel is disarmed while in the alarming state. Partition Disarmed occurs anytime a partition is disarmed.

In fact that’s now the only supported installation. PG3x and plugins, such as EnvisaLink-DSC, only run right there on the eISY. And in the case of the EnvisaLink-DSC plugin, it’s communication to the EnvisaLink in the DSC panel is all local too.

This was fixed in v3.1.9. You can put a longer password in but it will work for EVL4 only.

The release notes and instructions for the plugin were also migrated to HTML format and made available through my GitHub.io site here: https://goose66.github.io/nsdocs/evldsc-pg3.html The link(s) to the MD version of the release notes in older posts will no longer work.

A new version of the plugin v3.1.9 has been uploaded to the Production Plugin Store. This version adds/fixes the following: GPV state (driver) added to Panel node to track the plugin's status, "Ready - Forced Arming Enabled" message from a partition now handled the same as "Ready" messages, Partition nodes send "Partition Arm" (DON3) and "Partition Disarm" (DOF3) commands for partition arm and disarm, respectively, the maximum length of the password was increased 10 characters (works on EVL4 only), and descriptive names were added to the driver list in the PG3 Dashboard.