DSC Alarm integration

Seems all was not well. As mentioned above, HASS started by removing - platform but I was a dumb ass and did not even check to see if the group loaded…it did not. Upon further investigation today, I’ve found that my alarm_panel.yaml will only be loaded it it is called alarm_control_panel.yaml and I include the - platform: envisalink at the top.

    - platform: envisalink
      host: 10.0.1.221
      panel_type: DSC
      user_name: xxxx
      password: xxxx

But now that HASS is at least loading envisalink from a dedicated file, it is stalling with the following errors under 0.29.6.

    16-10-05 13:54:24 homeassistant.loader: Loaded alarm_control_panel.envisalink from homeassistant.components.alarm_control_panel.envisalink
    16-10-05 13:54:24 homeassistant.loader: Loaded envisalink from homeassistant.components.envisalink
    16-10-05 13:54:24 homeassistant.bootstrap: Error during setup of component envisalink
    Traceback (most recent call last):
      File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/bootstrap.py", line 102, in _setup_component
        result = component.setup(hass, config)
      File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/envisalink.py", line 91, in setup
        _host = config.get(CONF_EVL_HOST)
    AttributeError: 'NoneType' object has no attribute 'get'
    16-10-05 13:54:24 homeassistant.bootstrap: Unable to prepare setup for platform alarm_control_panel.envisalink because dependency envisalink could not be initialized

Anyone else seen this? For now, I have dropped the envisalink platform back into the configuration.yaml and everything is working again.

You probably are aware of this and its probably not the issue but yaml is sensitive to spacing. So your platform entry should be:

- platform: envisalink
    host: 10.0.1.221
    panel_type: DSC
    user_name: xxxx
    password: xxxx

Not when used in a dedicated file? Used all the example files on Github for guidance.

Not sure. However I suspect the yaml requirements for spacing are needed whenever using yaml. Worth trying with the spaces anyway?

I’ve just updated to 30.1 and running great, certainly no longer seeing issues when restarting.
I am trying to have a go at adding an ‘alarm_keypress’ service, which would call the keypresses_to_partition command from pyenvisalink.

However, the alarm_control_panel class doesn’t have an alarm_keypress method.
What is the guidelines with HA - do we register a service in the Envisalink class directly, or request another generic method added to the alarm_control_panel class.

(Forgive my terminology, haven’t done any Python or Home Assistant development before)

Forgot to mention the use case of wanting to be able to send custom keypresses to turn the programmable outputs of the alarm on or off

Anyone knows what is the following error related to ?

Oct 09 15:01:08 raspberrypi hass[1521]: DEBUG:pyenvisalink.envisalink_base_client:KeyError: ‘handler’
Oct 09 15:01:11 raspberrypi hass[1521]: DEBUG:pyenvisalink.envisalink_base_client:KeyError: ‘handler’
Oct 09 15:02:40 raspberrypi hass[1521]: DEBUG:pyenvisalink.envisalink_base_client:KeyError: ‘handler’
Oct 09 15:02:42 raspberrypi hass[1521]: DEBUG:pyenvisalink.envisalink_base_client:KeyError: ‘handler’

Finally upgraded from .23 to .30 and impressed with the progress. Many thanks to @Cinntax and others :smile:

Hmm- yeah not entirely sure, to be honest. I think you may need to actually define a new type of service for the alarm_control_panel component- this way other types of alarms can implement this too. I think you need to define that in components/alarm_control_panel/init.py

If I were you, I’d just look at how the existing services are defined, and follow suit.

Don’t worry about that- what’s happening is- the dsc passes back more information than what is relevant to us in hass (well at least right now anyway). So this is just saying that the dsc sent us something we don’t recognize, and we ignored it.

Thanks I’ll try that out - just didn’t want to define a new type of service only to find the alarm_control_panel class is locked down and difficult to get changed!

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:

  1. In alarm state, add a new variable to the partition status name/value collection.

  2. 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.

  3. 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.