I don’t know what this means. Open your states dev tool. Look at your keypad sensor (mine is sensor.home_alarm_keypad, but it’ll depend on what you named the partition). Look at the value of last_disarmed_by_user. I use this as the index for the array. You’ll need to adjust the array in HASS to match what’s in your alarm. Or just do a bunch of if/else statements to account for the numbers you care about.
I notice last_armed_by_user never have in anything like the last_disarmed_by_user
OK. So you’d need to have a 40 element array. So you probably want to use some math or some if/then statements.
That’s probably because you arm your alarm by pressing a button rather than entering a code. On my DSC, I can press a stay or away button to arm. But I can also key in my code. If I key in my code, last_armed_by_user is valued.
no a pro in template have any example I can see and modify to fit mines?
{% if states.sensor.home_alarm_keypad.attributes.last_disarmed_by_user -%}
{% if states.sensor.home_alarm_keypad.attributes.last_disarmed_by_user == 1 -%}Scott
{%- elif states.sensor.home_alarm_keypad.attributes.last_disarmed_by_user == 2 -%}Someone Else
{%- elif states.sensor.home_alarm_keypad.attributes.last_disarmed_by_user == 40 -%}Someone Other Person
{% endif %}
{%- else %}Someone{% endif %} disarmed the alarm
Not right now. But really - you’ve got the raw materials to work this out for yourself. Use the template dev tool to experiment.
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.