Thanks a lot its working great now that “if” did the trick… again thanks I now know I need to set and trying to learn template
It might not be hard to code this to be able to set up the user code names in config file save some work with templates. Will look into it
Has anyone notice that DSC alarm state is not showing up on sensor.home_alarm_keypad but is on alarm_control_panel.home_alarm? I noticed it on 40.0 upgrade but downgraded to 38.0 didn’t resolve it.
I use sensor.home_alarm_keypad to trigger my automations. I haven’t had any problem with it. I trigger automations on when it enters exit delay, when it’s armed and when it’s disarmed. All are working for me. I’m at .39.3
Ok thanks. I determined that because I didn’t shut down HA fully it didn’t close the evisalink connection properly. This caused the envisalink to continually disconnect and HA try to reconnect and hence the senor states where not updated. The disarmed state I saw must have been a previous state recorded when shut down as I think its a new feature in 40.0.
Hi - having a problem with the Envisalink component I can’t quite figure out. Mine is connected to a DSC panel. My problem is that if a zone changes just prior to a scheduled zonedump (which happens every zonedump_interval = 30 seconds) then at the time of the zonedump I get stale data. Example:
Let’s say the zonedump happens at 00,30,60, etc.
At t=22 I open a door, zone is reported open.
At t=24 I close the door, zone is reported closed.
At t=30, zonedump occurs and door is reported open again!
At t=60, zonedump occurs again and door properly reports closed
This only happens if the zonedump occurs within about 15 seconds of when I close the door. As a temporary workaround I can set zonedump_interval to a large number, but there is always the risk that a zone changes state just before the zonedump…and if so it could be stuck there until the next zonedump (unless the zone changes state again).
I’m running 0.40.1. Here is my config for the envisalink:
envisalink:
host: 192.168.1.31
panel_type: DSC
user_name: user
password: user
code: [code]
port: 4025
evl_version: 3
keepalive_interval: 60
zonedump_interval: 30
panic_type: Police
zones:
10:
name: 'Back Door'
type: 'opening'
11:
name: 'Front Door'
type: 'opening'
partitions:
1:
name: 'Home Alarm'
Here is a typical log output…the first 2 lines are me opening then closing the door, then at 20:34:58 a zonedump occurs and the door is reported as open again (until the next zonedump).
Mar 20 20:34:50 hassbian hass[5005]: 17-03-20 20:34:50 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: old_state=<state binary_sensor.front_door=off; device_class=opening, last_tripped_time=35, friendly_name=Front Door @ 2017-03-20T20:29:34.659613-04:00>, entity_id=binary_sensor.front_door, new_state=<state binary_sensor.front_door=on; device_class=opening, last_tripped_time=35, friendly_name=Front Door @ 2017-03-20T20:34:50.701690-04:00>>
Mar 20 20:34:51 hassbian hass[5005]: 17-03-20 20:34:51 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: old_state=<state binary_sensor.front_door=on; device_class=opening, last_tripped_time=35, friendly_name=Front Door @ 2017-03-20T20:34:50.701690-04:00>, entity_id=binary_sensor.front_door, new_state=<state binary_sensor.front_door=off; device_class=opening, last_tripped_time=35, friendly_name=Front Door @ 2017-03-20T20:34:51.693481-04:00>>
Mar 20 20:34:58 hassbian hass[5005]: 17-03-20 20:34:58 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: old_state=<state binary_sensor.front_door=off; device_class=opening, last_tripped_time=35, friendly_name=Front Door @ 2017-03-20T20:34:51.693481-04:00>, entity_id=binary_sensor.front_door, new_state=<state binary_sensor.front_door=on; device_class=opening, last_tripped_time=15, friendly_name=Front Door @ 2017-03-20T20:34:58.101180-04:00>>I’ll check later- but I think I know what’s going on. The envisalink library will interpret the zone timer data to infer the state as well as any events. It does this because, at least with Honeywell panels, we don’t necessarily have all the state events at initial startup. It’s also possible we missed an event, so we’re just using the zone timer data as additional info to synchronize with. I also noticed that the timer values for an open zone were never zero, but rather some small value. So I do think there is a possibility here that I’m interpreting a relatively small timer value as open, as you state.
I also know that I put in a feature to completely disable the timer dumps- I don’t recall off the top of my head what that was. I admit that it’s not totally necessary on the dsc panels because we get events for all zones upon initial hass startup.
Thanks very much for the great work on this! It’s been able to turn my honeywell system into something really useful! Posted this issue on github, but figure I post here too. I’ve been having a random issue that really reduces the reliability and robustness of the system. Around 30 times a day (the frequency is very random, sometimes happens every few minutes, sometimes hours) home assistant cannot read any state changes from envisalink nor can it call the arm or disarm services. It will become unresponsive for a few minutes, envisalink will close the tpi connection, connection is restored and functionality is resumed until it occurs again. During this period, I can still use the envisalink through the eyezon cloud service, which means it’s not losing network connectivity. The error is reported in the logs as below:
Home Assistant release (hass --version): 0.40.2
Python release (python3 --version): Python 3.5.2
17-03-29 21:53:12 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting…
17-03-29 21:53:18 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback _SelectorSocketTransport._read_ready()
Traceback (most recent call last):
File “/usr/lib/python3.5/asyncio/events.py”, line 125, in _run
self._callback(*self._args)
File “/usr/lib/python3.5/asyncio/selector_events.py”, line 669, in _read_ready
self._protocol.data_received(data)
File “/home/mbr/.homeassistant/deps/pyenvisalink/envisalink_base_client.py”, line 179, in data_received
callbackFunc(result)
File “/usr/local/lib/python3.5/dist-packages/homeassistant/components/envisalink.py”, line 127, in connection_success_callback
sync_connect.set_result(True)
File “/usr/lib/python3.5/asyncio/futures.py”, line 329, in set_result
raise InvalidStateError(’{}: {!r}’.format(self._state, self))
asyncio.futures.InvalidStateError: FINISHED:
Much appreciated if anyone can provide some insight to this or suggestions on a fix!
I’ve integrated my EVL3 into my HASS instance and am able to use my DSC sensors without issue. Thanks!
I have a PIR accessible from my HASS instance but not part of my DSC alarm panel. I’m looking for a way to use the DSC panel’s chime function to notify me when the PIR detects motion. One of the chime options is a doorbell sound that I’m currently not using for any zones.
Any suggestions on how I could trigger my panels to make the doorbell chime sound when this PIR detects motion in HASS? I’m able to send custom keypresses to the panel, but I’m not aware of any keypress combination that could manually trigger the chime. I could trigger an alarm (policy, fire. ambulance) but those use the siren, not the panel chime.
Any thoughts much appreciated!
I first did it by connecting a GPIO on a Rpi to a relay to a zone on the DSC panel and made that zone, non-tripping and chime on as you mentioned. I now think if you have a PGM not used on your panel you could send the key press to activate that PGM. (*71 for PGM1) I have my PGM hooked up to my garage so I know it chimes when HA activates it.
Ok I was able to check this further, and yes I am indeed interpreting any result under 30 seconds as still open- exactly as you report.
I also was able to confirm the ability to turn off the zone timer dumps. Simply set your zone timer dump interval to 0, and that will stop them from running altogether.
Hmm very odd- If I were you the next troubleshooting step I’d take is to use your command line and telnet into the evl (you’ll have to shut down hass while you do this- only 1 tpi connection is allowed at a time). I’d be curious if the evl drops the telnet connection too every so often. So if you telnet into it, and let it run for 30 minutes or so, to see if that dies too.
Thanks for the suggestion, I tested the telnet connection for over 12h now and not a single drop in connection. I also tried deleting my deps folder and restarted hass to have everything reinstall, but no luck in solving the issue.
There was 1 other person that looks to have a similar issue, but much less frequent.
Hi, I treid to get HA and EnviaLink (4) to work yesterday but were getting connection issues. I Found this thread and its my understanding that Envisalink only allows for 1 TPI User, so currently my Vera Edge is using the DSC Panel plugin and this now causes connection issues with HA + DSC integration. I read something in this thread about some proxy etc to resolve this, has there been any work considers to do this or if there is another way for me?
Can you connect HA to Vera with the component so that your don’t need envisalink to have two connections? Another possible solution is to not use Vera Edge and move everything to HA.
I was also having issues with getting ‘phantom’ zone status changes on my DSC system. Turned out to be related to the zonedump_interval as described previously. I ran into an issue when trying to disable them, however. Based on this:
Ok I was able to check this further, and yes I am indeed interpreting any result under 30 seconds as still open- exactly as you report.
I also was able to confirm the ability to turn off the zone timer dumps. Simply set your zone timer dump interval to 0, and that will stop them from running altogether.
I tried setting zonedump_interval: 0 however I got an error that the minimum value is 15.
Looks like based on the code (https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/envisalink.py) that this is indeed the case:
vol.Optional(CONF_ZONEDUMP_INTERVAL,
default=DEFAULT_ZONEDUMP_INTERVAL):
vol.All(vol.Coerce(int), vol.Range(min=15)),
For now I set zonedump_interval: 31536000 (365 days), but it would be much cleaner if the zonedump was just disabled outright.
Cinntax, could this be addressed in an update?
EDIT: Oh forgot to mention I LOVE the Envisalink integration, thank you so much for all your hard work!
Hi Tim- certainly. I’m overdue for a release- I have a new pyenvisalink version to reference also- so I’ll get a pull request staged up over the next day or so. Thanks!!
Okay, I have just submitted a PR to remove the “minimum 15 second” requirement from the zonedump configuration parameter. I’ll let you know when it’s been accepted, and you can test in the dev branch.
FYI- my PR for bumping up the pyenvisalink version, as well as removing the 15 second minimum from the zonedump interval parameter has been accepted. You’re free to give it a shot from the dev branch! I gave my end a quick test or 2.
Just a note for anyone else besides me searching for this thread: DSC panels can also be integrated into HA using the Alarm Decoder module. ad2usb works great with HA and doesn’t use on any external servers for communication.