Envisalink integration. Things users should know about it

I had a similar issue. My problem related to a weak network connection and so DHCP would fail and the Envisalink would drop offline causing HA to lose access. The problem was that my WiFi to Ethernet repeater was not functioning properly. After replacing it, everything worked smoothly.

On a side note, I sometimes wonder about my EV4 reporting to their cloud and so blocked the connection via my firewall. The EV4 reported that it could not connect to the server, but worked fine in all other respects.

Iā€™m getting this error in the logs but otherwise my sensor is working but this annoying message in the notifications is popping out. I think it started after day light savings on the weekend but I checked the time its correct in envisalink and homeassistant. Any idea what to do ?

Logger: pyenvisalink.envisalink_base_client
Source: /usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py:247

Unable to connect to envisalink. Reconnectingā€¦

This is the code that provides the error:

    def handle_connect_failure(self):
        """Handler for if we fail to connect to the envisalink."""
        self._loggedin = False
        if not self._shutdown:
            _LOGGER.error('Unable to connect to envisalink. Reconnecting...')
            self._alarmPanel._loginTimeoutCallback(False)
            ensure_future(self.reconnect(30), loop=self._eventLoop)

This routine is called when the library cannot connect to the EVL.
This can occur on initial connector or after a connection loss (which calls for reconnect).
So it tries to reconnect every 30s, is that how often it occurs?
Is there a ā€˜The server closed the connection. Reconnectingā€¦ā€™ message when this started?

Yes the message says
ā€˜ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnectingā€¦ā€™
Its been happening every 4-5 minutes

I have checked Envisalink page (http://192.168.x.x)/3) EnvisaLink TPI status is online for homeassistant client.

Same issue with my setup (and it used to work) - any progress in debugging this? Any additional data that we can provide?

I have not been able to track down anything obvious, I suspect it is most likely related to the network or to the evl, try powering off the panel and evl together for about 60 seconds and see if that solves the problem.

Do you know what firmware version your device has?

Iā€™m running 01.04.176 on an EVL4 board.

Mike

Yeah, power cycling the board and panel did the trick - I had tried numerous times to use the ā€œRebootā€ firmware option but this didnā€™t do anything.

Thanks!
Mike

Iā€™m having the same error come up. Sometimes the EVL is steady for a couple hours, other times every 20-30 minutes it drops and re-connects. I previously used the EVL on another home automation setup and it was rock-solid, so I am almost 100% sure itā€™s not the unit (I even re-connected the EVL to the old home automation and it remains rock-solid on the connection there.)

Iā€™ve recently hooked up my DSC alarm again (it was laying dormant as I had to move during renovation).

With an Envisalink 4 Iā€™ve never been able to successfully issue the ā€œalarm_control_panel: Triggerā€ service from Hass.

Some how it always shows in Hass as cleared, immediately after. Whereas on the Envisalink web page it shows as ā€˜In Alarmā€™.

Unfortunately I donā€™t have a physical keypad or siren attached right now to confirm any surrounding behaviour.

I have no idea where to start investigating this. Any thoughts would be welcome! It seems like an inconsistency in the library that Hass is using if itā€™s showing something different to Envisalink?

That might be a problem in the HA code, I am not sure, I have made many changes there trying to get it to work perfectly with a Honeywell panel, the code that parses the alarm state is not robust

My hardware is as follows. I use 2 partitions in separate structures. Home and Workshop

Panel: DSC1864 v4.6
Keypad: RFK5564 v1.3
Keypad: PK5500
Keypad: LCD5511
Envisalink 4

I tested both partitions and I can confirm that the ā€œHomeā€ mode, DSC ā€œStayā€ mode, works as intended with entry-delay enabled and motion devices disabled. The ā€œNightā€ mode, however, is as you stated. There is no entry-delay and the motion devices are not enabled. So, pretty useless for me and I just use the bedroom keypad in that scenario.

I installed and integrated this system into Samsung Smartthings in 2017. I used the Alarmserver integration, with webCoRE later on. I switched over to Home Assistant in 2020 and have been patiently waiting for an update that might resolve some of the issues that you have listed. Itā€™s always been my opinion, and possibly your implication as well, that much of the problem lies in the sharing of code between the two systems. Iā€™m still upset over having to use the word ā€œHomeā€ rather than ā€œStayā€. :wink: With the Smartthings integration and webCoRE, I had a ā€œStayā€ button that would arm with ā€œno-entry delayā€, (star, 9, access code), with I got home for the evening, and then a ā€œNightā€ button that would send, (star, 1), to enable the motion devices when I went to bed. That, and the ā€œAwayā€ function is about all Iā€™ve ever needed. I realize that I could accomplished these things in Home Assistant but I would prefer to have the functionality within the Envisalink integration, if it is possible.

Please let me know if I can be of any assistance with your testing and troubleshooting of the DSC alarm panel.

Regards,
Mitch

1 Like

I know Iā€™m late to the topic here, but thought I would contribute. I was trying to figure out how to turn lights on when the alarm triggered using a Honeywell Vista panel and the Envisalink. This worked for me. Maybe it will help others.

description: Turns lights on when alarm triggered
trigger:
  - platform: state
    entity_id:
      - sensor.home_keypad
    attribute: alarm
condition: []
action:
  - type: turn_on
    device_id: 9eea17aa772d0ee7fd3e3xxxxeea639c
    entity_id: switch.kitchen_lights
    domain: switch
  - type: turn_on
    device_id: 963d50c380bef0118a02xxxxf599475a
    entity_id: switch.hall_light
    domain: switch
  - type: turn_on
    device_id: 6ba772bf03fdd0bfedf4xxxx646ec0c6
    entity_id: switch.den_light
    domain: switch
mode: single
4 Likes

A slight heads up - My Envisalink EVL-4 (DSC) got a firmware upgrade pushed by EyezOn today to 01.05.x. Previously it was 01.04.x. This appears to be a ā€œmajor update*ā€ confirmed by EyezOn support. (* = their words).

This update broke things for me. Iā€™m still investigating. Currently the problem seems to be in Juggie/AlarmServer, which Iā€™m using as a proxy to enable full envisalink logging and multiple connections to the envisalink. The Hass Pyenvisalink integration connects to AlarmServer and has been running well for years.

Pyenvisalink started from the same code base as AlarmServer sometime in the distant past. It may not be affected by whatever changed since the code has diverged.

One disturbing bug to note, I can tell from AlarmServer, that the Hass Pyenvisalink integration isnā€™t getting any responses to itā€™s ping requests (code 000) from the Envisalink, but doesnā€™t seem to be reporting that anywhere. The only thing in the log is:

2023-01-27 14:42:15.237 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...

FYI ā€“ After a bit of digging I found the bug in the Envisalink 4 (DSC) firmware 01.05.203. The envisalink was spewing Partition 2, 3, 4 Not ready messages continually. It was sending those 3 messages about 10 times a second.

EyezOn rolled my firmware back to 01.04.202.

I noticed this because of a bug in Juggie AlarmServer.

According to the EyezOn forum firmware update thread the new firmware was only pushed out to EyezOn sidekick users (LTE backup radio) and is the default on new hardware.

I didnā€™t get a chance to try Home Assistant connected directly to the envisalink without AlarmServer as a proxy. I had limited time and I didnā€™t want to do a bunch of restarts to my main home assistant instance for re-configurations. It is possible it might have somewhat worked, consuming a bit of CPU processing the messages the envisalink was spewing.

Whatā€™s probably most relevant, the Envisalink (DSC) integration in Home Assistant didnā€™t provide any clear sign that it couldnā€™t connect to the Envisalink and that the entities were stale. The zones, keypad, and alarm entities all stated in their previous state and didnā€™t go unavailable.

Since you donā€™t know if Home Assistant is still successfully connected to your Envisalink, it means you shouldnā€™t really it trust it for monitoring your alarm system.

Hey,

Admittedly I kind of put development of AlarmServer aside when I discovered home assistant.

I can also confirm that my Envisalink connection is stale and Home Assistant is not reporting an issue. I did notice before that much of the python library used by the Envisalink module is from my code so Iā€™m guessing the firmware bug is causing the same issues in both places though I donā€™t know how the library has evolved lately as I havenā€™t looked.

I think Iā€™ll have a bit of time tonight to have a look at this to see if thereā€™s anything that can be done from the python side of things to mitigate the issue, despite the firmware bug the code in AlarmServer (and the python lib if the same bug is there) should not be crashing.

Iā€™m not the developer of the module or HA integration but Iā€™ll take a look at things tonight and see what I can figure out. Im also on the HA discord if anyone is looking.

Hey @juggie itā€™s been a long time, good to bump into you again and thank you for AlarmServer. Iā€™ve been depending on it for years to keep close tabs on my DSC system having it log everything and provide a convenient proxy for multiple connections.

I created/updated an issue on your GitHub repo with details of the bug in AlarmServer that was triggered by the envisalink 01.05.203 firmware spewing 30ish messages a second.

If anyone else has an Envisalink 4 and got pushed 01.05.203 (was supposed to only go to people with their Sidekick LTE cellular connection) you might want to contact EyezOn support about a rollback to 01.04.202. They rolled back mine this morning (Saturday).

I saw that thanks! Thatā€™s what prompted me to check my HA for the same issue. Iā€™ve got a few things on the go this afternoon but once the kid is in bed (my last commits also line up with when he was born in 2017!) Iā€™ll have a look and see what if anything can be done.

If your on the discord message me there and Iā€™ll check in later.

Edit: Oh as a side note I donā€™t have the LTE version. And I have the 3.

Looks like my problem was me, configuration problem after redoing some networking stuff. So as a result, no issue with EVL3, however it didnā€™t show any issue in the HA notifications which would be nice to add.

Iā€™m gonna totally hijack this thread for a sec just because Iā€™m kind of a newb and I think I found the folks who may, might, maybe be able to help me. Iā€™m trying to integrate my EVL-4 into home assistant and I put the code in my config.yaml and customized it for my setup. I think itā€™s connecting because when I hit one of the buttons for, say, ā€œalarm stayā€ in home assistant my keypad will beep but it never goes into an alarm mode, nor does home assistant register any changes.

One thing I canā€™t figure out is how to find the logs for this. Iā€™ve dug around and Iā€™m sorry but Iā€™m having a hard time understanding how to look for this since itā€™s not a separate add on that plugs in and you can use the actual add-on to look at logs.

I feel like once I can look at whatā€™s happening maybe I can hammer out a solution on my own or at least ask a better question. Thanks in advance for the help!

S