DSC Alarm integration

[mezz64]

Just checked the behavior this morning with all browser tabs closed and no external services accessing the api and I still am not able to get consistent behavior. I went through about 10 restarts and everything loaded correctly about 25% of the time. The other times it was either just the binary sensors failing or all the mqtt sensors failing to load.

Just to make sure something else wasn’t causing the issue I disabled the envisalink component and repeated the 10 restarts. All sensors loaded completely every time without issue.

I’d be happy to test any ideas you have in correcting things since the problem seems easily producible on my setup.

[ih8gates (Scott Reston)]

Thanks, @Cinntax. I’m using the All-in-on installation, so I had to deal with permissions first. To future viewers of this thread:

sudo su -s /bin/bash hass

will switch you to the hass user that owns the files.

Unfortunately, though, I’m not seeing a change to states.sensor.home_alarm_keypad.attributes.exit_delay.

I watched the UI panel that shows the keypad states and I also checked the variable via the template dev tool just to make sure it wasn’t an issue with the UI not responding.

This update also made all of my Forcast.IO sensors disappear, like @mezz64 is seeing.

[Cinntax]

Ok- so just curious- did any of the sensor attributes update for you? Or was the whole thing still reading na or false?

[ih8gates (Scott Reston)]

I didn’t see any of the alarm panel sensors update.

[Cinntax]

Dang- yeah i’m out of ideas for now. It’s just so random. I did learn quite a bit about the setup process while accounting for the asyncio changes, so I’ll take another look.

[xbmcnut]

Could someone kindly post their alarm_panel.yaml file? Mine works when integrated into the main configuration file but not when standalone.

Correct formatting for alarm_panel.yaml

Can someone assist with the correct formatting for a dedicated yaml file for my alarm panel? I’m using Envisalink 3 with DSC and it works fine when integrated into the main configuration.yaml. In the interest of keeping things tidy though, I’ve split up my files as many have done but when I include the alarm-panel.yaml file, HASS dies completely. No SSH access, no SMB, no webpage. I’ve just had to use Parted Magic to remove the alarm_panel.yaml file and edit the configuration.yaml to remove the …

[Cinntax]

I have a pretty good idea of what’s going on. It’s how I’m loading the sensors- however I’m not the only component Doing it this way (Ecobee/Vera do it this way too). So I may have to consult with Paulus on how he wants a resolution to look like.

[ih8gates (Scott Reston)]

Since the Envisalink will only allow one TPI subscriber, I have only been using it a bit as I port from my Vera setup. So, I’m wondering, @Cinntax, does the HA implementation of Envisalink report the user number of the last person to disarm it? I’m using that in Vera to let me know when my kids get home from school while I’m not there. Thanks!

[Cinntax]

Okay- with Paulus’ help- we finally got to the bottom of this issue- I’ll be doing a pull request to fix it later tonight. If you want to test it too- i have it checked in here:

Cinntax/home-assistant

The issue was pretty minute- so I’m glad Paulus came in with the assist!

[mezz64]

Thanks for tracking this down. I tested the change over 10 restarts and everything loads up correctly every time.

[Cinntax]

sweet! Pull request going in now.

[Cinntax]

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.

[dcshoes23]

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!

[Cinntax]

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…

[RobDYI]

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>

[dcshoes23]

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.

[Cinntax]

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.

[RobDYI]

Ok thanks. I found that deleting /home/hass/.homeassistant/deps directory help the envisalink connect to HA.

[carlostico]

Where does Envisalink config has to go ???
alarm_control_panel.yaml ???
alarm_panel.yaml ???

I am kind of lost…

[Cinntax]

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'