Timers still not updating reliably after 4.6.5 fix

[dpgh947]

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

Alexa timers not being updated in HA reliably, even after the fix to the previous reports of this in 4.6.5

To Reproduce

Set an alexa timer, look at HA sensors.

Expected behavior

Timers should appear, count down, and get reset at end, or if the timer is cancelled.

Screenshots

System details

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

Logs Please provide logs.

I have a debug log but am not sure all sensitive info is removed? Serial numbers are mostly obscured but still appear in some URLs logged

Additional context

I have been waiting on this fix as I have some automations which rely on timers (for example, if a cooking timer on my kitchen echo ends, I send a TTS alert to other echoes in case we can't hear the kitchen). I installed 4.6.5 straight away this morning and tested. First time I set a timer, it wasn't picked up in HA at all. I then enabled debug log and set another timer, it also was not picked up in HA for around 30 seconds, so I then cancelled the timer, at which point it WAS then picked up in HA. So I then had the situation where HA had an active timer sensor, but there was no actual live timer on the alexa device. The only way out of this was to reload the integration.

I have the debug log for this, but as noted above, I am not sure that all sensitive info is blocked out of the log? I can see most occurrences of serial number are blocked out, but there are still some visible in URLs that are logged. Is this an exposure?

[sambarlick]

I'm also having this issue too.

[dpgh947]

I see in the discussion here - https://github.com/custom-components/alexa_media_player/pull/1974 - that this fix is probably the best that can be done right now considering that Amazon have stopped (temporarily? who knows) the call that the code previously relied upon to update the timer sensors. I can completely understand that, but putting that info in the fix and/or the original issue before closing that would be useful. As the timers are working right now, I can no longer use them in the automations I was previously using. Right now, setting a timer seems to get reflected in HA most of the time (sometimes after 30 seconds or more, sometimes just never), timers ending also get reflected most of the time, but cancelling a timer part way through hardly ever gets sent through to HA. The new mechanism might be the best available at the moment, but for whatever reason, on my system it just isn't reliable.

[tbclark3]

I have about 20 Alexa devices, and the timers have never worked at all in the roughly 1 year that I have been using Home Assistant, always showing "Unknown". With this 4.6.5 release, they have started working for the first time. There is an inconsistent delay, usually a minute or two, but the timers work consistently except for a short timer that expires before the entity gets updated.

[popy2k14]

Dont know if we are facing the same issue. I am using _next_alarm to automate blinds and so on and sadly they also get's not updated since about a month (~HA 2023/06).

Does _next_alarm entities works for you guys?

[dpgh947]

I have been testing this timer problem and I am fairly certain it is a timing issue to do with when the push_activity gets sent compared to when the previous command that is no longer being sent was. Sometimes setting a timer and then cancelling it updates HA as expected, sometimes the set never gets picked up, and then the cancel actually causes the HA sensor to update with the timer that was originally set. A subsequent voice interaction (anything, even just "alexa" with no command) then causes the sensor to revert to "Unknown" as it should have after the cancel. This behaviour led me to thinking that the information that is being fetched from Amazon when this push_activity is seen has (sometimes) not yet been updated with the timer info (either being set, or cancelled/stopped).

I started work in mainframe IT over 40 years ago, don't know python, don't know GIT and don't know the API details so forgive me if this is complete nonsense, but after this testing and looking through the code changes in the 4.6.5 fix I have found that putting a delay in at the point in __init__.py where the command is handled has completely eradicated the problem for me. With this in place, setting and cancelling timers, or stopping them when they expire, works every time (so far!), in that the HA sensor is always updated as expected. I have used 5 seconds, I started at a completely arbitrary 4 but for whatever reason that didn't always pick up a "stop" when a timer ends. This is clearly a bit of a bodge, it may cause problems or may be fixed better another way, but it doesn't seem to cause any problems elsewhere that I can see:

if command == "PUSH_ACTIVITY":
                if (
                    datetime.now().timestamp() * 1000
                    - hass.data[DATA_ALEXAMEDIA]["accounts"][email][
                        "last_push_activity"
                    ]
                    > 100
                ):
                    #  Last_Alexa Updated
                    last_called = {
                        "serialNumber": serial,
                        "timestamp": json_payload["timestamp"],
                    }
                    try:
                        _LOGGER.debug("timing fix - SLEEPING 5 SECS")     <===============
                        await asyncio.sleep(5)                            <=============== 
                        await coord.async_request_refresh()
                        if serial and serial in existing_serials:
                            await update_last_called(login_obj, last_called)
                        async_dispatcher_send(
                            hass,
                            f"{DOMAIN}_{hide_email(email)}"[0:32],
                            {"push_activity": json_payload},
                        )
                    except AlexapyConnectionError:
                        # Catch case where activities doesn't report valid json
                        pass
                else:

The result is a delay between the push coming in and the various API calls as seen here (edited):

2023-07-03 08:44:20.563 DEBUG (MainThread) [custom_components.alexa_media] d****p@p******m: Received websocket command: PUSH_ACTIVITY : ********
2023-07-03 08:44:20.563 DEBUG (MainThread) [custom_components.alexa_media] timing fix - SLEEPING 5 SECS
2023-07-03 08:44:25.867 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static GET: https://alexa.amazon.co.uk/api/dnd/device-status-list returned 200:OK:application/json
2023-07-03 08:44:25.923 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static POST: https://alexa.amazon.co.uk/api/phoenix/state returned 200:OK:application/json
2023-07-03 08:44:25.924 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: get_entity_state response: {'deviceStates': *********
2023-07-03 08:44:26.157 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static GET: https://alexa.amazon.co.uk/api/devices-v2/device returned 200:OK:application/json
2023-07-03 08:44:26.361 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static GET: https://alexa.amazon.co.uk/api/bluetooth?cached=false returned 200:OK:application/json
2023-07-03 08:44:26.440 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static GET: https://alexa.amazon.co.uk/api/device-preferences returned 200:OK:application/json
2023-07-03 08:44:30.774 DEBUG (MainThread) [alexapy.alexaapi] d****p@p******m: static GET: https://alexa.amazon.co.uk/api/notifications returned 200:OK:application/json
2023-07-03 08:44:30.775 DEBUG (MainThread) [custom_components.alexa_media] d****p@p******m: Updated 7 notifications for 3 devices at 2023-07-03 08:44:30.775655+01:00

Someone has mentioned elsewhere that snoozing a timer still does not update HA with the extended time, I have found that with this delay in place that seems to work too.

Solving a timing problem with an arbitrary pause is obviously not a guaranteed 100% solution, there may well be occasions when 5 seconds is not enough, but it certainly seems good enough on my system for my needs now. Without it, it is far too hit and miss.

[popy2k14]

@dpgh947 nice find!

Does ..._next_alarm entities also works for you?

In my case since HA 2023/06 it doesnt work, also not with 4.6.5. When HA is restarted the correct ...next_alarm entities are read from the API, but when you enable/disable/change an alarm, the change is not picked up.

[dpgh947]

@dpgh947 nice find!

Does ..._next_alarm entities also works for you?

In my case since HA 2023/06 it doesnt work, also not with 4.6.5. When HA is restarted the correct ...next_alarm entities are read from the API, but when you enable/disable/change an alarm, the change is not picked up.

I don't use alexa alarms in HA but looking at the entities I can see that the relevant one was updated when I set an alarm last night for getting up this morning. I would guess that they get picked up by the same mechanism.

If you want to try my bodge, you can just edit the file in \config\custom_components\alexa_media (it's around line 910 onwards) and then restart HA to pick it up (reloading the integration won't do).

EDIT - this edit update works on a raspberry pi install using HAOS, don't know about other platforms...

[dpgh947]

OK, hold your horses... this delay is sometimes causing the update of last_alexa to get delayed too...

[popy2k14]

@dpgh947 nice find! Does ..._next_alarm entities also works for you? In my case since HA 2023/06 it doesnt work, also not with 4.6.5. When HA is restarted the correct ...next_alarm entities are read from the API, but when you enable/disable/change an alarm, the change is not picked up.

I don't use alexa alarms in HA but looking at the entities I can see that the relevant one was updated when I set an alarm last night for getting up this morning. I would guess that they get picked up by the same mechanism.

If you want to try my bodge, you can just edit the file in \config\custom_components\alexa_media (it's around line 910 onwards) and then restart HA to pick it up (reloading the integration won't do).

EDIT - this edit update works on a raspberry pi install using HAOS, don't know about other platforms...

Have patched the file manually and restarted HA. As before alarms got updated/loaded once HA was restarted but sadly not if i change the alarm time/day/repeat... in the alexa app. Will revert it for now.

[popy2k14]

It would be so nice if the alexa data (alarm/timers/...) would be reliable again.

[elarsson1]

I have also observed that alarms stopped updating with the 4.6.5 update reliably. With debug logging enabled, I noticed that I was seeing between 2 and 3 PUSH_ACTIVITY messages after setting or clearing an alarm and the duplicate suppression added in 4.6.5 (enforces a minimum of 100 second delay between subsequent PUSH_ACTIVITY being processed) was firing for the second and third occurrence of the PUSH_ACTIVITY message. I eliminated the duplicate suppression check and now find that the alarms are being processed reliably.

Incidentally, I've also observed that my Alexa routine that is set to fire when an alarm is dismissed also broke around the same time, so I suspect that Amazon's change may have unintentionally broke something in their own stack in addition to affecting this component. This gives me some hope they may revert the change.

[popy2k14]

I have also observed that alarms stopped updating with the 4.6.5 update reliably. With debug logging enabled, I noticed that I was seeing between 2 and 3 PUSH_ACTIVITY messages after setting or clearing an alarm and the duplicate suppression added in 4.6.5 (enforces a minimum of 100 second delay between subsequent PUSH_ACTIVITY being processed) was firing for the second and third occurrence of the PUSH_ACTIVITY message. I eliminated the duplicate suppression check and now find that the alarms are being processed reliably.

Incidentally, I've also observed that my Alexa routine that is set to fire when an alarm is dismissed also broke around the same time, so I suspect that Amazon's change may have unintentionally broke something in their own stack in addition to affecting this component. This gives me some hope they may revert the change.

Can you please give us details what to revert/change in the code to get alarms working reliable again?

[dpgh947]

EDIT - forget this update below, after working flawlessly during loads of tests, I just had another instance of saying "stop" to an expired timer going off failing to update HA properly. There is clearly a random timing issue here to do with the push_activity being sent and the timer info coming out of the api, but I can't figure out how to address it without causing other issues.

---

I had also experimented with taking out that check for double PUSH_ACTIVITY calls, but couldn't see it making any consistent difference - but I don't use alarms in HA so wasn't looking at them then.

Trying to figure out what this code is actually doing, and what the intention is, when I don't know python or the way all this asynchronous handling of the push commands and the API hangs together is making my brain hurt, but here is what I have now done, which might be complete garbage but might point someone who does know what they are doing in the right direction:

The routine that handles(handled) PUSH_NOTIFICATION_CHANGE, and which I believe is therefore no longer being used at all, calls "process_notifications". That has code handling alarms, so I added a call to that to the PUSH_ACTIVITY routine where I had tried the delay,

if command == "PUSH_ACTIVITY":
                if (
                    datetime.now().timestamp() * 1000
                    - hass.data[DATA_ALEXAMEDIA]["accounts"][email][
                        "last_push_activity"
                    ]
                    > 100
                ):
                    #  Last_Alexa Updated
                    last_called = {
                        "serialNumber": serial,
                        "timestamp": json_payload["timestamp"],
                    }
                    try:
                        await coord.async_request_refresh()
                        #
                        await process_notifications(login_obj)            <================
                        #
                        if serial and serial etc........

I found this was also causing a delay in last_alexa getting updated like my first delay bodge did, because there is a sleep(4) in the process_notifications routine, so I took that out too,

async def process_notifications(login_obj, raw_notifications=None):
        """Process raw notifications json."""
        if not raw_notifications:
            #await asyncio.sleep(4)                                      <================ commented out
            raw_notifications = await AlexaAPI.get_notifications(login_obj)
        email: str = login_obj.email
        previous = hass.data[DATA_ALEXAMEDIA]["accounts"][email].get(
            "notifications", {}
        )

Having last_alexa updated promptly is important to me because I have lots of node red stuff that responds to custom alexa phrases and responds to the device spoken to using TTS.

With these changes (note check for double calls still in place), I have found that last_alexa gets updated promptly, my alarm entities are getting updated when I set/cancel alarms, and timers work completely reliably, with one exception that I have found so far - if you set a timer on one echo, and then cancel it from another, that change is never picked up in HA, due to the fact (I think) that there is no push seen coming from the original device in that situation. The only way to clear it is to speak something - anything - to the original device. Clearly it would be possible to update all timer sensors rather than just the ones for the device that is being dealt with because the info is there in the "notifications" API call result, but that is beyond my so-far-few-hours-worth of python experience....

[jane-t]

I found a horrid work around for now. When the current timer goes off in the kitchen. I send

service: media_player.play_media data: media_content_id: go ding media_content_type: custom target: entity_id: media_player.kitchen_sonos

Which makes the Alexa go ding and the timer information is updated on the integration.

[dpgh947]

I found a horrid work around for now. When the current timer goes off in the kitchen. I send

service: media_player.play_media data: media_content_id: go ding media_content_type: custom target: entity_id: media_player.kitchen_sonos

Which makes the Alexa go ding and the timer information is updated on the integration.

That's clever, not horrid. What do you trigger that off?

[jane-t]

When the current timer time is reached I trigger it. It is not perfect but it helps.

[dpgh947]

Well it's not perfect, but I'm running with those changes above still. On the latest code I'd say timers work about 60% of the time, either not starting or not picking up when they are stopped or cancelled, and with the changes I've made it's about 98%. Very occasionally when I "stop" a timer that's going off, it doesn't update HA until I speak to it again.

[amaisano]

Well it's not perfect, but I'm running with those changes above still.

@dpgh947 which changes, exactly? You have two comments here which different code changes.

I made all your suggested edits and my timer is more of a mess than it was with the vanilla 4.6.5 code.

Are you able to post a gist or full file of what you have working? Maybe I misunderstood your changes/which file to make them in. Thanks.

[amaisano]

I found a horrid work around for now. When the current timer goes off in the kitchen. I send

service: media_player.play_media data: media_content_id: go ding media_content_type: custom target: entity_id: media_player.kitchen_sonos

Which makes the Alexa go ding and the timer information is updated on the integration.

@jane-t thanks for the bandaid. Works to clear the status of a cancelled/stopped timer. However doesn't quite work when snoozing:

Timer starts going off, "Alexa, snooze 10 minutes" "OK" -- no updates happen and timer is still at original time in HA.

Before all this API change nonsense, the snooze request would update the HA timer datetime, which I used as a trigger condition (to recognize the snooze action). Now when we say that phrase, the HA sensor never updates and continues to be in the past.

[dpgh947]

Well it's not perfect, but I'm running with those changes above still.

@dpgh947 which changes, exactly? You have two comments here which different code changes.

I made all your suggested edits and my timer is more of a mess than it was with the vanilla 4.6.5 code.

Are you able to post a gist or full file of what you have working? Maybe I misunderstood your changes/which file to make them in. Thanks.

Sorry if I caused confusion... it's just the updates in my latest post, forget my first attempt, so only adding the

await process_notifications(login_obj)

call at around line 927 and removing the sleep(4) at around line 677 (which was only put there in 4.6.5 but not explained), both these in __init__.py

EDIT - snoozing a timer that's going off works for me too.

[amaisano]

Ok I made that change (only those two changes) and snoozing is working GREAT. But now stopping the timer is impossible.

When the timer rings, I say "Alexa, stop timer" and the noise stops. However, HA's sensor datetime just updates to a new value, instead of returning to "unknown" which is what is expected.

I tried @jane-t 's service call and it also bumps the datetime - the the current time (time I made the call).

I tried reloading AMP, and same behavior. The datetime just changes from "12 seconds ago" to "now" (in datetime format of course).

I tried talking to the Echo Dot and same behavior - it just keeps increasing the timer sensor time to the current time, causing infinite loops in my automations.

What the heck is going on?

[dpgh947]

I have never seen anything like that, all I can think is the echo is screwed up somehow, try unplugging it and see if that clears it.

[popy2k14]

Well it's not perfect, but I'm running with those changes above still.

@dpgh947 which changes, exactly? You have two comments here which different code changes. I made all your suggested edits and my timer is more of a mess than it was with the vanilla 4.6.5 code. Are you able to post a gist or full file of what you have working? Maybe I misunderstood your changes/which file to make them in. Thanks.

Sorry if I caused confusion... it's just the updates in my latest post, forget my first attempt, so only adding the

await process_notifications(login_obj)

call at around line 927 and removing the sleep(4) at around line 677 (which was only put there in 4.6.5 but not explained), both these in __init__.py

EDIT - snoozing a timer that's going off works for me too.

thx for the hints. I have changed the code and restarted HA. Sadly alarms doesnt update, as it was before the amazon API changes.

Does alarms update for you?

thx

[toadleyb]

I found a horrid work around for now. When the current timer goes off in the kitchen. I send

service: media_player.play_media data: media_content_id: go ding media_content_type: custom target: entity_id: media_player.kitchen_sonos

Which makes the Alexa go ding and the timer information is updated on the integration.

This works perfectly for me on my daily alarm. Thanks!

[dpgh947]

thx for the hints. I have changed the code and restarted HA. Sadly alarms doesnt update, as it was before the amazon API changes.

Does alarms update for you?

thx

I do see alarm entities updating when I set and clear alarms, yes, but I don't use them in ha so I can't say if they were working without my update anyway.

[NivaBarCar]

Nice to see that you are also facing these problems with alarms not updating. Sad that it's officially not working for ages anymore. I did try the workarounds mentioned here and many thanks @popy2k14 for providing so many details.

I did try your code changes but cannot confirm that it's working for me sadly enough. When changing it the whole integration won't start anymore. I guess it's because I'm running HA with Docker in a container.

I will follow the discussion further hoping to find a solution for me as well as it's annoying to restart HA every time I change the alarm in the Alexa app :)

[dpgh947]

Well since yesterday, timers are completely broken for me, any changes only get picked up on integration reload, AND last_called is not being reliably updated either. Calling the alexa_media_update_last_called service does cause the last_called attribute to get updated, but just speaking to a device no longer does, although an update might randomly come through several minutes later... so either something is broken at amazon's end, or it's another deliberate change from them which is further breaking the api link to HA.

[elarsson1]

@dpgh947 How often are you reloading? I have had a daily reload set up for a while to address intermittent push notification failures but have considered implementing a more frequent reload to address the loss of push notifications that has manifested in the past few days. I'm concerned about hitting Alexa API throttle limits. My main use case is getting the next alarm time from the bedroom echos to schedule various wake up aiming

I've also been digging through the code base to figure out how to reactivate the old polling code. It appears to be controlled by a SCAN_INTERVAL configuration setting * 10 if web sockets is enabled, but I'm seeing no evidence that the polling is happening.

[amaisano]

Well since yesterday, timers are completely broken for me, any changes only get picked up on integration reload, AND last_called is not being reliably updated either. Calling the alexa_media_update_last_called service does cause the last_called attribute to get updated, but just speaking to a device no longer does, although an update might randomly come through several minutes later... so either something is broken at amazon's end, or it's another deliberate change from them which is further breaking the api link to HA.

I've noticed starting yesterday the same awful behavior. Things were working well enough with that workaround code change until today. Maybe servers are messed up again.

[popy2k14]

@dpgh947 How often are you reloading? I have had a daily reload set up for a while to address intermittent push notification failures but have considered implementing a more frequent reload to address the loss of push notifications that has manifested in the past few days. I'm concerned about hitting Alexa API throttle limits. My main use case is getting the next alarm time from the bedroom echos to schedule various wake up aiming

I've also been digging through the code base to figure out how to reactivate the old polling code. It appears to be controlled by a SCAN_INTERVAL configuration setting * 10 if web sockets is enabled, but I'm seeing no evidence that the polling is happening.

How do you "reload" to get wakeup alarms working again in my bedroom? Can you please guide me in the right direction, so wakeup alarms would get updated (at least once a day).

Thx

[dpgh947]

@dpgh947 How often are you reloading? I have had a daily reload set up for a while to address intermittent push notification failures but have considered implementing a more frequent reload to address the loss of push notifications that has manifested in the past few days. I'm concerned about hitting Alexa API throttle limits. My main use case is getting the next alarm time from the bedroom echos to schedule various wake up aiming

I've also been digging through the code base to figure out how to reactivate the old polling code. It appears to be controlled by a SCAN_INTERVAL configuration setting * 10 if web sockets is enabled, but I'm seeing no evidence that the polling is happening.

I am not doing a regular reload, it's a bit pointless for timers unless you do it say every 10 seconds, which would certainly break something. What I have done for now is update my node red flow that maintains the last_alexa sensor that I use in my TTS routines. I have added to that so that when it sees ANY change for a media player that ISN'T currently marked as the last_called, it calls the update_last_called service. This has at least solved (for now) the last_called problem. Timers and alarms, well, they're just broken. Obviously something the integration does during startup is retrieving the info, so it should be possible to make that same call triggered off something (I don't know what) for the info to be updated on the fly like it used to, but I have not managed to figure that out.

[dpgh947]

@dpgh947 How often are you reloading? I have had a daily reload set up for a while to address intermittent push notification failures but have considered implementing a more frequent reload to address the loss of push notifications that has manifested in the past few days. I'm concerned about hitting Alexa API throttle limits. My main use case is getting the next alarm time from the bedroom echos to schedule various wake up aiming I've also been digging through the code base to figure out how to reactivate the old polling code. It appears to be controlled by a SCAN_INTERVAL configuration setting * 10 if web sockets is enabled, but I'm seeing no evidence that the polling is happening.

How do you "reload" to get wakeup alarms working again in my bedroom? Can you please guide me in the right direction, so wakeup alarms would get updated (at least once a day).

Thx

You can reload any integration by calling the service homeassistant.reload_config_entry and give it the entity of anything that the integration controls. So in this case, any media_player.xxx entity. Try it from the developer tools "services" tab. Then you can call it from an automation, or from a node red flow.

[dpgh947]

For those that actually understand how this code works (I certainly don't), this is what I have found in debug traces.

The timer updates used to get handled when a PUSH_NOTIFICATION_CHANGE command was seen. The last update to fix timers a few weeks ago was to alter this to when PUSH_ACTIVITY was seen, because for whatever reason amazon stopped sending the PUSH_NOTIFICATION_CHANGE.

Now, when I speak to a device, all I see coming in are PUSH_EQUALIZER_STATE_CHANGE and PUSH_VOLUME_CHANGE, so now it isn't sending PUSH_ACTIVITY either.

[popy2k14]

@dpgh947 How often are you reloading? I have had a daily reload set up for a while to address intermittent push notification failures but have considered implementing a more frequent reload to address the loss of push notifications that has manifested in the past few days. I'm concerned about hitting Alexa API throttle limits. My main use case is getting the next alarm time from the bedroom echos to schedule various wake up aiming I've also been digging through the code base to figure out how to reactivate the old polling code. It appears to be controlled by a SCAN_INTERVAL configuration setting * 10 if web sockets is enabled, but I'm seeing no evidence that the polling is happening.

How do you "reload" to get wakeup alarms working again in my bedroom? Can you please guide me in the right direction, so wakeup alarms would get updated (at least once a day). Thx

You can reload any integration by calling the service homeassistant.reload_config_entry and give it the entity of anything that the integration controls. So in this case, any media_player.xxx entity. Try it from the developer tools "services" tab. Then you can call it from an automation, or from a node red flow.

thx a lot. triggering the reload now every 10 minutes and the wakeup alarm times get's updated! The intervall of 10 minutes suffice for my use case scenario.

Above you mentoned an API throttle limit, will 10 minutes work well and dont trip the limit? In other words, how fast can i go without tripping it?

Are there any disadvantages to reload the config in an intervall?

PS.: I dont have looked at the code, so dont understand it either, but would polling get back most of the functionallity. Sure with delays, but maybe with this we can use the addon again?

thx

[dpgh947]

@popy2k14 That wasn't me commenting about the throttle limit and polling... I've seen that code, but I don't understand that either.

[popy2k14]

Oh, sorry :-) PS.: Polling with homeassistant.reload_config_entry does not work reliable when calling every 10 minutes. Now the error pops up:

[139733845156112] Error handling message: The config entry x.x@gmail.com - amazon.de (alexa_media) with entry_id 54f659544acf0f0e10c8032069970908 cannot be unloaded because it is not in a recoverable state (ConfigEntryState.FAILED_UNLOAD)

And alexa media.player doesnt work anymore. All entities are unavailable!

[Ulli2k]

For my echo dot 5th the update never works. The only way is reinitialize the complete integration.

[popy2k14]

As a workaround for wakeup alarms I have now created virtual lights for every bedroom and exposed them in emulated hue.

Alexa can use an wakeup light for all alarms, which is now set to the individual virtual light. So I can react in HA's automations again.

This way it's better than using Alexa's wakeup routine, because you can set an wakeup light per Alexa device and they also stick on new alarms for reach device.

So a family member can not mess the alarms up so quickly or forget to add an routine 😉

Hope this helps

[beniffland]

Not sure if this is related but I have noticed that the total_active attribute is not getting updated. I use this to determine whether a timer has been started and then display an actual timer on a dashboard. For me the total_active won't update unless I reload the integration.

[alandtse]

Now, when I speak to a device, all I see coming in are PUSH_EQUALIZER_STATE_CHANGE and PUSH_VOLUME_CHANGE, so now it isn't sending PUSH_ACTIVITY either.

This is a key point. If Amazon has disabled this, then there will be no updates possible without going the polling route.

Above you mentoned an API throttle limit, will 10 minutes work well and dont trip the limit? In other words, how fast can i go without tripping it?

You'll know you've hit the limit when your account gets blocked or all of us who use the API get blocked. Amazon doesn't publish that type of info.

[oneseventhree]

has anyone found a work around for this? I know reloading the integration gets the timers to show up but theres no way to automate a reload of an integration (as far as I am aware?)

[colinnewman2000]

has anyone found a work around for this? I know reloading the integration gets the timers to show up but theres no way to automate a reload of an integration (as far as I am aware?)

You can do this: https://github.com/custom-components/alexa_media_player/issues/1992#issuecomment-1662908144

But don't run it too frequently or your developer account will get locked out. This means it is only really useful for Alarms which don't require real time updates.

[oneseventhree]

has anyone found a work around for this? I know reloading the integration gets the timers to show up but theres no way to automate a reload of an integration (as far as I am aware?)

You can do this: #1992 (comment)

But don't run it too frequently or your developer account will get locked out. This means it is only really useful for Alarms which don't require real time updates.

thanks for this - I thought I could activate it with "last_call" to reload the integration when I said the word "timer" but last_called does not update anymore either without a reload so I am fresh out of ideas

[dpgh947]

I used to use IFTTT before I really got in to HA, and I remembered that had a trigger for when an alexa timer goes off. I just looked and that trigger is still there, and interestingly it still works, so there's a mechanism of sorts somewhere that is still in place...

[dpgh947]

I think what we are seeing is the gradual complete shutdown of this api by amazon (just about). I am now not seeing ANY updates to media player entities coming through at all. I have had to completely change the way I handle the "last alexa" - I now cannot maintain this based off the activity that used to be seen whenever any device was spoken to. The only way it will work now is to call the update_last_called service whenever I am about to send a TTS announcement and I have not specified a target (in other words, I want it sent to the device spoken to). That service still works at the moment...

[popy2k14]

Any updates on this? None of my automations work properly, lack of entity updates from the integration.

Can we have an "workround" version which just polls, until the notification method work again (or is shutdown completly :-( )

thx

[NivaBarCar]

I have no update but a workaround for alarms that I have tested for a while and that I'm using now. (sorry if the code section is not working fine I tried)

Information Workaround works for:

• Trigger an automation at the time the alarm goes off

Workaround does not work for:

• Trigger an event before the alarm goes off

Description

1. Create a boolean trigger helper switch via settings / devices / helpers
2. Add the "Emulated Hue" integration via editor and configuring the configuration.yaml (example - exchange - with spaces please):

emulated_hue: --type: alexa --host_ip: your_home_assistant_ip --listen_port: 80 --expose_by_default: false --entities: ----input_boolean.your_alarm_trigger_helper_name: ----name: "Alarm trigger helper" ----hidden: false

3. Save configuration.yaml and restart HomeAssistant
4. After reload has finished open your Alexa app and ask her to detect new devices
5. After a while she will announce to have found new devices
6. Within section "lamps" you will find a lamp called like your trigger alarm helper
7. Within alarm settings set a new alarm as you wish and activate a "wake-up light"
8. Within general alarm settings you can select the wake-up light for each Amazon device separately
9. Here select the "lamp" named like your alarm trigger helper
10. You can adjust the time before the alarm but this has no effect on the trigger
11. If everything works fine you can see a little star next to your set alarm within Alexa app

Now when the alarm goes off the trigger will be switched "on" within HomeAssistant. Within HomeAssistant now you can set up an automation when the helper is switched "on" and react on this and after going through your steps deactivate the trigger again so that it works again next time.

Hope that helps some of you to achieve something independent from Amazon API.

[elarsson1]

I've implemented a similar solution to @NivaBarCar above, however I have it able to trigger up to an hour before the scheduled alarm.

Instead of using Emulated Hue, I'm exposing my device to Alexa using the standard Alexa Skill/Home Assistant Cloud integration. In addition, I'm using a virtual "light" entity instead of the input_boolean. The virtual light entity is created by the Virtual Components custom component:

https://github.com/twrecked/hass-virtual

By exposing a dimable light to Alexa instead of an on/off switch, the wake-up light before alarm setting in Alexa works. You can specify up to an hour before the alarm time. Alexa will start with the "light" set to low brightness and gradually increase it to 100% by the time alarm time is reached. With a switch, that setting is ignored and she simply turns on the light at the alarm time.

My automations don't care about the dimming level. They simply trigger when the "light" transitions to on, so they fire as soon as Alexa starts the wake up lighting sequence.

[NivaBarCar]

I've implemented a similar solution to @NivaBarCar above, however I have it able to trigger up to an hour before the scheduled alarm.

Thanks for sharing @elarsson1. You are right by mentioning that in case you use the cloud integration this works "better". My solution is based on not having the integration and not paying anything additional to use the Nabu Casa Service. But very nice that you are sharing your solution as well!

[oneseventhree]

Did anyone figure out a way to fix the timer/last called feature. I just want the timers to show without spamming the API