Hi, same problem here after upgrading HA from 0.92 to 0.95.4 (RuntimeError: unable to perform operation on <TCPTransport closed=True reading=False 0x707ff030>; the handler is closed)
Double checked config, several restarts, problem persists. No connection to envisalink.
Today I noticed i was running old Hassio (not sure about version) on RPi3, so I click UPDATE button in Hass.io / System.
Host OS updated to HassOS 2.12 and everything back to normal, envisalink stable 
So I recently played around with OpenHAB2 and, it can connect to my DSCServer without any issues and turn my alarm on and off. My Vera controller can also connect to the DSC Server without an issue. When I try to connect Home Assistant to the DSCServer, the system just hangs and never comes back. If I set HA to point to a different IP address (setting the HA to point to incorrect Envisalink IP on purpose), HA gives up and continues to load HA UI. So there is definitely something up with the HA implementation for the communication, it is like it initiates communication and just waits constantly to hear back. I am probably going to use OpenHAB2 for just the Alarm system and bridge it to Siri (that was my original goal in the first place) until something changes with the DSC implementation for HA. I wish I knew how to code properly to help fix this or get more debug logs.
Sorry to hear that tubo97se. I’m not sure what else to try as I’ve mentioned that I use HA with a dscserver and it always connects. Now, HA does randomly loose connection to the dscserver and I have to restart HA to get it to reconnect, but it is always able to reconnect. I believe you mentioned that you were running the java dscserver. That is really the only difference I can see between your setup and mine as my dscserver is running on an old android which is connected to an EVL3 and a DSC 1832 panel. Maybe try connecting HA directly to the EVL temporarily to troubleshoot. At least that would eliminate one of the variables in your setup even if thats not the way you want it running long term.
Thank you for the regular feedback on what to try. I did recently change some things in my setup:
Here is what I observed:
Cheers
For anyone having envisalink troubles since 0.98.x, there is an open issue on it - https://github.com/home-assistant/home-assistant/issues/26438
For what it’s worth, I’m running 98.3 and am not having any problems with the Envisalink component starting. Best of luck tracking it down.
Good to know. A couple of people on the 0.98 release notes discussion have reported issues as well. Are you running an EVL3 or 4? And are you running hassio on a Pi? Just wondering what might be different about a working setup.
I’m on 98.2 and Yesterday I had to restart Home Assistant a second time to get the Envisalink component working.
I have an EVL-4. HASSIO .98.3 installed on RasPi3B+. Both connected by Ethernet directly to router. The update to .98.3 was about 48 hours ago. No errors related to Envisalink or DSC in log, and all security/communications are working fine.
BTW -I see a 98.4 update was just released, but not seeing release notes for it yet.
I’ve tried multiple restarts and a full reboot. No love. I am using an EVL3. Roll back to 0.97 and everything works fine. Tried 0.98.4 today, not working. I’ll roll back again.
I’ll upgrade as well and give everything a try to see if I can lend a hand. Unfortunately the way components/platforms get initialized has had major changes, and i’m a bit out of touch with some of that- i haven’t made changes in quite some time as things have in general been working for folks outside of some seemingly isolated cases (until now).
Hi,
Updated today to 0.98.5 from 0.97.2 and get the same problem with Envisa
No issues here with DSC and EVL3 on 0.98.x and upgraded today to 0.99 and no issues at all, rock solid here for years.
I think I needed to remove quotes in configuration for code: some longe time ago if I remember correctly.
code: ‘1234’
to
code: 1234
I’ve tried every variety of tips as well as experimentation on my own and it just doesn’t work. I’ve tried each new release up to 0.99.3.
@Cinntax I appreciate everything you’ve put into this integration. Are you still planning to have an active role in it, or is anyone else? The number of people reporting the same issue is (slowly) rising according to the github issue report.
Hey everyone,
I’m still around 
- however i suppose it’s obvious that life has gotten in the way here, as i really haven’t had much time for this- i apologize. I’ve been looking at the issue in github, and unfortunately i’m unable to reproduce.
One thing i see from the logs is that, upon initial connection, the network connection is failing, reporting that to HASS, and HASS is giving up on initializing the component- but since the envisalink library supports connection retries, it continues on, even when the component initialization has given up- not sure if HASS supports retries on the actual component initialization or not!
The envisalink library uses the same asynchronous loop as the rest of HASS. So I have a theory that all of the rest of the initialization “stuff” is interfering with the connection timeout of 10 seconds.
I’m running hass on an octa-core server within a container vs. a RPI3 so that seems to be a key difference, and why i’m hoping i’m right here.
What happens if you, in your envisalink config- add a “timeout” configuration-
like so
timeout: 100
hi @Cinntax, I tried the timeout of 100 seconds as you recommended and unfortunately it did not improve things.
Here are a couple more possible clues, which I tried based on feedback I’m seeing others provide about their successes:
On one occasion I was able to reboot the envisalink module before restarting my HASS and the component initialized properly. I’ve not been able to repeat that - may be very timing dependent. Rebooting the envisalink unbinds the current TPI session, and you are probably aware that the envisalink only allows one TPI client at a time.
By running the DscServer applet, I can get the envisalink component to start up reliably. This may be because DscServer can host multiple external TPI client sessions while binding itself to the envisalink for the single TPI session that the hardware allows.
Yeah i think the key difference with the DSCServer is that it’s providing an isolation layer (with a much more stable network connection). For example, it appears it would be possible to be connected to the DSCServer, and DSCServer may/may not even be connected to the envisalink- so it can provide a smoothing effect.
I suppose I could immediately return “connection success”, and also provide a data flag whether we’re actually connected or not- how does dscserver behave if it loses actual hardware connection on it’s end?
The other idea would be to see if there is a possible way of retrying the initializiation process, since i am retrying behind the scenes (which is why my first idea would work pretty well).
Ok- so upon further inspection of the component code, i’m able to perform a retry of the initialization process (or rather, the component initialization won’t “give up” upon first failure). So I’ve gone ahead and pushed a new library version, and working through the pull request process with HA.
I hope that should help things along.
Looking forward to trying your new version!
From what I can tell, when DscServer loses the EVL connection, it drops clients (HA). It then has a recurring 30 sec retry strategy to reconnect to the EVL. Once it reconnects, HA does not appear to be making any attempt to reconnect as a client to DscServer. I have to restart HA to get everything functional again.
So does anyone using a dsc alarm with an envisalink 3 have the status of any sensor bounce on them?
I have a 3rd party program repeating since the envisalink can only have one connection at a time. I have this program called nodelink give the status of my alarm to my ISY hub. Now I have it send statuses to homeassistant also.
Homeassistant came after the ISY for me and in the isy this doesn’t happen. Now in homeassistant every time a sensor changes state it stays for a few seconds, flips back to the state it just changed from and then in another few seconds it returns to the correct state.
I can mostly ignore this, but there are times when it is pretty annoying.
Any thoughts?