Hey guys. I downloaded the master branch and put the files in config/home-assistant/custom_components directly. HA never fully launches and I just get this in my log. I’m running 0.76 in docker. I’m not sure what else to do.
2018-08-23 18:19:02 INFO (MainThread) [homeassistant.loader] Loaded elkm1 from custom_components.elkm1
2018-08-23 18:19:02 WARNING (MainThread) [homeassistant.loader] You are using a custom component for elkm1 which has not been tested by Home Assistant.
2018-08-23 18:19:03 INFO (SyncWorker_4) [homeassistant.util.package] Attempting install of elkm1==0.4.7
2018-08-23 18:19:12 WARNING (MainThread) [homeassistant.setup] Setup of config is taking over 10 seconds.
No I’ve tried launched it a bunch of times. This is the first time I’ve tried so it’s never worked before.
This is all I have in my config for elk. Real IP omitted.
If you want to share a full log file I can take a look through that. If you DM me I can DM you back with a link to a private file drop. Feel free to comment out IP addresses. Or leave them
In case anyone is looking for a way to determine what zone triggered the alarm, I’ve created the following automation to place it in an input_text field
- id: alarm_triggered_zone
alias: "Record zone that triggered alarm"
trigger:
platform: state
entity_id:
- sensor.elkm1_zone_001
- sensor.elkm1_zone_002
- sensor.elkm1_zone_003
- sensor.elkm1_zone_004
- sensor.elkm1_zone_005
- sensor.elkm1_zone_006
- sensor.elkm1_zone_007
- sensor.elkm1_zone_008
- sensor.elkm1_zone_009
- sensor.elkm1_zone_010
- sensor.elkm1_zone_011
- sensor.elkm1_zone_012
from: 'Normal'
to: 'Violated'
condition:
condition: or
conditions:
- condition: state
entity_id: alarm_control_panel.elkm1_area_001
state: 'armed_away'
- condition: state
entity_id: alarm_control_panel.elkm1_area_001
state: 'armed_home'
- condition: state
entity_id: alarm_control_panel.elkm1_area_001
state: 'armed_night'
action:
service: input_text.set_value
data_template:
entity_id: input_text.alarm_triggered_by
value: '{{ trigger.to_state.attributes.friendly_name }}'
Finally, one more to clean-up the field on a new arming:
- id: alarm_clear_last_triggered_zone
alias: "Alarm - Clear last triggered zone on rearm"
hide_entity: True
trigger:
- platform: state
entity_id: alarm_control_panel.elkm1_area_001
to: 'armed_away'
- platform: state
entity_id: alarm_control_panel.elkm1_area_001
to: 'armed_home'
- platform: state
entity_id: alarm_control_panel.elkm1_area_001
to: 'armed_night'
action:
service: input_text.set_value
data_template:
entity_id: input_text.alarm_triggered_by
value: 'None'
Thanks for sharing this code; however I wonder if it might be possible if @gwww and @BioSehnsucht might actually implement the protocol handler which reports the alarm status
While considering this, could you also expose the System Trouble Status ‘SS’ messages. I have this week had a battery go flat on a smoke sensor and the alarm panel communications with HA went into an unknow state; exposing this information would really help, but i understand that it might break some stuff as you possibly may present status details for each zone, etc and for each area.
I have some code in my git repo where i implemented this in a JS library for Iriduim a year or two back if it is any value,
The main benefit of this, would be to assist with also identifying issues which might be due to a number of zones been breached; and also insights to scenarios like low battery faults on wireless smoke sensors as an example
Glad to implement it. The decoder is there. It’s one line of code in the lib and probably one line in the HA component.
Help me understand. The AZ message sends an array of zone definitions. With a non-zero being a zone definition (burglar, fire, etc) and meaning that is the zone that triggered the alarm.
It seems like I should just store the a boolean. Something such as zone_triggered_alarm. Does that make sense?
What actaully happens in the ELK, is that once the alarm is triggered, the response changes to define why the alarm has triggered and what zone caused it, then until the alarm is acknowledged by keying in the unarm code, if the burglar for example continues to move around the premises, then each additional zone that is tripped is no appended to this response code; thus returning an array of all the zones which have been tripped from the time of the alarm to the acknowledgement.
When the disarm code is presented a second time, the alarm trip is cleared and area then disarmed.
It didn’t really answer the question I had on my mind What I was getting at is that the message seems odd. I believe that it the AZ message sending an array of ‘0’ or ‘1’ would have made more sense.
What I have implemented is that if the value is zero then I set a zone attribute to False. If it is non-zero then I set it to True. The attribute is called triggered_alarm.
It is implemented in what will be the 0.7.3 elkm1-lib.
The other news… I’ve been doing a quite a bit of cleanup and refactoring of the HA component. That has also meant that I’ve been modifying the elkm1-lib (it has been renamed due to a testing conflict. It was called just elkm1). The mods to elkm1-lib are breaking changes, meaning that the latest HA component code is also required. You can find the newest HA code on my repo on the refactor branch. (https://github.com/gwww/ha-elkm1/tree/refactor).
What is important to know is that I’ve been doing lots of work preparing to get this into hass proper. That means there are breaking changes. Hopefully the last.
The primary change is to device_state_attributes. All the names were changed to match their attribute name. So for example the zone attribute that was called Logical status is now called logical_status. This will break automations (well, it will if you use them).
The reason to do this was to stay more consistent with the overall component design in hass. Yah, I could have left them, but I’d prefer to make the breaking changes now rather than when this gets into hass.
I have also removed a couple of attributes. Happy to discuss whether they should be put back, different ones added, etc. The goal is to not only have a really clean code base but to also make automations “easy” (for whatever definition of easy works). I’m flex but want to have the design discussions to make sure we make the best decisions for good design, functional, easy to use, etc.
So, if you’d like to try the new code I’d be happy to hear how it goes.
FYI, the AZ/SS functionality is not yet on the master branch. @gwww has been putting in a lot of work to refactor code for eventual HASS inclusion as well as general improvements and I haven’t had a chance yet to test it (though having eyeballed it it should work other than some breaking changes requiring potential config updates) and apply it to master, and that new code is tied in with that.
There’s some pretty big changes in the work he’s been doing, so for the moment I’ve put it in a new branch refactor, if anyone wants a peek at the future and/or really needs AZ/SS functionality now. This branch is still evolving. There will be breaking changes, but hopefully for the last time. Other than AZ/SS there’s no reason to “upgrade” from the master branch yet, so if you don’t need/want it, stick to master. You can also go straight to the source and look at his refactor branch at his fork of the Github repository.
For now I am leaving master as-is except for any minor bug fixes until the refactoring is done-ish and tested out with more systems (at least tested on the one we have at work in addition to Gwww’s), as there are some functionalities he can’t test that we have and vice versa.
This thread is approaching 500 posts. Maybe it is time to get a sub-category under “Third party integrations” for discussions about integrating home assistant with the Elk M1?
I think what he means is that Elk’s functionality doesn’t change much over time. Once 90% of it has been implemented, there probably won’t be much development discussion anymore.
Right, I tend to agree; this driver is already pretty mature; and has has really no issues since moving to the revisions with the new library from @gwww
With the exceptions of small PR’s and Feature requests, once its installed and running it behaves very nicely; and brings a pretty old but stable platform a very real new lease of life values.
I maintain(ed) the current Elk plugin for Indigo (https://github.com/billchurch/indigo-elk-m1-plugin) but I’m migrating away from that to HA. Happy to lend a hand where needed, is there a todo or something somewhere for this? What help is needed?
Not much help needed with the code. Most of the changes only require a few minutes to put in.
Help is mostly needed in testing now.
The other area is that there are we are deciding on the “tuning” the last couple of features. Figuring out the way we want to go forward with those features is the part that requires to have discussion and align on a single path.
The one feature we are discussing is around what the correct attributes are on the devices we create in hass. Take a look at the device_state_attributes methods. Trying to get to the minimal, but right list so that automations are “easy” (for whatever definition we decide on for easy) to implement.
The other feature we are talking about is around the “hidden” flag on the hass side of things. Right now we can configure a device to be hidden and we also try to be smart and automatically hide devices if we perceive they are not in use. Hass has a new frontend called lovelace. Lovelace is not the default interface yet but it will be. Lovelace does not support hidden.
So, as usual, the hardest thing about building anything is figuring what the right thing is!
What I was getting at is that the message seems odd. I believe that it the AZ message sending an array of ‘0’ or ‘1’ would have made more sense.