Goose66

@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.

While @Guy Lavoie post covers this, to be more direct, the Zmatter dongle is more like a PLM for Thread-over-Zigbee devices. Beyond Thread devices via the ZMatter dongle, Matter support in IoX should include other Matter devices, both directly via WiFi and through other hubs, such as Alexa devices (I hope). So you shouldn’t have to have the ZMatter dongle to integrate with any Matter devices, just Thread devices (when you don’t have some other hub).

Looking at equal but native from the opposite angle, I would hope (although I have no reason to believe) that Matter integration would be done using an API layer that would be the same as the eventual API for plugins after the removal of the Node Server API and PG3 from mix. In an ideal world, everything would be a plugin and Insteon, Zwave, Matter, and plugin nodes could all be equally supported. The difference would be Insteon, Zwave, and Matter plugins would be provided by UD (and probably be much more sophisticated and stable). Looking forward to IoX 6.x!

Changes are listed in the updated release notes here: https://goose66.github.io/nsdocs/evldsc-pg3.html “Partition armed” event refers to any arming. If you want to know how it was armed, you would have to check the state. But you would want to incorporate a delay to make sure that IoX had processed the state change which may or may not arrive before the “Partition armed” event.

Short answer, yes. Long answer is that I have always been of the opinion that the ISY and whole UD ecosystem was designed around Insteon/X10 at its core, including the programming model that allows for separate and distinct conditions for state changes and events (commands) (along with schedule, etc.), and I have always tried to design plugins that present nodes that fit within this paradigm. I also try and mirror the devices’ native paradigm - what does the DSC keypads (or the EnvisaLink API) reflect as state vs. what events happen or are raised. In this specific case, I’ve also tried to maintain some consistency with the EnvisaLink Honeywell/Vista plugin, which i wrote from the same base code.

@apostolakisl A new version (v3.1.9) of the plugin is in the Non-Production (Beta) store for testing. I know you know this, but when we have tested and move it to production, your programs with have to be adjusted.

Alarm Triggered means an alarm was triggered for the partition, i.e., the partition moved to an “alarming” state. Alarm Restored means (or at least is supposed to mean) that the partition was in an “alarming” state and the alarm has been turned off (presumably by disarming the partition). These events (commands) are sent so that the partition node can be dropped into a scene as a controller to, e.g., turn on all exterior lights when the alarm is triggered, etc. The Partition Armed and Partition Disarmed events (commands), once implemented, should satisfy your needs without needing any complicated state logic or trickery with Else clauses (which anybody who’s been around here for the past 12 years knows I think are basically worthless in the current programming paradigm). So, for example, two programs, one with “If 'DSC PG3 / Keypad MDPA' is switched Partition Armed” and the second with “If 'DSC PG3 / Keypad MDPA' is switched Partition Disarmed.” It’s also self-documenting.

Yes, two programs. And we will need another event (command) for arming. By having them in two separate programs, you won't need the complimentary "not" statement for events (commands) in your if statements. Currently the events (commands) sent to the Partition node are Alarm Triggered (DON) and Alarm Restored (DOF). This was done to make programming for responding to these events easier as well as the Partition node to be dropped into a scene as a controller. However, the way it appears to be coded right now, the Alarm Restored event (command) will be sent whenever the partition is disarmed, regardless of whether the partition was alarming or not. I suggest changing the code to send the following events (commands) for the Partition node: Alarm Triggered (DON) - the Alarm has been triggered Alarm Restored (DOF) - when the panel is alarming and is subsequently disarmed (thus cancelling the alarm) Partition Armed (DON3) - when the Partition is armed Partition Disarmed (DOF3) - when the Partition is disarmed That should have you covered without changing anything for existing users.

Looking through the history I don't ever see that there was a version 1.0.5. It jumped from 0.2.5 in Non-Production to 1.0.6 in Production (the latest being 1.0.7). If I recall correctly, the latest version 1.0.7 still supports the use of a personal Google Device Access Project. If everyone is amenable, I can upload v1.0.7 to Non-Production.

Also, it appears the partition node is already receiving an event (command) when the partition is disarmed, but it is currently labeled "Alarm Restored." Instead of the complex code you posted for determining disarmed, try: If 'DSC PG3 / Keypad MDPA' is switched Alarm Restored Then <Partition has been disarmed> The name of this command can be changed from "Alarm Restored" to something like "Partition Disarmed" when we make the other change(s) if this works.

Took a look at your log and sure enough it's a bug. Your EnvisaLink sends a "Partition Not Ready" for partition 1 but then follows up 3 seconds later with a "Partition Ready – Force Arming Enabled." The description of this command is the same as "Partition Ready," but I am guessing it has something to do with all the open zones that are configured as "non alarm zones." Paradoxically, the current code actually checks for the "Partition Ready – Force Arming Enabled" command and handles it the same as a "Partition Ready" command, but for what ever reason, the "Partition Ready – Force Arming Enabled" command doesn't make it to the state handler for the partition node and is instead marked by the API as an "Unhandled" command. It's a simple fix. However, it's been almost 3 years since I touched this code and a lot in the environment has changed. I'm not sure if I need to bring this one up to new standards or just make this one change and push it out. Bringing it up to new standards would mean less likely that it would be blown up by some new PG3/IoX release. I could also implement some other todos, such as upping the password to 10 characters, adding names to the state (driver) values, adding additional events (commands) for "Partition Armed" and "Partition Disarmed", adding disarm with custom user code, etc. But the problem with doing all this is I have no way of testing it because I don't have a DSC panel anymore. I would need to get a VPN setup to somebody with a DSC panel and EnvisaLink to test/debug changes. Just implementing the "Partition Ready – Force Arming Enabled" command handling would be easy (one line changed) and would (hopefully!!!) not introduce any bugs so I could just push it out. What do you think?

As to NodeLink "reading" the number of zones and partitions configured, this is not a feature of the TPI (API) presented by the EnvisaLink, so don't know how it was doing that. Similarly, a status of "Disarm" vs. "Ready/Not Ready" is simply a difference in the way the EnvisaLink-DSC plugin is designed vs. NodeLink. The EnvisaLink sends a "partition disarmed" command but that's generally immediately followed by a "partition ready" or "partition not-ready" command. Perhaps NodeLink handled these states separately. The Plugin does send a heartbeat every few minutes. From the document linked above: Don't know about "non-Alarm Zones" - never experienced or tested that. Perhaps you should try specifically bypassing these. I will try and take a look at the log files tonight to figure out why the partition never goes to "Ready".

First, a caveat: I no longer have a DSC alarm panel with an EnvisaLink so I have no way to test changes or updates to this plugin anymore. That said, the installation/configuration instructions for the plugin are here: https://goose66.github.io/nsdocs/evldsc-pg3.md Answers to many of these questions may be found there. Spcifically: 1. The EnvisaLink does not provide a way to retrieve the panel configuration. You must configure the number of zones and partitions in the Custom Configuration Parameters, if different from the defaults. You must set the number of zones to include the zone number of the keypad connected zone, even if there are not intervening zones. 2. The command outputs came be configured on your panel to be in toggle mode or on/off mode, depending on your panel series. Unfortunately, as I mentioned above, there is no way to retrieve the configuration from the panel. So the plugin only support command outputs came activation, which toggles the command output on and then off based on the configuration of the panel. Once activated, the EnvisaLink will never clear the active status, so if always says active. 3. For partition state and zone statuses, this all worked several years ago, when I was using it, so I can’t really provide any insight on what may be happening without seeing any logs. But I will say it may just work differently from NodeLink, so if you can recreate a set of conditions and generate a log file in “Debug” mode, I can tell you if it is working as designed or not. 4. If the partition state never returns to ready when disarmed, this may be why the last disarming user is not set.

I believe the point of calling these features out is that they specifically don’t need the ZMatter dongle. The ZMatter dongle will allow the eisy to communicate directly with Thread-based devices. But Matter is supported on other networks besides Thread, such as Wi-fi. Thus Wi-Fi direct to Matter devices (what I’m waiting for) and wi-fi through hub/bridge to Thread devices can all be implemented in eisy by software update alone, requiring no Thread hardware (ZMatter dongle).

This is still on the to-do list, but the steps were daunting (and potentially expensive) and I had other lower-hanging fruit to go for. If anyone wants to use in the meantime, I encourage you to setup your own Google Developer account and Google Device Access project to use. The instructions in the plugin release notes are detailed and refined.

It’s deja vu all over again! 🤪

You should be able to wire the ratgdo to use the discreet open and close terminals on the gate controller. There is a diagram on the ratgdo wiring page here: https://paulwieland.github.io/ratgdo/03_wiring.html. However, as Guy Lavoie said, monitoring open and close status probably won't work, unless you have the expansion board and use the aux relays or you install separate open and close limit switches (e.g., microswitches or reed switches).

Nodes from plugins should be deleted in the PG3 Dashboard, not from IoX Admin Console. The node list is stored in the PG3 database and most plugins recreate all of the nodes from these database entries when they restart. If you delete a node from the IoX Admin Console, it will just get recreated when you restart the plugin. Deleting it from PG3 deletes it from IoX as well. This is a known limitation in the PG3 system. Once PG3 is absorbed into IoX (v6?), this should be cleaned up.