ELK M1 Interface

Third party integrations
587

Perhaps the way to expose the functionality of a Task firing is to just generate a custom event on the event bus. The Z-Wave component generates “scene activated” events when I push a button on a Z-Wave remote.

For example:

- alias: minimote1 scene 1
  # - button 1 short press
  initial_state: True
  trigger:
    platform: event
    event_type: zwave.scene_activated
    event_data:
      entity_id: zwave.minimote1
      scene_id: 1
  action:
    service: homeassistant.toggle
    entity_id: switch.sonoff1

Something like this might be a solution for this specific Elk task firing, and perhaps other asynchronously generated events from the Elk.

588

Yeah, we might have to change it if we can’t find a way for automations to trigger on the scene activating. Thus far I haven’t found a clean way of doing it, but most of my Google results are for triggering scene from an automation, not the other way around.

589

How were you using the switch version of tasks to drive automation?

590

Just looked for the state change event as a trigger to kick off an automation. I seems to have these left-over in my configuration…

########################################################
# watch for Elk automation invocation events for turning outside lights on and off
#
- alias: elk Ext Lights On
  initial_state: True
  trigger:
    platform: state
    entity_id: switch.elk_task_009
    to: "on"
  action:
    - service: homeassistant.turn_on
      entity_id: group.outside_lights
    - service: logbook.log
      data_template:
        name: Elk Outside Lights On Task On
        message: "Elk Outside Lights task ON  at {{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
        entity_id: group.outside_lights


# replicate behavior of Elk task that turns off lights after
# 15 minutes
- alias: elk Ext Lights On - After Timeout
  initial_state: True
  trigger:
    platform: state
    entity_id: switch.elk_task_009
    to: "off"
    for:
      minutes: 15
  action:
    - service: homeassistant.turn_off
      entity_id: group.outside_lights
    - service: logbook.log
      data_template:
        name: Elk Outside Lights On Task timeout
        message: "Elk Outside Lights task ON timeout  at {{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
        entity_id: group.outside_lights

- alias: elk Ext Lights Off
  initial_state: True
  trigger:
    platform: state
    entity_id: switch.elk_task_010
    to: "on"
  action:
    - service: homeassistant.turn_off
      entity_id: group.outside_lights
    - service: logbook.log
      data_template:
        name: Elk Outside Lights Off Task
        message: "Elk Outside Lights task ON  at {{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
        entity_id: group.outside_lights

In these examples, the Elk tasks got kicked off due to a keypad interaction.

I’m not sure if these still work any longer. When I looked earlier at the event stream coming out of Home Assistant, all I see is the associated switch changing state to “off”. Some probably has changed somewhere along the way and I didn’t notice. Lately, these automations really are not needed for me since I look for my Z-Wave door lock being unlocked to automagically deal with the outside lights…

591

Just having some custom event fired would “work” for me. I think there might be other opportunities to use Elk-specific events to notify when other random things happen? Maybe programming mode start/end, etc.

592

@lmamakos The following worked for me:

- id: task_activated
  alias: "Task activated"
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id:
        - scene.task010
  action:
    service: persistent_notification.create
    data_template:
      title: "Task activated"
      message: >-
        Task activated at {{ now().strftime('%Y-%m-%d %H:%M:%S') }}

Is that what you need?

593

I asked about this on the HASS Discord and was told :

there should be an event fired by home assistant when the service is executed and the scene entity is activated. So we should be able to make an automation that triggers on the corresponding event message. Event name should be service_executed and then match on the event data. Automation Trigger - Home Assistant

So that may be another solution. Just have to figure out the right event_data combination, etc.

594

The automation I posted in my last message works for me. Do we need more than that?

595

I think that works for my use-case.

596

Thanks to the ceaseless efforts of @gwww we will hopefully be in HASS 0.81. There will be breaking changes, especially for anyone on the older versions… but functionally you should lose nothing, just have to reformat or rename various things, etc…

5 Likes
597

Thanks to @BioSehnsucht and @gwww for the tireless efforts getting this amazing work merged into the Home Assistant code base. I was stalking the various pull requests on github, and it was a herculean effort to tweak and tune and modify the (already working quite nicely!) code to match the stylistic guidelines for Home Assistant. Especially when some of those guidelines were unknowable ahead of time.

1 Like
598

I can’t thank you guys enough for all the work you have put into this! Hands down, the best integration (I have seen) of the Elk M1 system.

599

Thank you @BioSehnsucht! You got us all going on this journey. Your insight and understanding of the ElkM1 was instrumental.

To all those who have tested and helped us get to a quality integration, thank you!

If you have a thermostat, please do some extra testing. All I can say is that the code appears to work. I did as mush testing as I could without an actual thermostat.

Yes, there are a lot of changes with the integration into HASS. Some I wish didn’t have to be made. However in the end I think we will end up with a better system, even if there is some short term pain. Fire your questions to the list when you stumble across something not working. Better still take a peek at the code. There’s an attempt to make the code readable. But, yah it is still code.

Integrations have Lovelace in mind. So, for example, there’s no hidden in the Elk config any more. I encourage you all to start to play with Lovelace. Take a look at the work by Marius for some custom Lovelace components https://github.com/ciotlosm/custom-lovelace. I have contributed heavily to the alarm_control_card (for arming/disarming). It too needs a bit of work to deal with “custom” arming modes such as arm_vacation.

HASS continues to evolve. I expect that the Elk-M1 integration will also have to evolve. Time to take a break for bit before looking at any evolution.

On to my next projects :slight_smile:… I’m looking at better UPB lighting integration (the Elk integration already supports it, but the Elk-M1 is missing stuff). And probably will start to tune up the alarm_control_card.

3 Likes
600

This is great news. I have seen that it is being published as being included. Thanks everyone for working on this project and getting it going.

601

Many thanks to @BioSehnsucht and @gwww. We all started this a very long time ago and I’m glad you guys stuck with it. My most sincerest “thank you”!

602

I am running into an issue with elk module after upgrading to 0.81
I have reduce my config to a simple:
elkm1:
host: elk://

However I get this error:
Invalid config for [elkm1]: invalid temperature unit (expected C or F) for dictionary value @ data[‘elkm1’][‘temperature_unit’]. Got None. (See /home/homeassistant/.homeassistant/configuration.yaml, line 78). Please check the docs at https://home-assistant.io/components/elkm1/
8:00 PM config.py (ERROR)

If I add config for temperature_unit the error repeats for the next missing “optional” config item. It is as if none of the optional config items are optional.

603

fwiw, i’m seeing the same behavior.

604

I’m looking for the cause now.

For now put: temperature_unit: F (or C) in your config. So you’ll have something such as:

elkm1:
  host: elk://192.168.42.42
  temperature_unit: C
  area:
    include: [1]
   (etc)
605

Fix pushed to my local repo under the elkm1-fix branch. Will merge later; waiting to see if other bugs come in. Will shoot for 0.82 release of hass.

1 Like
606

So now that the integration into HASS is complete, do we just delete the custom components that we created before so that it operates off the (newly) native integration?