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.
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.
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)
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!
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…
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)
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.
