alexa_media_player: Timers still not updating reliably after 4.6.5 fix
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?
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 6
- Comments: 61 (6 by maintainers)
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:The result is a delay between the push coming in and the various API calls as seen here (edited):
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:
Workaround does not work for:
Description
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
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.
Sorry if I caused confusion… it’s just the updates in my latest post, forget my first attempt, so only adding the
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?