ELK M1 Interface

Third party integrations
505

Good day folks!

There have been quite a number of changes made over the last couple of weeks. I feel like we are close to integrating this into hass proper. To do that we need to make sure that this code is well tested.

On the elkm1-lib side, heartbeat was added to detect dead connection to the Elk. The IC, SS, and, AZ are now supported. There is also a 30 second timeout timer when connecting to the Elk (there used to be a system default timeout, which in my experience was around 2 minutes).

On the hass side, there was a major cleanup/refactor to simplify the code and centralize some of the logic. Functionality wise support for new arming modes was added. The attributes for a device was refactored – names no longer have spaces in them (this will mean automations will have to be refactored to the new names). If you think that additional attributes are missing pleas post. Autohiding of elements was removed. You can still hide elements through the configuration. Speaking of the config, you can when specifying the list of elements (include/exclude/show/hide) you can do a yaml list or a comma separated list. For example the following would be valid:

zone:
  - include:
    - 1, 3-10, 19
    - 38-42

Any integer in the above can be a valid integer in the range of 1 to max number of the element (e.g.: 208 for zones). An integer can also be written using the X10 housecode format, so a3 - b12. Not terribly useful except for lighting that uses that “number” scheme.

You can see all the changes the elkm1-lib here and here. The version as of this writing is 0.7.7.

You can see all the changes to the hass code here.

Over to you folks now. Please test the heck out of it! Particularly the heartbeat, IC, SS, and AZ stuff.

506

Does the roadmap include more of the Elk output features? I still use my ISY994i to control a few automations that have screen and voice outputs. I’d love to migrated these to native HA.

  • Display Text On LCD Screen (dm)
    My Elk keypads display Trash Day on Monday’s until the gate where the trash cans are has been opened, indicating the trash cans are taken to the curb.

  • System Word Messages (sw/sp)
    If one of my gates is left open for more than 60-sec, the internal Elk speakers/keypads announce via voice “Warning gate left open” every 5-minutes until they are closed.

  • Zone Bypass Request (zb)
    Every Thursday, the gates are bypassed during certain hours so the pool cleaner can come

  • Request Change User Code (cu)
    The housekeeper’s code is only enabled when they are scheduled

  • Zone Trigger (zt)
    This allows me to expand the system to include zones not native to the Elk (Insteon sensors) and trigger the virtual zone numbers.

  • Keypad KeyChange Update (KC/kf)
    Nothing yet for these but it would be cool to be able to use the Elk keypad as an interface to HA. This would also allow changes to chime

507

They can be on the roadmap :slight_smile:

For outputs, are you thinking that the time parameter should be added?

For the others, if you could only pick one, what would that be?

The good news is that most of those message are already supported in the elkm1-lib. They just need to expose a hass service.

How’s the testing on the other features coming along? :wink:

508

Should I be testing the master branch, or the refactor branch?

I’m almost done converting all my home automation stuff from my macOS / Mac Mini to Ubuntu and docker containers on a diskless “NUC” style device. It’s almost all working again :slight_smile:

509

master is basically the old gwww-elkm1-lib branch, but kept stable (no dev work occuring on master like it did on gwww-elkm1-lib). refactor is the new hotness, but you’ll need to be on current version of HASS and there are breaking changes and no guarantee of stability (as it is a dev branch) though we won’t be merging known badness to it. refactor represents where we’re going. Eventually, refactor will be what gets integrated into HASS proper.

As long as you’re on a current version of HASS the refactor branch has no known issues AFAIK ? Other than possibly needing to re-add some attributes to entities that were cleaned up during refactor work.

510

I installed the refactor branch yesterday and so far no major issues. I am very happy about the attribute name change since that was a pain to deal with the spaces when using Node Red to trigger automations.

The only issue I am seeing is that after a restart of home assistant the zones display as state Unknown until they are triggered at least once even if the logical status and physical status are showing the correct values.

Screenshot_2018-09-03_12-49-49

Thanks for all the hard work @gwww and @BioSehnsucht!

511

I don’t see unknown state on restart. Which repo and branch did you pull the code from?

512

I ran the following then copied the files over to my custom_components folder.
git clone https://github.com/BioSehnsucht/ha-elkm1.git --branch refactor

I also removed the elkm1.py file from the root of custom_components since it is not present in the refactor branch.

Do I need to pull a specific version of your lib too or is it linked in the ha-elkm1 component?

I have the following config that I have been running for a few months now:

elkm1:
  host: elk://x.x.x.x:2101
  area:
    exclude: 
      - 2-8
  counter:
    exclude:
      - 1-64
  keypad:
    exclude:
      - 2-16
  output:
    include:
      - 4-6
  task:
    exclude:
      - 1-32
  thermostat:
    exclude:
      - 1-16
  plc:
    exclude:
      - a1-p16
  zone:
    include:
      - 1-2
      - 17-20
      - 193
  user:
    include:
      - 1-2
      - 10
  setting:
    exclude:
      - 1-20

I just redid some tests and after a restart all my zones display “Unknown” but as I walk through the house and trigger doors and motion sensors they change to Violated/Normal correctly after. The ones I don’t trigger remain “Unknown”.

513

Same situation as @mathd. Zones are shown Unknown until a state change. Used the exact same upgrade process, even deleted the elkm1.py file in the root of custom_components. Running HA 0.77.2.

514

No need for a time parameter on the outputs.

If I had to prioritize one, it would be Display Text On LCD Screen (dm).

515

Perhaps try the refactor branch on @Gwww’s repo. His repo is ahead of mine by multiple commits (since I haven’t had a chance to actually look at them yet, and he hadn’t specifically sent a PR or told me I should pull the changes, I hadn’t yet done so in case there were incomplete changes).

1 Like
516

What @BioSehnsucht said – @jshank and @mathd try the refactor branch off my repo. That will also pull the latest elkm1-lib. I just don’t see that on what I’m running so I guessing that the bug occured and got fixed before I noticed.

@jshank – working on the service calls (display text will be my next one). It’s easy to do but harder to do “right”. I’ve been messaging with a number of the hass devs on the way to do this “properly”. I think I now know however waiting for some more feedback. The elkm1-lib support displaying text, speaking words/phrases – Just need to get it into the hass code.

517

Ok, I did the following and still get the same results:

  • git clone https://github.com/gwww/ha-elkm1.git --branch refactor
  • Copied and replaced the files in custom_components
  • Stopped HA
  • Deleted all the elk folders in /deps/lib/python3.6/site-packages/ and /custom_components/__pycache__/ since there were a few of them with different versions in there.
  • Restarted HA twice
  • Checked the libs (I have elkm1_lib-0.7.7 in the site-packages)

I still get the “Unknown” states until the zone is triggered and I just noticed that the Outputs status is doing the same thing.

518

I’m baffled. The code looks good and it works fine for me. Next step is debug log. If you can turn on debugging in your configuration.yaml:

logger:
  default: debug

And make the log available to me. You can email me if you prefer (address in the elkm1-lib setup.py).

I have a theory. I could be a timing issue. The Elk could be responding with states sooner than the hass platform is ready to accept changes. The log will tell me for sure. Since I don’t have that problem I can only guess at this point. @mathd or @jshank… look forward to hearing!

519

I am cleaning up my debug log and will send it over but I have the following which may confirm your suspicion:

2018-09-03 22:21:43 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.elkm1_zone_020, old_state=None, new_state=<state sensor.elkm1_zone_020=unknown; index=20, state=unknown, physical_status=eol, logical_status=normal, definition=burglar_perimeter_instant, area=1, bypassed=False, triggered_alarm=False, friendly_name=Porte sous-sol, icon=mdi:alarm-bell @ 2018-09-03T22:21:43.242823-04:00>>

520

Did you make sure to remove all of the old files in config/custom_components/ before putting in the refactor branch code? Need to make sure the old config/custom_components/elkm1.py is gone (it’s replaced by the new config/custom_components/elkm1 folder)

521

Yes I did remove the elkm1.py file from the root of custom_components.

522

I’m pretty sure I know what the problem is. I’m just trying to prove it. The problem is that the hass state cannot be updated until hass says that the device is ready. The Elk state change comes in before hass is ready and does not get the notice to update state.

If you are comfortable adding a line of code and trying again it might prove my theory. In the file custom_components/elkm1/__init__.py, right at the end of the file there is a method. It should look like this:

    async def async_added_to_hass(self):
        """Register callbacks."""
        self._element.add_callback(self._element_callback)

Change it to look like this (one line added at the very end, indent is important):

    async def async_added_to_hass(self):
        """Register callbacks."""
        self._element.add_callback(self._element_callback)
        self._element_callback(self._element, {})
523

Yes that works :slight_smile: All my zone are displaying the correct status on start now.

1 Like
524

I will push a fix to github in Tuesday. For now, bedtime!

1 Like