Node Server Requires Frequent Restart (eisy v5.8.0)

[vspete]

First, I love this node server when it is working.  I am using a HW Vista Panel with 24 zones and 1 partition. When first started the panel and all 24 zones report correct status and update status in a timely manner.  My system has 5 motion detectors. After some random number of hours (less than a day), the motion detectors stop updating their status and remain showing an "open" condition. Occasionally, an exit door status will freeze reporting an "open" state despite being closed.  The node server partition status reports "not ready" when any of the zones report an "open" condition.  The panel console, Eon App, and Total Connect all show the panel status to be "ready"  Restarting the node server clears this condition and we start fresh.

My suspicion is that the frequency of Motion triggers and potential overlap with processing zone updates is causing the issue. I believe that Total Connect and Eon do not use motion zones to determine whether the panel can respond to commands. The Eon App shows motion detectors to be open for a long time following a trigger.

Any help with this issue will be greatly appreciated.  Thanks in advance....

[Goose66]

Do you have "smartzonetracking" enabled? From the  current Release Notes:

Quote

6. With SmartZoneTracking enabled, the node server keeps up with the state of zones (open, closed) instead of relying on the EnvisaLink's zone state tracking. States for bypassed zones show as "Unknown." If the feature is disabled, then the node server relies on the zone state tracking in the EnvisaLink. Either way, zone states are squirrely.

What shouldn't be "squirrely" is Ready status. This is (or at least has always appeared to be) reliably and accurately reflected by the EnvisaLink - what you see on your panel should always be the same as what you see in the Admin Console. If this is out of sync, then the problem may lie in the link between EnvisaLink and your panel.

But I need to look at it more closely. Let me know on the smartzonetracking setting.

[vspete]

Yes, I have had "SmartZoneTracking" enabled while experiencing this issue. I haven't experienced any issues overnight when the motion detectors are not being frequently triggered.  When walking through the house, one can trigger multiple zones in an overlapping fashion, viz., a motion zone is triggered while another motion zone has yet to no longer sense motion. The most disturbing thing is that when a wired exit zone is also "opened" the administrative console shows that zone as open even after it is closed (and system not ready).  The console, EzeOn App, and Total Connect App show everything okay and ready to arm.  As for connectivity: the eISY and EnvizaLink communicate via a wired LAN.

Viewing the node server log, is not throwing any errors and seems to indicate that no change is occuring.  Also, the log shows that only the first 16 zones are being "set."  All motion detectors are in zones 3-7.  Bypassing, a zone higher that 16 does correctly report its condition.

As of this morning, I have disabled "SmartZoneTracking" to see if that makes a difference.  Thanks...

Edited February 14 by vspete

[Goose66]

like I said, the zone's are squirrely. By squirrely, I mean that the EnvisaLink does a good job of informing the plugin when a Zone is open, but not a good job of informing the plugin when the zone closes again. The EnvisaLink says that's because the panel doesn't inform it:

That's what smartzonetracking is about. It basically uses the ready status of the partition and the bypass flags to help the plugin keep up with the zone statuses. If one zone is open, e.g., a motion zone, and then another zone is open, e.g. an exit door, without the partition going to ready in between, then it is possible for the closing of the motion zone to not take place until all zones are closed and go to ready. However, the ready status should be solid - when the partition goes ready, the EnvisaLink sends a specific command to the plugin and the plugin sets the status (ST driver) for the partition node to ready. There's really no logic involved there.

First thing is to make sure you set up your panel for the EnvisaLink according to the instructions, including ALL the programming steps. Next, re-enable smartzonetracking and run it with Debug-level logging set in the PG3 dashboard until the error condition occurs, then send me the plugin log file.

[vspete]

Thanks for the detailed information regarding zone status communication.  I did program my panel per the EnvisaLink instructions. As I indicated, I would try running the node server WITHOUT using the "smartzonetracking" option.  I shortened the "shortpoll" time from 30 to 10 seconds giving me an average 5 second response time. This level of responsiveness is just fine and I have yet to experience the node server becoming non-responsive.

I appreciate your offer to troubleshoot the smartzonetracking issue. My situation is probably an outlier based on multiple zones being triggered at virtually the same time on a regular basis. If it would help you, I can re-enable smartzonetracking and run it with Debug-level logging set in the PG3 dashboard until the error condition occurs, then send you the plugin log file.  Thanks again.

[Goose66]

A new version of the EnvisaLink-HW plugin has been released that should fix your problem. Malformed data messages like the one you are consistently experiencing should be ignored. Of course, because I was unable to reproduce the error, I await your feedback that the problem has been fixed.

[vspete]

2 hours ago, Goose66 said:

Malformed data messages like the one you are consistently experiencing should be ignored.

Thanks for releasing the update. I will install and advise after a few days.  Whether the offending data message is "malformed" or "undocumented", ignoring it would seem to be the appropriate solution. I was able to suppress these messages by changing zone #10's type to "interior type". Zone #10 is a perimeter (interior house to garage door) zone physically located between two interior motion zones. This change negatively affects my "stay" security but doesn't adversely affect "away." I will revert #10's zone type to a "perimeter," test the plugin and let you know.

[Goose66]

I agree that it’s weird that you are consistently receiving the same data yet I am calling it “malformed.” But I say that only because I can see how the data is malformed - specifically the message data starts in the correct format for a few characters, then contains one or two invalid characters, then contains a complete message data string in the proper format. That’s why I am calling it malformed.

[Goose66]

Ok, as soon as I posted the above, something occurred to me: the bytes of data read from the socket are converted to Python strings (Unicode) before the message data is parsed. Maybe there’s something in that conversion that’s causing a first message to be truncated and then combined with the subsequent message. For example, since Python is written C, if one of the bytes was null, perhaps, it could terminate the string and the cr/lf from the socket read would never be received and it would just read into the next message. Of course, it seems like this would all be handled by the Python socket libraries or string conversion libraries. Or maybe it’s just something in the EnvisaLink messaging format that wouldn’t be a problem in C or node.js but is inherently incompatible with Python. But maybe something to look at.

[vspete]

I am pleased to report that so far everything is working perfectly with "SmartZonetracking" enabled.

Clearly, based on the offending message, "malformed" is the correct term for this message. What I find interesting is that while the malformed messages are frequent and identical, they do not occur every time a particular set of sensors are triggered or opened individually.  What I have observed below seems always to be true:

1. The panel is in a disarmed state
2. An Exit Zone is Open
3. A perimeter zone is open (or opened) AND one (or two) motion detectors are open (simultaneously).

What I am not sure of (in addition to the ambiguity described in #3) is whether the malformed message is created during, after, or concurrent with the expiration of the entry delay initiated by opening the Exit Zone. In a disarmed state, the entry delay doesn't mean anything, but I don't know whether it might affect EnvisaLink messaging.

I am going to mark this issue as solved.  Thanks so much Randy for the effort you have put into addressing this issue.

Edited March 4 by vspete