Timers still not updating reliably after 4.6.5 fix #1976

dpgh947 · 2023-06-30T11:30:42Z

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). : 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?

The text was updated successfully, but these errors were encountered:

sambarlick · 2023-07-01T07:06:22Z

I'm also having this issue too.

dpgh947 · 2023-07-01T10:23:26Z

I see in the discussion here - #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 · 2023-07-01T19:35:47Z

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 · 2023-07-03T06:18:05Z

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 · 2023-07-03T09:27:35Z

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 · 2023-07-03T14:45:52Z

@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 · 2023-07-03T14:59:13Z

@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 · 2023-07-03T15:42:38Z

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

popy2k14 · 2023-07-03T20:35:57Z

@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 · 2023-07-03T20:36:39Z

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

elarsson1 · 2023-07-04T22:25:37Z

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 · 2023-07-05T04:19:15Z

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 · 2023-07-05T08:16:12Z

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 · 2023-07-05T18:16:19Z

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 · 2023-07-05T21:03:40Z

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 · 2023-07-06T17:38:59Z

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

dpgh947 · 2023-07-06T18:01:18Z

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 · 2023-07-12T14:57:38Z

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 · 2023-07-12T15:09:10Z

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 · 2023-07-12T15:41:38Z

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 · 2023-07-12T21:36:34Z

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 · 2023-07-12T21:59:03Z

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 · 2023-07-13T20:44:58Z

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 · 2023-07-14T00:11:20Z

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 · 2023-07-14T06:37:50Z

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 · 2023-07-15T19:46:48Z

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 · 2023-08-02T09:08:05Z

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.

Ulli2k · 2023-08-03T15:44:30Z

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

popy2k14 · 2023-08-04T15:50:19Z

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 · 2023-08-08T03:50:37Z

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 · 2023-08-08T07:16:22Z

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 · 2023-08-26T23:48:07Z

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 · 2023-08-27T05:47:01Z

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.

oneseventhree · 2023-08-27T12:13:51Z

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 · 2023-08-28T14:25:24Z

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 · 2023-08-30T08:33:44Z

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 · 2023-09-04T10:22:08Z

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 · 2023-09-06T11:19:37Z

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

Create a boolean trigger helper switch via settings / devices / helpers
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

Save configuration.yaml and restart HomeAssistant
After reload has finished open your Alexa app and ask her to detect new devices
After a while she will announce to have found new devices
Within section "lamps" you will find a lamp called like your trigger alarm helper
Within alarm settings set a new alarm as you wish and activate a "wake-up light"
Within general alarm settings you can select the wake-up light for each Amazon device separately
Here select the "lamp" named like your alarm trigger helper
You can adjust the time before the alarm but this has no effect on the trigger
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 · 2023-09-06T11:56:51Z

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 · 2023-09-06T12:02:31Z

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 · 2023-09-06T12:04:17Z

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

elarsson1 · 2023-09-06T12:37:18Z

@NivaBarCar I suspect you could get this to work with Emulated Hue just as well, rather than relying on the Alexa skill and the HA Cloud subscription. The key, I believe, is using a light entity instead of an input_boolean (which shows up in Alexa as an on/off switch) as the trigger. You could create a virtual light, that is dimmable, using the Virtual Components and expose that via Emulated Hue instead of the input_boolean and then Alexa would be able to turn it on at low brightness before your schedule alarm time.

popy2k14 · 2023-09-06T12:41:42Z

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

Create a boolean trigger helper switch via settings / devices / helpers

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

Save configuration.yaml and restart HomeAssistant

After reload has finished open your Alexa app and ask her to detect new devices

After a while she will announce to have found new devices

Within section "lamps" you will find a lamp called like your trigger alarm helper

Within alarm settings set a new alarm as you wish and activate a "wake-up light"

Within general alarm settings you can select the wake-up light for each Amazon device separately

Here select the "lamp" named like your alarm trigger helper

You can adjust the time before the alarm but this has no effect on the trigger

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.

:-)
that's the exact workaround i have implemented for all my wakup light's and the work reliable!

But i have automations which checks if something is playing and if not play something.
That does'nt work because the integration has no current play status.

Is there also an workaround?

popy2k14 · 2023-09-10T18:26:05Z

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.

Any chance to get volume updates working?
Thx

amaisano · 2023-09-11T18:42:49Z

I was going to implement @elarsson1 's idea but found out Timers (which I used for tons of cool automations) don't provide any Alexa-side routine or trigger effects like the wake-up lighting. So i'm still looking for a better way to workaround this for timers. I suppose I can create a routine that creates an alarm when asked a certain way, which might be the way to do it for now.

As of now, I've increased my "completely reload the Alexa integration" automation from every 12 hours to every hour, and even that is fairly useless for timers, since A) it doesn't capture snooze command changes and B) many timers are created on the fly and expire within the hour.

I could increase the integration reload frequency more but I read I will start getting throttled...

Bastian007 · 2023-09-15T10:56:59Z

Issue still exist for newest update 4.7.0

popy2k14 · 2023-09-15T12:13:15Z

@alandtse
Is it possible to get an poll feature and/or poll service?

So if users automations are using data from Alexa (timers, alarms, volume, ...) are working again?
I know we can't poll too often, but maybe some automations can work again.

Thx a lot

GRClark · 2023-09-17T11:55:07Z

Updated to 4.7.1 and still not working for timers.

ifflanb · 2023-09-18T05:17:52Z

Same for me 4.7.1 is still broken.

amaisano · 2023-09-18T15:14:20Z

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.

dpgh947 · 2023-09-18T15:16:01Z

The only thing that will fix timers is Amazon reverting the api changes they made which broke them in the first place. The only dependency I had on timers in HA was an automation that announced in the lounge if a kitchen timer went off. It was pretty useful when I was cooking and wandering about, it's a shame it's gone, but I've quickly learned to do without it.

alandtse · 2023-09-22T06:24:11Z

Follow #1953 for update since it's the same root cause now. Closing dupe.

alandtse added bug Something isn't working help wanted Extra attention is needed good first issue Good for newcomers labels Jul 19, 2023

alandtse mentioned this issue Aug 8, 2023

Device entity States not updating #1992

Closed

alandtse added the help wanted Extra attention is needed label Aug 27, 2023

github-actions bot removed the help wanted Extra attention is needed label Aug 28, 2023

alandtse closed this as completed Sep 22, 2023

alandtse mentioned this issue Sep 29, 2023

fix: add http2 push to replace websocket #2040

Merged

Timers still not updating reliably after 4.6.5 fix #1976

Timers still not updating reliably after 4.6.5 fix #1976

Comments

dpgh947 commented Jun 30, 2023

sambarlick commented Jul 1, 2023

dpgh947 commented Jul 1, 2023

tbclark3 commented Jul 1, 2023

popy2k14 commented Jul 3, 2023

dpgh947 commented Jul 3, 2023

popy2k14 commented Jul 3, 2023 • edited Loading

dpgh947 commented Jul 3, 2023 • edited Loading

dpgh947 commented Jul 3, 2023

popy2k14 commented Jul 3, 2023

popy2k14 commented Jul 3, 2023

elarsson1 commented Jul 4, 2023

popy2k14 commented Jul 5, 2023

dpgh947 commented Jul 5, 2023 • edited Loading

jane-t commented Jul 5, 2023 • edited Loading

dpgh947 commented Jul 5, 2023

jane-t commented Jul 6, 2023

dpgh947 commented Jul 6, 2023

amaisano commented Jul 12, 2023

amaisano commented Jul 12, 2023 • edited Loading

dpgh947 commented Jul 12, 2023 • edited Loading

amaisano commented Jul 12, 2023

dpgh947 commented Jul 12, 2023

popy2k14 commented Jul 13, 2023

toadleyb commented Jul 14, 2023

dpgh947 commented Jul 14, 2023

NivaBarCar commented Jul 15, 2023 • edited Loading

dpgh947 commented Aug 2, 2023

Ulli2k commented Aug 3, 2023

popy2k14 commented Aug 4, 2023

beniffland commented Aug 8, 2023

alandtse commented Aug 8, 2023

oneseventhree commented Aug 26, 2023

colinnewman2000 commented Aug 27, 2023

oneseventhree commented Aug 27, 2023

dpgh947 commented Aug 28, 2023

dpgh947 commented Aug 30, 2023

popy2k14 commented Sep 4, 2023

NivaBarCar commented Sep 6, 2023 • edited Loading

elarsson1 commented Sep 6, 2023

NivaBarCar commented Sep 6, 2023

oneseventhree commented Sep 6, 2023

elarsson1 commented Sep 6, 2023

popy2k14 commented Sep 6, 2023

popy2k14 commented Sep 10, 2023

amaisano commented Sep 11, 2023

Bastian007 commented Sep 15, 2023

popy2k14 commented Sep 15, 2023

GRClark commented Sep 17, 2023

ifflanb commented Sep 18, 2023

amaisano commented Sep 18, 2023

dpgh947 commented Sep 18, 2023

alandtse commented Sep 22, 2023

popy2k14 commented Jul 3, 2023 •

edited

Loading

dpgh947 commented Jul 3, 2023 •

edited

Loading

dpgh947 commented Jul 5, 2023 •

edited

Loading

jane-t commented Jul 5, 2023 •

edited

Loading

amaisano commented Jul 12, 2023 •

edited

Loading

dpgh947 commented Jul 12, 2023 •

edited

Loading

NivaBarCar commented Jul 15, 2023 •

edited

Loading

NivaBarCar commented Sep 6, 2023 •

edited

Loading