Initial setup and zone update issues on Vista 21 panel

[ufodone]

          ``

``Great work!

Background:

• Vista 21 with Envisalink 4. Firmware 01.04.202A
• I have partitions 1&2, zones 2-8, 10-18.
• A mixture of doors (5), windows (7) and motion sensors(4). All sensors are wired.

---

Testing results:

Testing sequence one:

• shutdown my production HA

• stopped VM for my production HA

• Creation of new VM for Home Assistant on my Proxmox server
• Fresh install of latest version of Home Assistant
• Installed Glances, Log Viewer and SSH
• Restarted
• Install HACS
• Restarted
• Installed Envisalink_new (0.6.4)
• Restarted
• Configured Envisalink new
• I have partitions 1&2, zones 2-8, 10-18 but I configured it as zones 1-19
• Restarted HA
• Confirmed zones 1-19 configured with partitions 1&2
• Renamed several zones
• Reconfigured to what I really have (partitions 1&2, zones 2-8, 9-18)
• Confirmed ability to delete entities for zones 1, 9 and 19
• Opened /closed all zones one by one and confirmed that the entity for the zone showed the correct state as well as the message for the keypad was correct.
• shutdown testing HA

• shutdown testing VM

  Testing sequence two:

• start VM for my production HA
• start for my production HA
• added envisalink_new
• restarted HA
• it did not pick up my existing configuration I did get a message: "Retrying setup: Unrecognized/undetermined panel type at nnn.nnn.n.12:4025" (I masked the IP)
• manually configured envisalink_new
• removed include statement for envisalink in my configuration.yaml
• restarted HA
• confirmed that all partitions and zones were created with the default names
• manually renamed all zones and partitions
• Opened /closed all zones one by one and confirmed that the entity for the zone showed the correct state as well as the message for the keypad was correct.

---

• it's a nice day here in Colorado so I opened most of the windows to air out my house.
• Screen shot of the history showing the state status of what I had opened is below:
• Observations
• I was not closing/opening the windows during this timeframe. The history was showing I was closing the windows with increasing duration for about 12 cycles then restarting.
• It missed several basement motion events
• it missed several LR motion events. It failed to pick up a LR motion clear event that occurred several seconds after the detection.
• 

Detail of just one of the window entities showing curious progression of invalid "closed" durations:

• Like the original Envisalink integration, my logfile is flooded with state changes from the keypad:

---

Clicking on the documentation link in the HA integration page takes you to: "https://www.home-assistant.io/integrations/envisalink_new" and a "Oh no! This page does not exist 😞"

---

• Logging set at debug
• Errors in the logfile:

2023-03-14 15:41:27.584 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...
2023-03-14 15:41:57.588 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...
2023-03-14 15:42:27.591 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...
2023-03-14 15:42:57.595 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...
2023-03-14 15:43:27.598 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. `Reconnecting...```

Let me know if you need more details.

_Originally posted by @hunstad in https://github.com/ufodone/envisalink_new/issues/1#issuecomment-1468890962_

[ufodone]

@hunstad Thanks for the testing. There appears to be a few different issues here.

For sequence two, I'm not sure I'm quite following your sequence.

added envisalink_new restarted HA it did not pick up my existing configuration I did get a message: "Retrying setup: Unrecognized/undetermined panel type at nnn.nnn.n.12:4025" (I masked the IP) manually configured envisalink_new removed include statement for envisalink in my configuration.yaml

On the initial restart, did you still have the envisalink section in your configuration.yaml? Did you also have envisalink_new? You definitely want to be sure to never have two configurations for the same EVL device at the same time. The EVLs only accept a single connection simultaneously so multiple configs for the same device can cause problems. I'm wondering whether the initial Unrecognized... message was due to the original envisalink integration already having created that connection. Those errors in the log file about the server closing the connection could also point to that.

Regarding the zone flapping issues, are you able to provide debug logs of the issue occuring? It's possibly related to the new algorithm introduced for Honeywell panels. I don't have a Honeywell panel myself so it's difficult for me to reproduce myself.

Like the original Envisalink integration, my logfile is flooded with state changes from the keypad:

I've heard others having this issue. I suspect this is due to the honeywell panels cycling through the faulted zones, etc. and sending updates for each one. I'm not sure what the right answer is here as I assume reflecting the keypad text in HA is valuable. I believe others have used the exclude feature in either the history or recorder integrations to suppress these updates being written to the DB.

[hunstad]

re: initial config. I probably missed a step leading to the errors.

re: Regarding the zone flapping issues. I'll try to get more detailed logs for you.

re: I've heard others having this issue (log flooding). I do have the same issue with the old envisalink integration. This occurs with the keypad text as well as the individual zones. (for the zones, the last triggered time attribute is changed, but not the zone state). My solution was to create parallel binary.sensor template entities for each zone and keypad entities and use jinga rules to determine when to update. That what I can use the exclude feature for the envisalink entities.

[ufodone]

The last_tripped_time updates on the binary sensors are due to a bug in the integration which I've logged as #29. This is newly introduced with this version of the integration but given how the zone timers used to work on the Honeywell systems, I can imagine how a similar issue could have existed there.

I also tried reproducing the zone flapping with my mock Honeywell EVL tool but didn't have any success so I'd definitely love to get some logs at some point if you're able.

[ufodone]

I've pushed a new release which should fix the last_tripped_time being incorrect and updating needlessly so I'm going to close this issue now.

If you still experience the zone flapping with a large number of zone open and can provide logs, please feel free to open a new issue. Thanks.