Thanks for tracking this down. I tested the change over 10 restarts and everything loads up correctly every time.
sweet! Pull request going in now.
1 Like
Sorry- not at the moment. It seems like it would be relatively easy to pull off, just need to properly handle event code 750. I’ll keep that in mind for a next release. I’d also want to see if that same concept exists on the honeywell side, as i’m trying to keep this implementation honeywell and DSC compatible.
Just updated to 0.29.4 which has your fix and I confirm it’s all working perfect now! Thanks so much for not giving up, you’re doing such an awesome job! 
Thanks! Much appreciated- are you now seeing states in your “sensor”? I know with the dsc folks the sensor status was rarely/almost never updated…
Hi everyone,
I have been using HA for about a week and always had problem connection to the Envisalink when the socket was not closed properly as explain in the TPI doc. I usually had to reboot the Envisalink from the webpage and wait couple of minutes before restarting HA for a fresh socket. This typically happened when I rebooted and didn’t let HA close the socket.
With the upgrade to 29.4 today, I have had a terrible time establishing a socket. I was only logged into 29.4 a couple times before I didn’t close it properly and now can’t keep the connection. Any ideas on how I should close the socket properly or reset procedure for the Envisalink so it can connect? Thanks
(HA 29.4, Python 3.50, EVL3, Raspberry Pi 2)
16-09-29 21:56:44 homeassistant.components.emulated_hue: Listen IP address not specified, auto-detected address is 192.168.2.186
16-09-29 21:56:44 homeassistant.core: Bus:Handling <Event component_loaded[L]: component=emulated_hue>
16-09-29 21:56:44 homeassistant.core: Bus:Handling <Event service_registered[L]: domain=logbook, service=log>
16-09-29 21:56:44 homeassistant.core: Bus:Handling <Event component_loaded[L]: component=logbook>
16-09-29 21:56:44 homeassistant.core: Bus:Handling <Event component_loaded[L]: component=alexa>
16-09-29 21:56:44 root: Connecting to envisalink on host: 192.168.2.18, port: 4025
16-09-29 21:56:44 pyenvisalink.envisalink_base_client: Latching onto an existing event loop.
16-09-29 21:56:44 pyenvisalink.envisalink_base_client: Started to connect to Envisalink… at 192.168.2.18:4025
16-09-29 21:56:44 pyenvisalink.envisalink_base_client: Connection Successful!
16-09-29 21:56:44 pyenvisalink.envisalink_base_client: The server closed the connection. Reconnecting…
16-09-29 21:56:49 pyenvisalink.envisalink_base_client: Started to connect to Envisalink… at 192.168.2.18:4025
16-09-29 21:56:49 pyenvisalink.envisalink_base_client: Connection Successful!
16-09-29 21:56:49 pyenvisalink.envisalink_base_client: The server closed the connection. Reconnecting…
16-09-29 21:56:54 homeassistant.components.envisalink: Timeout occurred while establishing evl connection.
16-09-29 21:56:54 homeassistant.bootstrap: component envisalink failed to initialize
16-09-29 21:56:54 homeassistant.loader: Loaded switch.command_line from homeassistant.components.switch.command_line
16-09-29 21:56:54 homeassistant.core: Bus:Handling <Event state_changed[L]: new_state=<state switch.outside_lights=off; friendly_name=outside_lights @ 2016-09-29T21:56:54.783717-07:00>, entity_id=switch.outside_lights, old_state=None>
16-09-29 21:56:54 homeassistant.core: Bus:Handling <Event state_changed[L]: new_state=<state switch.family_light=off; friendly_name=family_light @ 2016-09-29T21:56:54.821753-07:00>, entity_id=switch.family_light, old_state=None>
16-09-29 21:56:54 asyncio: Task exception was never retrieved
future: <Task finished coro=<BaseEventLoop.create_connection() done, defined at /usr/local/lib/python3.5/asyncio/base_events.py:548> exception=ConnectionResetError(104, “Connect call failed (‘192.168.2.18’, 4025)”)>
Traceback (most recent call last):
File “/usr/local/lib/python3.5/asyncio/tasks.py”, line 241, in _step
result = coro.throw(exc)
File “/usr/local/lib/python3.5/asyncio/base_events.py”, line 645, in create_connection
raise exceptions[0]
File “/usr/local/lib/python3.5/asyncio/base_events.py”, line 632, in create_connection
yield from self.sock_connect(sock, address)
File “/usr/local/lib/python3.5/asyncio/futures.py”, line 358, in iter
yield self # This tells Task to wait for completion.
File “/usr/local/lib/python3.5/asyncio/tasks.py”, line 290, in _wakeup
future.result()
File “/usr/local/lib/python3.5/asyncio/futures.py”, line 274, in result
raise self._exception
File “/usr/local/lib/python3.5/asyncio/selector_events.py”, line 436, in _sock_connect_cb
raise OSError(err, ‘Connect call failed %s’ % (address,))
ConnectionResetError: [Errno 104] Connect call failed (‘192.168.2.18’, 4025)
16-09-29 21:56:54 homeassistant.core: Bus:Handling <Event state_changed[L]: new_state=<state switch.fireplace=off; friendly_name=fireplace @ 2016-09-29T21:56:54.855387-07:00>, entity_id=switch.fireplace, old_state=None>
Yes, it does seem to be updating the status now that it never did before. Again, job well done! It’s working really well now.
One limitation of the envisalink device is that only 1 client can connect to the TPI at a time. I have seen this behavior before when I have my “live” HA connected, and then I try to connect again using my development instance.
Ok thanks. I found that deleting /home/hass/.homeassistant/deps directory help the envisalink connect to HA.
Where does Envisalink config has to go ???
alarm_control_panel.yaml ???
alarm_panel.yaml ???
I am kind of lost…
This is what my alarm.yaml looks like:
#optional
port: 4025
evl_version: 3
keepalive_interval: 60
zonedump_interval: 30
#required
host: xxx.xxx.xxx.xxx
panel_type: HONEYWELL
user_name: xxxx
password: xxxx
code: '0000'
zones:
09:
name: 'Front Door'
10:
name: 'Garage Entry'
12:
name: 'Basement Door'
11:
name: 'Back Door'
13:
name: 'Kitchen Window'
14:
name: 'Bedroom 1 Window'
15:
name: 'Bedroom 2 Window'
16:
name: 'Bathroom Window'
17:
name: 'Master Bathroom Window'
18:
name: 'Basement Bay Right'
19:
name: 'Basement Bay Left'
partitions:
1:
name: 'Home Alarm'
and my line in configuration.yaml:
envisalink: !include devices/alarm.yaml
Oh- really everything goes in configuration.yaml. You can optionally split various items out into separate files if you’d like just to keep things easier to maintain, but if you’re struggling - it’d probably be easiest just to keep everything together in configuration.yaml.
Thank you, I’ll try that.
Do I need - platform at the top as shown below?
- plaform: envisalink
#optional
port: 4025
evl_version: 3
keepalive_interval: 60
zonedump_interval: 30
No- you just need the include line in configuration.yaml, and the contents in your secondary file.
The platform line is when you have a more generic component like a switch or sensor, and you need to tell ha WHICH switch/sensor. In this case, the envisalink config is a hub config, much like Zwave or Vera.
Man that is confusing. Knowing when to include - platform and when not to. 
I’m pleased to advise though that fixed my problem so thank you. Simply leaving out - platform was all it took. Frustrating though that leaving this in will prevent HASS from starting altogether.
I agree very confusing but worked… learning curve so high !!!
Hold the phone! Even though HASS starts now, my alarm panel group is missing. Excerpts from the log:
16-10-05 00:19:18 homeassistant.loader: Unable to find component alarm_panel
16-10-05 00:19:43 homeassistant.core: Bus:Handling <Event state_changed[L]: new_state=<state group.alarm=unknown; order=14
Surely I need to tell HASS somewhere that the platform envisalink needs to be loaded? Even though it is not required in the alarm_panel.yaml, do I still need envisalink: in the configuration.yaml?
Is there a way for me to keep track of development with this? Keeping track of who disarmed the system is the last (I think…) bit that I’m looking for that’ll let me move my Envisalink from my Vera to HA.