feat: fire "alexa_media_last_called_event" after update

[danielbrunt57]

This addition will allow scripts/automations which reference the notify.alexa_media_last_called service or the templated sensor.last_alexa sensor to wait for this event to fire before proceeding with their actions. Previously, everyone was using a hard coded delay to ensure the update last_called had finished. I had tried watching timestamps but this was only reliable when the timestamp actually changed which sometimes did not happen. With this feature the reaction time to actions will be a variable delay yet reliable. I've implemented this with a timeout on the wait for event and if it times out, I bypass all the notify/TTS actions.

[sumoneelse]

This is awesome. No more hard-coded delays! Here is a script I'm using now to update sensor.last_alexa:

alias: Echo Device Last Called Update
sequence:
  - parallel:
      - action: alexa_media.update_last_called
        data: {}
      - alias: Wait for alexa_media_last_called_event to fire
        wait_for_trigger:
          - platform: event
            event_type: alexa_media_last_called_event
        continue_on_timeout: true
mode: single

Dropping this here in case it helps anyone and if anyone has any suggestions for improvement.

[garysargentpersonal]

@danielbrunt57 @sumoneelse I've been using this for a few days now and while it is reliable, I have noticed that waiting for the event to fire is significantly a longer delay then the old method of waiting for the timestamp to change. With the event it's around 4.5 seconds from finishing speaking to Alexa to a lamp turning on. With waiting for the timestamp change it is around 2 to 2.5 seconds.

As a result I've modified my script to now detect EITHER the timestamp changing or the event firing, which should be the best of both worlds.

I don't know if there is a way to make the event firing quicker? Also why do we need to do this at all, can't the call to update alexa's block instead of us having to wait like this?

alias: Update Last Called Alexa and wait for result
sequence:
  - parallel:
      - data: {}
        action: alexa_media.update_last_called
      - wait_for_trigger:
          - platform: event
            event_type: alexa_media_last_called_event
          - platform: state
            entity_id:
              - sensor.last_alexa
            attribute: last_called_timestamp
        continue_on_timeout: true
        timeout:
          hours: 0
          minutes: 0
          seconds: 10
          milliseconds: 0
mode: single

Where sensor.last_alexa is:

template:
  - sensor:
    - name: Last Alexa
        unique_id: last_alexa
        icon: phu:amazon-logo
        state: >
          {{ states.media_player | selectattr('attributes.last_called','eq',true) | map(attribute='entity_id') | first | default(none) }}
        availability: >
          {{ states.media_player | selectattr('attributes.last_called','eq',true) | map(attribute='attributes.last_called_timestamp') | first is defined }}
        attributes:
          last_called_timestamp: >
            {{ states.media_player | selectattr('attributes.last_called','eq',true) | map(attribute='attributes.last_called_timestamp') | first | default(none) }}
          actual_friendly_name: >
            {{ states.media_player | selectattr('attributes.last_called','eq',true) | map(attribute='attributes.friendly_name') | first | default(none) }}

[sumoneelse]

Thanks for the suggestion for improvement! I implemented the timestamp trigger in parallel with the last_called_event and watched in the UI to see which one was caught while I issued several commands.

Without exception it was the last_called_event for me. I even disabled the last_called_event trigger to verify there was nothing wrong and observed the timestamp trigger was working but slower.

I am going to leave timestamp there as belt-and-suspenders never hurts.