hart2hart Posted May 30, 2023 Posted May 30, 2023 (edited) Goose66, I moved over to EnvisaLink-DSC from NodeLink. Glad to report success and thank you for the NS as all went well, but following are three questions and a request to ponder: 1) Is Panel "Force Update" a form of Set Query to the NS to update all data elements? 2) Is Panel "Alarm Panel Connected" the heartbeat that NS and Envisalink are talking? 3) I have not created firewall rules and in fact my security system is monitored by Eyez-On. In my case, is there an advantage either way to the NS param disablewatchdog? Which way would you set it? -- Why? Request to Ponder) I have many programs that use the status of the security system. An example and there are many others -- for that at home look, lights are turned on and off at times based on is the security system armed away. A big difference between EnvisaLink-DSC and NodeLink is that NodeLink represents panel status as Armed Away, Armed Stay and Disarmed so there was little traffic related to status changes. Envisalink-DSC has the armed statuses (with zero entry variants) and the very accurate Ready and Not Ready (vs Disarmed). I've got several interior motion sensors in the security system. The result is that every time you walk around, they turn on and then off. Given my setup, this translated to high volume of programs triggering (even if false) as the status changed usually between Ready and Not Ready. The result was multiple Random all on events an hour after I updated the NS dependent programs and restarted the node server. As I was converting the programs, I was a little concerned at the number of programs using the armed away construct as the list had grown over multiple years. However, I thought (wrongly) it had worked for years and I felt/assumed it would work with a different node server. When it quickly happened a couple times, I realized something was structurally different and isolated it to the status changes and how many/how fast they were occurring. I isolated the rapidly changing statuses to 3 programs that set integer variables (simple example below) and updated all the programs to use the variables as the programs real triggering event (except for one as we will see) was the other part of the If and the security status was secondary. The restructuring stopped the random all on events. Security:Set Armed Stay If 'Security System / Security System:Partition' Partition State is Armed Stay Or 'Security System / Security System:Partition' Partition State is Armed Stay Zero-Entry Then $Security_Armed_Stay = 1 Else $Security_Armed_Stay = 0 I quickly made several program updates to stabilize my lighting setup. However, by doing this, I could no longer see and diagnose the issue looking at the actual problem. However, through a review of text file of all programs (supported by a log and event capture), I isolated the source of the problem to one program being triggered on both the true and false side. The program was only updating a scene and a device but the number of times it was occurring and likely the much faster speed of the eisy executing the event translated to random all on events. I'll restructure that program, so it is only triggering a couple times a day and put Wait between the scene and device updates for when it does occur. The ponder moment is -- could another status be maintained by the node server that only presents armed and disarmed so this kind of "hidden" event is less likely to occur for me and others? Finally, I really like the new setup and thanks for the hard work to develop and support. Paul Edited May 30, 2023 by hart2hart
Goose66 Posted May 30, 2023 Posted May 30, 2023 (edited) 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. Edited May 31, 2023 by Goose66
Goose66 Posted May 30, 2023 Posted May 30, 2023 (edited) 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." Edited June 1, 2023 by Goose66
Goose66 Posted May 31, 2023 Posted May 31, 2023 (edited) 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." Edited June 1, 2023 by Goose66
hart2hart Posted June 1, 2023 Author Posted June 1, 2023 On 5/30/2023 at 5:56 PM, Goose66 said: Thanks for the insights.
GTench Posted June 2, 2023 Posted June 2, 2023 Not sure if this will help or not but this is how I check for the alarm status (stay armed, away armed, away armed no bypass) 1. Defined one of my unused zones as type 26 (used for automation purposes only and will not trigger an alarm). 2. Defined an unused PGM as type 17 (away armed status) 3. Connect a zone resistor from zone terminal in step 1. to ground. 4. Connect a wire from zone terminal in step 1. to the PGM terminal in step 2. The zone in step 1. will now show as closed when the system is not armed. When the system is armed, PGM shorts to ground thus bypassing the resistor and the zone shows as open. I use this zone's status from the node server to determine the alarm's status. I repeated this process using 2 more pairs of zone/PGM to define zones reporting "stay armed status" and "armed away no bypass" I believe that I tried just using the PGM status values from the node server but for whatever reason it did not work for me but this was over a year ago so am unclear as to why now. Goose66, I also want to say thanks for the node server. It has been working great for me
hart2hart Posted June 3, 2023 Author Posted June 3, 2023 On 6/2/2023 at 2:15 PM, GTench said: Not sure if this will help or not but this is how I check for the alarm status (stay armed, away armed, away armed no bypass) 1. Defined one of my unused zones as type 26 (used for automation purposes only and will not trigger an alarm). 2. Defined an unused PGM as type 17 (away armed status) 3. Connect a zone resistor from zone terminal in step 1. to ground. 4. Connect a wire from zone terminal in step 1. to the PGM terminal in step 2. The zone in step 1. will now show as closed when the system is not armed. When the system is armed, PGM shorts to ground thus bypassing the resistor and the zone shows as open. I use this zone's status from the node server to determine the alarm's status. I repeated this process using 2 more pairs of zone/PGM to define zones reporting "stay armed status" and "armed away no bypass" I believe that I tried just using the PGM status values from the node server but for whatever reason it did not work for me but this was over a year ago so am unclear as to why now. Goose66, I also want to say thanks for the node server. It has been working great for me Thanks and that is an interesting solution. At this point, I'm using these two programs to catch and isolate Armed status into a State variable. If the programs have issues, I'll try your solution. Security:Set Armed If ( 'Security System / Security System:Partition' Partition State is Armed Away Or 'Security System / Security System:Partition' Partition State is Armed Away Zero-Entry Or 'Security System / Security System:Partition' Partition State is Armed Stay Or 'Security System / Security System:Partition' Partition State is Armed Stay Zero-Entry ) And $Security_Armed is not 1 Then $Security_Armed = 1 Else - No Actions - (To add one, press 'Action') Security:Set Disarmed If ( 'Security System / Security System:Partition' Partition State is Ready Or 'Security System / Security System:Partition' Partition State is Not Ready ) And $Security_Armed is not 0 Then $Security_Armed = 0 Else - No Actions - (To add one, press 'Action') I have equivalent programs for Armed Away and Armed Stay.
Recommended Posts