alexa_media_player: Timers still not updating reliably after 4.6.5 fix

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

I’m also having this issue too.

Please review the release notes. Neither of the releases that came out recently promise or describe any fixes to this situation. Do not expect it to be magically fixed when the number goes up.

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

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.

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.

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.

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.

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

1. Save configuration.yaml and restart HomeAssistant
2. After reload has finished open your Alexa app and ask her to detect new devices
3. After a while she will announce to have found new devices
4. Within section “lamps” you will find a lamp called like your trigger alarm helper
5. Within alarm settings set a new alarm as you wish and activate a “wake-up light”
6. Within general alarm settings you can select the wake-up light for each Amazon device separately
7. Here select the “lamp” named like your alarm trigger helper
8. You can adjust the time before the alarm but this has no effect on the trigger
9. 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.

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…

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

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.

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.

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?