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 ?
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.
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?
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.
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
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ā. 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.
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.
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.
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!