What’s the format of the last tripped time ? Is it number of seconds ?
That alarm_control_panel is nasty to add a new type of service in - it is hardcoded to send ‘code’ to any handlers. well, unless I just continue using ‘code’ instead of defining a new attribute ‘keypress’, but that doesn’t seem very nice
I probably need to restructure that unless just register an Envisalink only service…
EDIT: I’ve got it up and running with these changes basically keeping in style with the other methods. https://github.com/home-assistant/home-assistant/compare/dev...jnimmo:dev
Maybe I’ll have a look at the last armed/disarmed by user too before trying to do an update!
I’d be really excited to get the last user info! +1
I’ll add it to pyenvisalink tonight, and then will see how to integrate it into HA envisalink
Is an attribute with the user (0001 - 0042) on the alarm object sufficient?
I actually don’t think you’ll have to do anything special in HA for the “last user” functionality. I was thinking of just adding a new property to the partition’s status name/value collection. So it’d go alongside chime/ac_present/trouble/etc. Then, the sensor will just pick that up automatically as a new value to track.
So without looking too closely, i think you’ll need the following in pyenvisalink:
-
In alarm state, add a new variable to the partition status name/value collection.
-
For now, you can modify the handle_partition_state_change to capture the extra bytes if the command is 700 or 750 (kind of like i am for 652). I’m not terribly thrilled with this, but I think the best way to clean this up long term would be to allow us to explicitly define both a handler and a seperate callback. Right now it’s just done by naming convention. Ideally, in this case here, we’d have a separate handler to handle the different behavior, but still call the normal partition_update callback.
-
in the dsc_envisalinkdefs, would need to map the command 700 and 750
If you’re interested in testing the change just need to add this block of code to pyenvisalink\dsc_client.py - just before the last ‘return partitionNumber’ in the handle_partition_state_change method.
(It will only record it for the disarms unless you edit other files)
'''Log the user who last armed or disarmed the alarm'''
if code in ['700','750']:
lastChangedByUser = {'last_changed_by_user': int(data[1:5])}
self._alarmPanel.alarm_state['partition'][partitionNumber]['status'].update(lastChangedByUser)I’ll see if I can give this a trial run. Busy day today, so might not be till tonight or tomorrow AM, but I’ll report back either way. Thanks.
EDIT: Shoot. I’m still running 0.29.6 b/c I heard about 29.7 issues. I’ll need to update to .30 first.
Just checking if the last tripped time can be made user friendly? Is this a customization on HASS ?
Thanks no rush!
At the moment it adds an attribute to the alarm control panel ‘last changed by user’ 1-42
This will be updated when a user arms or disarms the alarm
Was wondering if we should be setting it back to blank if it is armed/disarmed by the master code?
EDIT: Master code seems to show up as user 40 on mine, so probably don’t need to worry about resetting to blank after all.
I upddated to 30.2 this morning. Exit delay and entry delay are looking good!
UPDATED: I’d posted that the last_changed wasn’t working. I hadn’t let a full exit delay complete! Looks to be working - I’m seeing last_changed_by_user now. I’ll give it some extra testing this morning.
Also - if you want to fix it while you’re committing code, there are 3 tabs on an empty line at line 124 (in the file I have). Between handle_command_response_error and handle_poll_response.
I noticed that alarm_control_panel.home_alarm has a changed_by attribute that’s null for me.
Does that mean that the alarm component has an attribute where last_changed_by_user should be presented?
EDIT: home_alarm is created by my partition 1 “Home Alarm”
I’m only seeing a change in last_changed_by_user when the alarm is disarmed, not when it’s armed.
On a fresh restart of HA, if I arm the alarm, there’s no last_changed_by_user attribute until I disarm. In fact, if I arm the alarm and then key in a code during the exit delay, I don’t see a last_changed_by_user until I’ve gone through a full arm / disarm cycle.
This could be an issue with how I pasted-in the code you posted. I’ve got:
def handle_partition_state_change(self, code, data):
"""Handle when the envisalink sends us a partition change."""
"""Event 650-674, 652 is an exception, because 2 bytes are passed for partition and zone type."""
if code == '652':
parse = re.match('^[0-9]{2}$', data)
if parse:
partitionNumber = int(data[0])
self._alarmPanel.alarm_state['partition'][partitionNumber]['status'].update(evl_ArmModes[data[1]]['status'])
_LOGGER.debug(str.format("(partition {0}) state has updated: {1}", partitionNumber, json.dumps(evl_ArmModes[data[1]]['status'])))
return partitionNumber
else:
_LOGGER.error("Invalid data has been passed when arming the alarm.")
else:
parse = re.match('^[0-9]+$', data)
if parse:
partitionNumber = int(data[0])
self._alarmPanel.alarm_state['partition'][partitionNumber]['status'].update(evl_ResponseTypes[code]['status'])
_LOGGER.debug(str.format("(partition {0}) state has updated: {1}", partitionNumber, json.dumps(evl_ResponseTypes[code]['status'])))
if code in ['700','750']:
lastChangedByUser = {'last_changed_by_user': int(data[1:5])}
self._alarmPanel.alarm_state['partition'][partitionNumber]['status'].update(lastChangedByUser)
return partitionNumber
else:
_LOGGER.error("Invalid data has been passed in the parition update.")
For anyone that’s interested, here’s an automation that’ll notify you when someone disarms the alarm, with their name.
- alias: Alarm Disarmed trigger: - platform: state entity_id: sensor.home_alarm_keypad state: 'Disarmed' condition: condition: numeric_state entity_id: sensor.home_alarm_keypad value_template: '{{ state.attributes.last_changed_by_user }}' above: 1 # filter myself out action: - service: notify.notify data: title: "Alarm" data: priority: 0 data_template: message: > {% if states.sensor.home_alarm_keypad.attributes.last_changed_by_user %}{{ ["Scott","Wife","Son","Daughter"][states.sensor.home_alarm_keypad.attributes.last_changed_by_user - 1] }}{% else %}Someone{% endif %} disarmed the alarm
Nice thanks for testing!
Yeah spotted a few issues with tabs thanks to GitHub text editor will get those sorted!
We’ve now split it into last_armed_by_user and last_disarmed_by_user in case gives some more flexibility.
You won’t see the arming event unless you add 700 into the dsc defs file but the full updated code is nearly ready
Re last tripped time I still can’t see where that is inserted in the code but will have another look
Point me to some code if you want me to give it a run.
Thanks for working on this. I’m psyched that I was able to move all of my alarm code over to HA today. Just about done with the old Vera!
This looks like some nice functionality. I’ll try to test it at some point soon. A bit loathed to screw around with my set up at the moment as I’ve got it working well thanks to Cinntax.
Great stuff! I’ve just accepted jnimmo’s pull request for pyenvisalink. Are we ready for a release then? If so, i’ll release pyenvisalink 1.8, and you’ll have to update in your hass commit.
Yes that’s correct- it’s number of seconds, but hte envisalink device does “time out” after a given period of time, so it doesn’t go on forever.
@Cinntax: alarm_control_panel/envisalink.py needed a couple of fixes: https://github.com/srirams/home-assistant/commit/2f8deb70cb5f3621a69b6b9acb72f8e29123650c (DSC doesn’t need a code to arm, so I’ve left it as is, but you may need to change it for Honeywell. Also, if you do use a code to arm a DSC system it arms in a different mode I think…)
Great work!
@sriram I’ve got a pull request open at the moment, do you want me to see if I can integrate those changes?
It is up to how the DSC alarm is setup whether a code is required though isn’t it - I think that is a programmable option whether it can be armed without a code?