alexa_media_player: Media Players Not Updating

IMPORTANT: Please search the issues, including closed issues, and the FAQ before opening a new issue. The template is mandatory; failure to use it will result in issue closure.

Describe the bug

Media Player entities go stale after a few hours. If I start playing media either with my voice, or by having a routine triggered my HA media player entities don’t know about it and just says standby. Or if media has been playing for a while and I stop it, the media player entity will still show it playing. Reloading the integration with kick things and get them showing the correct status again for a little while To Reproduce

  1. Play media on an alexa device after it’s been idle for a few hours.
  2. Observe media state in HA hasn’t changed
  3. Submit issue on github

Expected behavior

Media player should show current status of media player entities Screenshots

System details

  • Home-assistant (version): 2023.5.3
  • alexa_media (version from const.py or HA startup): 4.6.4
  • alexapy (version from pip show alexapy or HA startup): 1.26.8
  • Amazon 2FA is enabled (y/n). <!—We will not debug login issues if unanswered—>:yes

Logs Please provide logs. These debug logs begin at 9:08 when I run my “soundmachineon” routine which plays white noise on amazon music and didn’t update the status until 9:09 when I reloaded alexa media player. Ignore the BROKEN_TUYA lines, they were filling up my logs so I did a find/replace to get rid of them.

alexa_logs.txt

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 20
  • Comments: 191 (25 by maintainers)

Most upvoted comments

Openhab has also currently issues with their integration (Last Voice command no longer reported), and one of the maintainers said its due to Amazon is no longer reporting last voice command state changes via websocket. Instead Amazon is now reporting via HTTP/2 stream. Could it be that this linked, and the same is true for the media player states?

https://community.openhab.org/t/amazon-echo-smartj-binding-last-voice-command-not-working-anymore/148296/68

Please don’t ping me. I don’t promise any support. The code is open and you can make your own changes. I’ve already analyzed your logs and explained what I know. Honestly, I’m probably done with supporting this and pings do not encourage me to work more.

After updating to version 4.7.6, today Alexa Media Player requested re-authentication. With previous versions (4.6.5) this had never happened.

I use Amazon EU (IT), Hass OS 2023.9.2.

Also, is so many API calls normal?

I attach screenshots of the relogin notifications: IMG_5872

IMG_5882

same here '(

How about for Amazon.com.au?

bob-dispatch-prod-fe.amazon.com

I’ll try to patch alexapy to automatically choose the correct host.

I fixed the issue with timers and alarms for me by partially reverting https://github.com/custom-components/alexa_media_player/commit/8f0dfa2f6585ebac08bd5a708951155c80f63588

It seems that PUSH_NOTIFICATION_CHANGE events are implemented by Amazon over HTTP2. Restoring this bit of code has made my timers and alarms update within 5 seconds of a change on the device, and has the added bonus of responding to changes made on the Alexa app as well. I’ll put together a small PR for the change.

but for now, still having problems with Alexa Media Player and entities that are not updating… What a shame to no longer see the music, alarms and other things!

I also have the same problem and I’m constantly being contacted from people that are using my multinotify that are having this issue that generates two issues:

  • the volume is not resumed (as it stopped updating with the real value)
  • the music play status is wrong so at the end of the message echo will not resume the play or will play while it was not playing before (as the status was not updated), quite annoying.

Generally the “solution” is to reload the integration or restart Home Assistant but not having even a way to detect that this is happening is very bad.

From my perspective it could be that the websocket is closing without notice so it stops to receive updates from Amazon. I’m not a python programmer so I’m not able to contribute (sigh…) but couldn’t anyone check the webserver management code? We could work on that to ensure the websocket is alive and if it’s not we can reestablish it. As a last resort a code that every time interval recycle the websocket could be a temporary fix that helps this not to happen too frequently. But websocket closing should be a very detectable event that should be handled.

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

Does running homeassistant.update_entity on the relevant media_player entity help at all?

Sorry for pinging you, the only reason I did was because I sent a few messages with responses to your question and didn’t hear anything back. The app shows it playing, HA does not.

Is there anything we can do as non coders to help you try to figure out what may have changed in the api? We can’t be the only two people having this issue.

@emufan couple questions,

  1. What type of WiFi APs do you use?
  2. What type of echo devices are you seeing this issue on?

for me I use Unifi WiFi 6 Lites and am seeing this issue in particular on an echo show 5 and an echo spot. Those are the two devices I run the sound machine on, but I “think” the issue occurs on them all.

am i the only one still having the issue that the media player entity status isn’t updating on newest version?

same issue for me: v4.7.3 , amazon.it

Yes. It works flawlessly with Media controls. I can start it with voice, and pause it with HA, and resume it with voice. The HA status is delayed by 1-2 seconds, but it doesn’t get much better than this.

image

Having issues with amazon.de.

Thank you for getting this updated so quickly!

I’ve installed the latest version, restarted HA and had an Echo Dot play music for +5 minutes. The media_player entity didn’t update during the time and this was the only entry in the log:

2023-09-29 09:48:41.068 DEBUG (MainThread) [alexapy.alexahttp2] Preparing ping to https://bob-dispatch-prod-na.amazon.com/ping
2023-09-29 09:48:41.159 DEBUG (MainThread) [alexapy.alexahttp2] Received response: 204:

Is there something else that I should be doing?

polling is bad, and these rude solutions are worse than no solution

This. 100%.

Unfortunately it seems the only real solution here is to use the new HTTP/2 API.

https://github.com/Apollon77/alexa-remote/compare/v5.10.3...v6.0.0 shows the changes to enable http2 pushes. Unfortunately, alexapy is built on aiohttp, which does not support http2.

Httpx does support http2. However, swapping from aiohttp to httpx is a large undertaking. Perhaps it can be done by just replacing the websocket with httpx. If someone submits a PR to gitlab to address this, ping me here. I don’t check gitlab anymore.

Given the trends, I’m expecting for Amazon to shut down the ecosystem soon. So not in my roadmap but I will take PRs of people figure it out without just spiking the polling. That’s why it’s tagged as help wanted.

this issue is present from ever, years at least.

You sure about that? This ticket was only opened in the last few months

Yes, I’m absolutely sure about that. There was previous issues about this argument that was closed, here the first I’ve found where I’ve participating in: https://github.com/custom-components/alexa_media_player/issues/1578 That’s more than a year ago (and the problem was there from well before).

I also only started encountering this issue around that time, give or take. If the issue existed before that perhaps something has made it get worse recently so more people started encountering it / noticing?

I don’t know why that problem arrives in waves, maybe when Amazon changes something then it happens more frequently, who knows. In fact if you don’t use volume_level or timers, or play status of Alexa devices there a good chance you’ll even not noticing this issue is there as it’s not preventing announcements and other commands from being run. It makes status updates from Amazon not arriving so, for example, you change the volume of a device by voice but that volume in the Home Assistant entity don’t change. I noticed that from much time as I’ve developed multinotify, a script that, between the other functions, backup the volume and play status of devices, play the announcement then restore the volume of every device and resume the play where it was paused. When the websocket stops working that script is backing up a not real status and that makes you understand to be in that condition easily.

From my perspective it could be that the websocket is closing without notice so it stops to receive updates from Amazon.

That’s not how I interpreted Alan’s analysis of the log file, unless I misunderstood?

#1953 (comment)

Yes, you’re right. This could be a brand new issue with same symptoms that was there from ever. But stating that my Alexa devices are working as before (they update with the Echo devices status then, after a random amount of time, they stops updating) I thought that this issue was related to that condition that there from ages. Furthermore more than one users of my script told me about this issue and I suggested to reboot or reload the integration and that fixed that, until next time. So that’s the exact same issue as ever.

Hi, I am experiencing the same bug, for some reasons, the media player state isn’t updating at all, and only a reload of the integration can fix the bug, I don’t know for how much time. This is really problematic because many automations depend on these states. I’m not a python coder but I wish someone will put his hands on it to fix it, cause this integration is so popular. Anyway, thanks to the author, and I hope this bug can be fixed in the future.

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This seems to help, kept updating the entity from that point while playing, stopped playback and started a new Pandora Session and it still updated. Will play if we need to schedule the service call for periodic refreshing of the 7+ AMZ Devices

Yeah, I have something like the following running, not sure if overkill but seems to run okay and keeps things updated:

alias: Alexa media updates
description: ""
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - repeat:
      while:
        - condition: template
          value_template: "{{ true }}"
      sequence:
        - service: homeassistant.update_entity
          data: {}
          target:
            entity_id:
              - < list of entities >
        - delay:
            hours: 0
            minutes: 0
            seconds: 10
            milliseconds: 0
mode: restart

Yeah sadly Amazon have nutered a lot of this. The devs have done their upmost to keep the media player functionality going, but evilcorp just keeps shutting it off. We are luckily to have anything at all considering how much Amazon is hemorrhaging with Alexa.

Im hoping that either HA’s own voice stuff matures to the point we can just be rid of Alexa and let it die. Or that the paid Alexa tier will reenable this functionality

Guys: useless to post here further in a closed thread. The authentication issue is handled here: https://github.com/custom-components/alexa_media_player/issues/2059 and should have been solved with 4.7.7

So I’ve been updating regularly, including the latest one today, and I’ve got no volume controls in the entities for all my media players. They’ve been missing for probably a couple of months now. I saw a closed ticket about this which has redirected me to this ticket, which seems also to be closed. Am I in the right place? Why is this ticket so very active and also marked as closed? 😕

After updating to version 4.7.6, today Alexa Media Player requested re-authentication. With previous versions (4.6.5) this had never happened.

I use Amazon EU (IT), Hass OS 2023.9.2.

Also, is so many API calls normal?

I attach screenshots of the relogin notifications: IMG_5872

IMG_5882

I must be in the minority here. 4.7.3 worked mostly fine for me, but 4.7.4 and 4.7.5 do not work for me at all. I’m in Canada, and I honestly don’t remember what server I’m connected to, but something in 4.7.4 definitely broke things for me. I’ll have to do some more testing to see if I can pin the issue down.

4.7.5 : ❤️❤️❤️

Confirmed that 4.7.5 fixes the issue.

I noticed the same problem in 4.7.4 where eventually the HTTP/2 connection would close with:

[alexapy.alexahttp2] HTTP2 Connection Closed.

I’ve been running 4.7.5 for about 20 minutes and I’ve lost count of how many commands I sent and the connection has remained open.

Great work on this to all involved. Thank you.

amazon.de (or amazon.it, amazon.fr, amazon.uk etc.) is not missing, it’s covered by the default selection (https://github.com/Apollon77/alexa-remote/blob/master/alexa-http2push.js#L33)

Please note, we’ll do another release to address this but after that releases will slow down. We are missing many translations for some of the new keys that we were required to add and they only get added during a release. If you’re in a non-English locale, it’d be helpful to get those filled out or you’ll just see blanks where we don’t have your language.

How about for Amazon.com.au?

bob-dispatch-prod-fe.amazon.com I’ll try to patch alexapy to automatically choose the correct host.

https://github.com/Apollon77/alexa-remote/blob/master/alexa-http2push.js#L33-L44 has the conversions.

Keep in mind, the conversions aren’t complete! amazon.de (Germany) is missing for example. https://github.com/Apollon77/alexa-remote/blob/master/alexa-http2push.js#L33-L44

Please note, we’ll do another release to address this but after that releases will slow down. We are missing many translations for some of the new keys that we were required to add and they only get added during a release. If you’re in a non-English locale, it’d be helpful to get those filled out or you’ll just see blanks where we don’t have your language.

How about for Amazon.com.au?

bob-dispatch-prod-fe.amazon.com

I’ll try to patch alexapy to automatically choose the correct host.

https://github.com/Apollon77/alexa-remote/blob/master/alexa-http2push.js#L33-L44 has the conversions.

Amazing find. Any way to change that on HAOS?

I’m not very familiar with HAOS. If the path above doesn’t work try one of these methods.

Apparently alexapy hardcodes the us endpoint, hence eu instances don’t receive push updates. Changing the authority to bob-dispatch-prod-eu.amazon.com fixed the issue.

After removing and re-adding the integration with 4.7.3, I am once again getting push messages, but the entites are only updating after a subsequent voice command.

Example: I say “Alexa, set an alarm for 7:30am” Next alarm sensor shows “Unknown” I say “Alexa, what time is it?” Next alarm sensor shows “Saturday September 30 7:30am” I say “Alexa, cancel alarm” Next alarm sensor shows “Saturday September 30 7:30am” I say “What is today’s weather” Next alarm sensor shows “Unknown”"

I’ve repeated this with varying lengths of delay in between steps from 5 seconds to 10 minutes with the same result. I believe that some of the duplicate suppression logic introduced to overcome previous issues might be causing the problem here and will dig into that code.

I just installed the 4.7.3 update and restarted the home assistant server and everything started working perfectly!

Working perfectly (tested only 1x time on an Echo Show) “Set a timer / stop time” on 4.7.3. I will update this comment if it stops working but so far so good.

I made no changes except installing the update and restarting Home Assistant.

Config data including region URLs:

var ue_id = 'AMXXXXXXXXXXX',
    ue_url = '/ap/uedata',
    ue_navtiming = 1,
    ue_mid = 'XXXXXXXX',
    ue_sid = '141-XXXXXXX-XXXXXX',
    ue_sn = 'www.amazon.com',
    ue_furl = 'fls-na.amazon.com',
    ue_surl = 'https://unagi-na.amazon.com/1/events/com.amazon.csm.nexusclient.prod',
    ue_int = 0,
    ue_fcsn = 1,
    ue_urt = 3,
    ue_rpl_ns = 'cel-rpl',
    ue_ddq = 1,
    ue_fpf = '//fls-na.amazon.com/1/batch/1/OP/ATVPDKIKX0DER:141-XXXXXXX-XXXXXX:XXXXXXXXX$uedata=s:',
    ue_sbuimp = 1,
    ue_ibft = 0,
    ue_fnt = 0,

@all which are having issues with the new version and @all where it does work:

Which site do you using? in my case, i am using amazon.de

I don’t remember seeing this Public URL option before. Is it relevant? I’ve populated it but it hasn’t changed anything, but I won’t be in a position to remove and re-add the integration until later today.

image

I removed, re-added and inserted my URL into the configuration and restarted. Unfortunately there was no change.

Also for me after removing the integration and readd/relogin, media players does not update. I have enbled debug logging for the compontent, but there was no usefull information why it fails. The initial fetch of data works.

Anything we can provide to help out?

same as me. nothing in logs but all entites are unavailable: image

Also for me after removing the integration and readd/relogin, media players does not update. I have enbled debug logging for the compontent, but there was no usefull information why it fails. The initial fetch of data works.

Anything we can provide to help out?

Even after relogging, push updates don’t work. This might be related:

2023-09-29 11:29:48.092 DEBUG (MainThread) [alexapy.alexahttp2] Received raw message: --------abcde123
2023-09-29 11:29:48.112 DEBUG (MainThread) [alexapy.alexahttp2] HTTP2 Connection Closed.
2023-09-29 11:29:48.113 DEBUG (MainThread) [alexapy.alexahttp2] HTTP2 Connection Closed.
2023-09-29 11:29:48.114 DEBUG (MainThread) [custom_components.alexa_media] c*********@g*******m: Close requested; will not reconnect http2
2023-09-29 11:29:48.115 DEBUG (MainThread) [custom_components.alexa_media] c*********@g*******m: Close requested; will not reconnect http2

This may be useful. https://github.com/mkb79/Audible. Apparently for audible registration access_token got deprecated.

Regardless, I may be able to do a http2 release but users will have to manually generate an access_token. https://github.com/Apollon77/alexa-remote. For some reason the way we generate tokens does not allow http2 connections. It may very well be my account is blocked due to too many connections.

Ok, I’m trying to put actual information in this thread to try to resolve this. However, with all the chatter, it’s going to get buried. Please take the workaround chatter to the discussion forum.

Also, can I get a volunteer to go through this thread and help clean it up and maybe more moderation?

Anyway back to the technical:

Spoke too soon … updates worked instantly for a device the first times. But now now updating again 😦

Because you’re bombing Alexa API with requests each 30 seconds, and I guess after some time API starts to debounce it. That’s why polling is bad, and these rude solutions are worse than no solution.

Works great for me and it doesn’t make them go unavailable. We’re just updating the entities, not reloading the integration. This seems to be a decent workaround for now.

You are still wrong here. reload_config_entry is reloading the integration. See https://www.home-assistant.io/integrations/homeassistant/#service-homeassistantreload_config_entry.

Updating an entities is via update_entity. See https://www.home-assistant.io/integrations/homeassistant/#service-homeassistantreload_config_entry.

I tried proposed NodeRED alternative - and it’s actually lightning-fast in TTS announcements, skills like Actionable Notifications etc. No subscriptions though, as far as I understand. So returning to status-quo would be preferable - and then I can slowly move some functionality, not related to media player itself, to NodeRED. 😃

Does Node Red show last_called and timers?

Last called can be retrieved by getting Activities and picking the latest one. It does even tell what was the request.

Timers/alarms are returned with Notifications for device.

You can play with it yourself, it’s easy.

I agree, I’m hoping that nabu casa comes out with some hardware at the end of the year of the voice to compete with Alexa, then we can let this integration die

You seem to have misunderstood something here.

This custom component is not used to transmit voice commands to Home Assistant. This custom component is used to control Amazon Alexa and Amazon Echo devices.

Voice commands are transmitted to Home Assistant via the Nabu Casa Skill and the Nabu Casa Cloud.

Seems that this integration is going to be abandoned very soon, when such fundamental issues are not fixed anymore. I really loved it.

I agree, I’m hoping that nabu casa comes out with some hardware at the end of the year of the voice to compete with Alexa, then we can let this integration die

Seems that this integration is going to be abandoned very soon, when such fundamental issues are not fixed anymore. I really loved it.

Same problem. Will be possible to solve it somehow?

Same here. Will wait for updates. If any help is needed, please reach out.

Today I noticed that I am having the same issue where the media player (Alexa) status isn’t updating for any of its attributes unless the entity is reloaded manually. Ive created an automation to overcome this by making the trigger for any status change in the media player to reload the “Home Assistant Core Integration: Update entity”. This works but isn’t really a solution.

@Pirol62 While I can’t speak for what thresholds Amazon deems acceptable, that looks like an entirely reasonable workaround to me to keep polling to a minimum while still allowing the desired functionality 😃

You are suggesting, to poll/ping every entity periodically e.g. every 1 minute 24/7? I don’t know, if this is a good apprach.

Agreed, but a production / user workaround is better than nothing. I would like a bit more control over the the HA Polling threads, or Ubiquity UDME not to loose fixed DNS entries when it shouldn’t and forget ones when it should, no defects there 😉

The polling the monitored media_players is working for me ATM, 12% Utilization on the NUC style HA host (No noticeable Changes). So I am happy now that I can see my last ten items on my playlist dashboard.

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This seems to help, kept updating the entity from that point while playing, stopped playback and started a new Pandora Session and it still updated. Will play if we need to schedule the service call for periodic refreshing of the 7+ AMZ Devices

That’s a great question, I’m not home this weekend but I’ll test that out when I get back.

I would completely understand and as you said open code, etc. But I cannot do such codings and have the not-updating-anymore as well. So any mitigation oder fix on the long run would be very very good of course.

Here e.g. die next-timer entities often are not started and stay as unavailable even when a timer on the device is started. Only a reload of the integration is fixing this then.

@alandtse is there anything else I can provide to help solve this issue?

Can confirm here as well. There is in these cases not error in the log, nothing. And state of player is Standby but this state state is then hours old.

But if I try via TTS to call it, nothing is happening. Only if I restart the integration and try it again.

And even if I start e.g. a timer via voice on the device itself, the next_timer-entity stays in “unknown”. And only if I restart the integration, the next_timer-entity would be filled again.

Yes, but the logs also show that the routine starts which just plays white noise from Amazon’s music, but the status of the player never updates. The official app does show that update, and reloading the integration updates the media player and then everything is fine…for a couple hours.