Feature Request: Last Alexa Called

Today I learned that alexa_remote_control.sh can retrieve the last alexa device that was called. So, I downloaded the code and looked at the last_alexa() function. After some experimenting I figured out that function generates the Alexa API URL of https://alexa.amazon.com/api/activities?startTime=&size=1&offset=1.

A sample of JSON response is provided below. But the path we want is activities.sourceDeviceIds.serialNumber! With the device’s serial number we can direct TTS responses to the correct Echo. This is important to users like myself that have an Echo device in every major room of the house (Kitchen, Living Room, Family Room, Bed Room, etc.)

What do you say? Do you want to make an amazing upgrade to our favorite TTS component? 😃

{
	"activities": [{
		"_disambiguationId": null,
		"activityStatus": "SUCCESS",
		"creationTimestamp": 1547351733581,
		"description": "{\"summary\":\"turn on the living room computer\",\"firstUtteranceId\":\"A7WXQPH584YP:1.0/2019/01/13/03/G090QU0674750NLT/55:31::TNIH_2V.bcbda961-b9c8-4243-9d2d-b1f2279d6f1bZXV/1\",\"firstStreamId\":\"A7WXQPH584YP:1.0/2019/01/13/03/G090QU0674750NLT/55:31::TNIH_2V.bcbda961-b9c8-4243-9d2d-b1f2279d6f1bZXV\"}",
		"domainAttributes": null,
		"domainType": null,
		"feedbackAttributes": null,
		"id": "A12BCDEF3GH4I5#1547351733581#A7WXQPH584YP#G090QU0674750NLT",
		"intentType": null,
		"providerInfoDescription": null,
		"registeredCustomerId": "A12BCDEF3GH4I5",
		"sourceActiveUsers": null,
		"sourceDeviceIds": [{
			"deviceAccountId": null,
			"deviceType": "A7WXQPH584YP",
			"serialNumber": "G090QU0674750NLT"
		}],
		"utteranceId": "A7WXQPH584YP:1.0/2019/01/13/03/G090QU0674750NLT/55:31::TNIH_2V.bcbda961-b9c8-4243-9d2d-b1f2279d6f1bZXV",
		"version": 1
	}],
	"endDate": 1547351733581,
	"startDate": 1547351733581
}

last_alexa() from alexa_remote_control.sh

last_alexa()
{
${CURL} ${OPTS} -s -b ${COOKIE} -A "Mozilla/5.0" -H "DNT: 1" -H "Connection: keep-alive" -L\
 -H "Content-Type: application/json; charset=UTF-8" -H "Referer: https://alexa.${AMAZON}/spa/index.html" -H "Origin: https://alexa.${AMAZON}"\
 -H "csrf: $(awk "\$0 ~/.${AMAZON}.*csrf[ \\s\\t]+/ {print \$7}" ${COOKIE})" -X GET \
 "https://${ALEXA}/api/activities?startTime=&size=1&offset=1" | jq -r '.activities[0].sourceDeviceIds[0].serialNumber' | xargs -i jq -r --arg device {} '.devices[] | select( .serialNumber == $device) | .accountName' ${DEVLIST}
}

[brianhanifin]

_Note: I recreated my fork of your repository from scratch in an attempt to follow Github’s guidelines, and clear up some confusion. https://github.com/brianhanifin/alexa_components_

---

In testing this feature… I used Home Assistant’s “States” page. Filtering the "Attributes column with “last_called: true” shows the current “last called” device. Sometimes it would show up almost instantly, but other times it would up to a count of 10 (to estimate seconds).

After quite a bit of testing today I have come to the conclusion that, this isn’t working reliably for the purpose I wanted it for. I have tried two different approaches and there is just too often the previous device is being used. If you have any ideas on what to try, please let me know. But we might want to hold off on this feature until it can be separated as a sensor. As a sensor I believe the API would be called on demand, instead of seemingly randomly.

---

Originally I wrote a single script to update the following template sensor, and activate alexa_tts. Unfortunately, the speech almost always triggered before the sensor updated, so it would not play on the correct device. To correct this at first I tried a 10 second delay, but that wasn’t ideal… and it worked more often, but still didn’t work every time. Next I tried to store the previous sensor value in an input_text entity so I could use a wait_template instead of a delay. The script almost always hung at the wait_template.

sensor.last_alexa

platform: template
sensors:
  last_alexa:
    value_template: >
      {%- for entity in states.media_player -%}
        {%- if state_attr(entity.entity_id, 'last_called') == True -%}
          {{ entity.entity_id }}
        {%- endif -%}
      {%- endfor -%}

---

So then I tried splitting the script into 3 parts: 1. sensor updating script, 2. automation which triggers when the sensor state changes, 3. a script to execute alexa_tts. Unfortunately, that didn’t work much better. Lastly I tried replacing the sensor with an input_text entity.

script.repeat_last_message

repeat_last_message:
  sequence:
    # Make sure the automation trigger is enabled.
    - service: homeassistant.turn_on
      entity_id: automation.repeat_last_message_trigger

    # Update the last_message.
    #- service: homeassistant.update_entity
    #  entity_id: sensor.last_message

    # Update sensor.last_alexa.
    - service: homeassistant.update_entity
      entity_id: sensor.last_alexa
    - service: input_text.set_value
      data_template:
        entity_id: input_text.last_alexa
        value: >
          {%- for entity in states.media_player -%}
            {%- if state_attr(entity.entity_id, 'last_called') == True -%}
              {{ entity.entity_id }}
            {%- endif -%}
          {%- endfor -%}
  
    # Trigger an automation when the last_alexa sensor is updated.
    # automation.repeat_last_message_trigger --> script.repeat_last_message_2

automation.repeat_last_message_trigger

# Trigger when the sensor.last_alexa is updated.
alias: repeat_last_message_trigger
initial_state: off
trigger:
  platform: state
  entity_id: input_text.last_alexa
action:
  - delay: "00:00:02"
  - service: script.turn_on
    entity_id: script.repeat_last_message_2

script.repeat_last_message_2

repeat_last_message_2:
  sequence:
    # Say the previous message on the last Alexa device that was spoken to.
    - service: media_player.alexa_tts
      data_template:
        media_player: "{{ states('input_text.last_alexa')|trim }}"
        message: "{{ states('sensor.last_message') }}"

[keatontaylor]

Hey @brianhanifin, a sensor would likely be the better approach, but to do so the component would need to be re-worked a bit to allow generic login in a master component that would spawn children for the different entity types we want. I’ve been meaning to re-organize the component to support this.