Goose66

I'm betting the power supplies in your LED lights are causing interference in the PLC communication from the switchlinc. Try a filter between the switch load wire and the lights.

See if your fans have a remote control unit available that can be added, and then buy a Olibra Bond Bridge to control the fans via the remote codes.

Several years ago I installed my first PG1 Node server that loaded a malformed nodesdef.xml that prevented the ISY from starting. Since I didn’t have a recent backup, I pulled the SD card and mounted it Windows. I was able to decipher the file system enough to find the errant profile XML file and remove it, allowing the ISY to start. I think I recall that each program is similarly stored in an XML file in various folders. proceed at own risk — possibly warranty voiding — and all that jazz. BTW, UD quickly fixed the profile load bug in a firmware update. It’s also very possible that subsequent firmware changes have made the underlying file system unreadable/indecipherable.

It's coming...

When doors have been idle for some period, the Node server is in "inactive" polling mode and polls based on the longpoll setting. When a door state change is detected or a command is sent from the ISY, the Node server switches to an "active" polling and polls based on the shortpoll setting. It remains in active polling mode until there have been no more status changes/commands for 3 minutes. This accounts for the behavior you mentioned on closing because of the 10 second or so alarming period before the door starts moving on remote close (see # 6 in the release notes linked in the pinned topic - https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md). This also accounts for the status taking a minute or more to show up when you open the door via the app and the Node server is in inactive (longpoll) mode. However, I have not experienced this type of behavior on an open, in that when I send an open command from the ISY the door begins to move almost immediately (1 or 2 seconds). The purpose of this rather convoluted process is that it is important for the Node server to appear like an instance of the mobile app to the MyQ service. Remember that the MyQ Node server is a hack and not an (officially, at least) approved usage of the MyQ API. If we have a bunch of node servers pinging the MyQ service every 10 seconds 24/7, they will detect this and lock us out!

Maybe create a user code specifically for the ISY/Node server, then at least you could differentiate disarms from the automation system from those done with the master code.

According to API documentation and the current programming, if a partition is armed or disarmed with a user code, then the "Last Arm/Disarm User" state values for the partition is set to the number of the user code. If a partition is armed or disarmed using some other method (by key switch, by button on a keypad, etc.), then the "Last Arm/Disarm User" is set to 0. So when you disarm from the ISY via the Node server, it uses the user code configured in the Custom Configuration Parameters. Accordingly, the number of that user code (40=mater user code) is what will appear in "Last Arm/Disarm User." So I would think that is technically accurate - the master user code configured in the panel was used to disarm the alarm. That said, there maybe could be a way to add a disarm command that took a different user code. It would have to be able to pass an integer between 1 and 999,999 and would result in a dropdown list in the ISY with 1,000,000 selections (which would probably break Java). It would also result in your user code being transmitted across the network in an unencrypted REST request.

The commands that the Node server sends for each node type are here: https://github.com/Goose66/NSDocs/blob/main/evldsc-pg3.md I just updated it to show the values for the "Control" conditions in the ISY. That said, I am open to changing how these work based on how people use them. I toyed with the idea of changing the DON and DOF for the partition to be armed and disarmed. Currently I use the Zone "Opened" and "Closed" commands (in ISY scenes with Insteon devices) and I use partition "Alarm Triggered" and "Alarm Restored" to turn on my floods when an alarm goes off. But the Alarm Panel "Alarm Triggered" and "Alarm Restored" are probably better for this, since the floods would be best used for a fire alarm at night.

@TJF1960 "Status" will only show states (driver values) for the node, e.g., "Partition" state. Setting an if condition on a state will trigger the program whenever the state (driver) value changes, regardless of the value being tested for in the if statement. As I mentioned above, there is no "Disarm" state - it just goes to "Ready" after a few seconds. "Control" will show commands that the node generates that are received by the ISY. If you put a control in the If statement, the program will be triggered only when that command is generated, e.g.: resulting in: If 'Perimeter / Alarm Panel / Partition 1' is switched Alarm Restored Then Set 'Perimeter / House MyQ Gateway / Light Module' Off Else - No Actions - (To add one, press 'Action')

Are you not getting an "Alarm Restored" (DOF) command from the partition when the partition is disarmed? Perhaps this should be renamed, but that's what the Alarm Restored command on the partition is for - it is (should be) sent when the partition is disarmed, either from an alarming state or an armed state. The reason for this command is because the partition remains in an undefined state for a second or two after it is disarmed (so the ISY sees no state change), and then eventually the partition will return to the "Ready" state.

Not to be that guy, but isn't it WAY easier to run an ethernet drop and move your ISY/Polisy to the location of your PLM than it would be to make some special cable and hope that it works (and doesn't void some kind of warranty).

@brians Yes, it had an intermediate folder in the zip file ("evldsc-pg3-3.0.8") in the zip file, as you noted (I uploaded the wrong zip file). I think @bpwwer noticed it and cleaned it up for us. Trophy emoji to Bob!

Fixed. Thanks. Unfortunately, there were some profile changes, specifically for the Alarm Panel node. The node address of the panel was changed from "controller" to "panel" in order to facilitate a future feature of the Node server supporting multiple panels, e.g., panel1, panel2, etc. (mostly implemented). In addition, the driver value used for the alarm panel connected state changed from GV1 to ST. This was due to ST being something different for controller nodes in PG2. Any programs that utilize partitions, zones, or command outputs, however, should continue to work like they always did. EDIT: In hindsight these changes were not really necessary. Before you install, please provide some feedback on these changes because it wouldn't be that hard to change things back. Another question is do I make similar changes in EnvisaLink-Vista to keep them consistent?

I have released the PG3 version of the EnvisaLink-DSC Node server (v3.0.8). The EnvisaLink-DSC Node server provides an interface for the ISY to a DSC PowerSeries™ alarm panel through EnvisaLink™ EVL-3/4 and DUO™ adapters from EyezOn. See http://www.eyezon.com/ for more information on these products. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/evldsc-pg3.md. There is a 1-month trial period and then the Node server is a one-time purchase at $10.95.

I have released the PG3 version of the Bond Node server (v3.0.9). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/bond-pg3.md. There is a 1-month trial period and then the Node server is a one-time purchase at $10.95.

@headviking If you are a DIY and home automation fan, then I suggest looking online to find out how to factory reset your DSC 1616 alarm panel (involves some wiring and grounding of a pin on the control chip), enter a new installer code, and configure the panel from scratch so you know exactly how everything works. If not, then I would suggest contacting an alarm monitoring company and have them take over system configuration and maintenance.

You could instead just alter your program to run every 30 minutes: If 'ZW 016 On-Off Power Switch' Status is On And Time is Last Run Time for 'Reset kWh sump 2' + 30 minutes Then Set 'ZW 016 Energy Meter Sump 2' Reset Else - No Actions - (To add one, press 'Action') Make sure "Run at Startup" is Enabled.

Yes on HW Envisalink. I haven't looked at Autelis Pentair in a long time, and again the issue is I just have no way to test it. When I convert Autelis AquaLink, I will take a look.

I think a DSC panel would be better - yes. But you have to replace all of your keypads as well. Looks like the DUO from Eyezon has the Envisalink functionality plus an LTE modem, so it should work with the nodeservers (HW or DSC).

I believe there is a small number of folks that use the HW EnvisaLink nodeserver in "production." You may want to PM @bgrubb1 and see what he thinks.

The Vista 20P with Envisalink is exactly what was used to develop the nodeserver. It does give you the ability to arm, disarm, and monitor the status of your partitions, bypass zones, toggle the door chime, etc. It also gives you a status for each zone, but the zone status is probably not as reliable (or timely) as the DSC (and I assume Elk) panels provide. With DSC panels, the nodeserver gets a specific message from the panel every time a zone opens and another specific message when the zone closes again, along with other messages that flow from these conditions (alarming, partition not ready, etc.). In the Honeywell panel, while you get a general message that the status of one of the zones has changed when a zone is opened, it doesn't identify which zone and you really never get a specific indication of when the zone goes closed again. So the nodeserver implements a "smartzonetracking" feature where it will use other status messages, such as zone bypassed and partition ready, to try and divine the status of the individual zones. I certainly wouldn't tie any fail-safe decisions to the zone status in the HW nodeserver, but to have it turn on and off lights and stuff like that would be OK.

Yes. I should have all my nodeservers running on PG3 by mid-March.

So long as the system has JRE v9 or less, or Oracle JDK v8 or less, it should work. Anything newer probably won't support Java applet launch from jnlp files. For others, download the isyfinder-2.0.jar file on the web and use the following command (in a script or batch file): java -jar .\downloads\isyfinder-2.0.jar

In addition to what @JAbraham said, it appears that you are running ISY on Polisy. If the Polisy is running both PG3 and ISY on Polisy, try 127.0.0.1 for the IP Address.

I have released the PG3 version of the MyQ Node server (v3.0.18). Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md. There is a 3-month trial period and then the Node server is $12.95 a year. I decided on an annual subscription for this one since I am generally required to update it a couple of times a year to keep it running.