Envisalink identify arming/disarming user

I’m planning to leave the solution i’m using today and integrate dsc+envisalink to Homeassistant instead.
But a function i have today is that i can identify which user who arming and disarming the alarm with the keypad
Is this possible or can i only have one user with pin code?

You can ID the disarming code.

Youll set up one (or more) codes to arm/disarm through HA but you absolutely can get the user who manually disarmed at a keypad.

Its also incredibly fast

Ok, thats great to hear Nathan
Is this id/user/pin-code configuration documented somewhere?
I’ll guess this has to be added in the configuration.yaml

Edit:
I’ll guess the user is identified from the dsc id database?
in my ex. case user 01 → 05
So then i will se these users in attibute below?
state.attributes.last_changed_by_user

1 Like

I know this thread is old, but I’m trying to figure out how to do exactly this. DSC alarm panel, Envisalink integration into HA, and I need to know which DSC user punched in their code at the keypad.

the changed_by attribute sounds (based on name) like what I want, but it is always null, so I don’t know if I am doing something wrong or what.

For what it’s worth, I have been able to verify, using debug logging, that the alarm system is sending the user data:

2024-01-07 07:14:48.219 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] ----------------------------------------
2024-01-07 07:14:48.219 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] RX < 750100018E
2024-01-07 07:14:48.219 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] calling handler: handle_partition_state_change for code: 750 with data: 10001
2024-01-07 07:14:48.219 DEBUG (MainThread) [pyenvisalink.dsc_client] (partition 1) state has updated: {"alarm": false, "armed_stay": false, "armed_away": false, "armed_zero_entry_delay": false, "exit_delay": false, "entry_delay": false, "alpha": "Disarmed"}
2024-01-07 07:14:48.220 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] Invoking callback: callback_partition_state_change
2024-01-07 07:14:48.220 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] ----------------------------------------

In this case the data is 10001, where 001 is the user who disarmed the system. I note that the DSC also sends command 655, “Partition Disarmed”, which only contains the partition that was disarmed, but command 750 is the one of interest here, as it does provide the user.

it then invokes callback:
callback_partition_state_change,
which I see from looking at the source code is the function:
async_partition_updated_callback
(envisalink/__init__.py, line 199), which in turn calls:
async_dispatcher_send(hass, SIGNAL_PARTITION_UPDATE, data)
(line 183), where SIGNAL_PARTITION_UPDATE is defined on line 54 as "envisalink.partition_updated"
However, that’s as far as I get, as I can’t find where the partition_updated function is defined.

I do have a theory as to why changed_by is always null though: When the system is disarmed, both command 750 and 655 are sent - in that order. When command 750 comes through, perhaps changed_by is set, but then, moments later, when command 655 without a user comes through, it is set back to null? If so, I wonder if I could trigger on that attribute changing and somehow save the data elsewhere if, and only if, it is not null…

EDIT: Nope, that doesn’t seem to work. I can set up an automation triggered by the changed_by attribute of the alarm control panel changing, but said automation doesn’t appear to ever be triggered. So my next theory is that the callback_zone_state_change is simply ignoring the user sent by the 750 command.

EDIT 2: Some creative googling led me to the sensor.<alarm_system_name>_keypad entity, rather than the alarm_control_panel entity. As it turns out, the “sensor” entity has a last_disarmed_by attribute that does, in fact, contain the last user to disarm the system (and also, a similar last_armed_by_user attribute). So I should be able to simply check/use that attribute to do things dependent on the user.