Alexa-Notify-Bridge: Persistent yellow ring notifications for your Echo devices

Share your Projects!
,
1

Hi everyone!

Since I started using Home Assistant, I’ve been trying to find a way to send persistent notifications to my Alexa devices. Until now, I’ve been using Alexa Media Player and the official integration, but they only read the notification out loud at the exact moment it triggers. If you’re not in the room or don’t hear it, the notification is lost forever.

For example, I would have an automation saying “The washing machine has finished”, but if I wasn’t around to hear it, the wet clothes would just sit there. I know you can also send notifications to your phone or loop the TTS every X minutes, but the repeating announcements get quite annoying.

I’ve always wanted to use Alexa’s native notification feature: it makes a small chime and the LED ring pulses yellow until you ask, “Alexa, what are my notifications?”. Then she reads them out to you. But unfortunately, there wasn’t an easy way to send custom text notifications from HA this way.

I was aware of the Notify Me skill, but it’s not available in my country (Spain), and I didn’t like the idea of routing my notifications through third-party servers anyway.

The other day, while playing around with AI and seeing how these new coding agents work, I thought: “Maybe it’s not that complicated to build my own solution with the help of AI”… so I went for it!

After spending some time refining the code, improving security, adding logs, and documenting the process, I think it turned out pretty well! I’ve decided to open-source it in case it’s useful to anyone else here:

:backhand_index_pointing_right: GitHub - R91g/Alexa-Notify-Bridge · GitHub

Main Features:

  • Easy to use: Just send a simple local HTTP POST request (via a HA rest_command) to generate a persistent notification on your Alexa account.
  • :spouting_whale: Dockerized: Ready to deploy in seconds with Docker Compose.
  • :locked: Privacy Focused: It doesn’t rely on third-party servers (other than Amazon’s own API). Your credentials stay securely on your local server.

I’ve also included a quick guide in the README on how to set it up with Home Assistant using a script wrapper, so it shows a nice text input box in the visual Automation UI.

Let me know what you think, and I hope you find it useful!

2

I’ve just updated it so it can also be used as a Home Assistant app (formerly add-ons)

3

I have not tried this yet but will soon. Thought about what might be an interesting combination… your bridge + Alexa Media Player.

I made a combo of AMP + card + script that does TTS announcements. Would be cool to roll this into your add-on so TTS could be both immediately, and stored for playback later as a ‘yellow ring notification’ (or both - stored until cleared by asking for notifications)

4

Yes, that’s exactly how I use it! When a notification triggers, it announces over the speakers and sends an alert to my phone, while leaving the persistent notification on Alexa. That way, if I missed the voice announcement or was away, the yellow ring reminds me once I’m back (I used to check phone notifications while out and completely forget about them by the time I got home).

Installing the Home Assistant add-on is very straightforward now. The only part that takes a few minutes is setting up the custom skill in the Amazon Developer Console. If you run into any issues with that, just let me know and I’ll help you out.

One thing to keep in mind: if your Amazon account is enrolled in the Alexa+ early access preview, the physical alerts on the Echo (the yellow LED ring and chime) might not trigger. The notification still arrives in your account and Alexa will read it if you ask, but the hardware light doesn’t turn on. Leaving the Alexa+ preview and switching back to standard Alexa immediately restores the yellow ring.

AI suggests that Amazon is testing new backend routing for Alexa+ that currently bypasses the classic notification pipeline to physical Echo hardware—it even broke delivery alerts for standard Amazon packages on my account. I’d love to know if anyone else tests this to see if it happens across all accounts on Alexa+ or just certain rollout groups.

5

I reviewed your integration. It have a complex setup so I was thinking it would be nice to have it without requiring the overhead of an add-on, and also have it natively leverage Alexa Media Player’s benefits (only if the user installs AMP - totally optional).

AMP has the ability to target each-separate Alexa device (I use this a lot) or all Alexa devices on the account. Your bridge can only send to a ‘user’, no device targeting, you get all devices no matter what.

I did some brainstorming with my buddy Claude. We came up with this, lmk what you think…

A small native HA integration that replaces the bridge and uses Alexa Media Player for speech.

  • Port the bridge’s core (token cache, Proactive Events POST, rate limiter, expiry clamping) to run inside HA, using HA’s own HTTP session. No container.
  • Takes the Client ID, Client Secret and region through a config flow with a credential check, replacing the .env file.
  • Exposes one action, for example alexa_notify.send, with message, delivery (speak / announce / quiet), devices and expiry_hours.
  • quiet goes straight to Amazon’s official API.
  • speak and announce call notify.alexa_media with the chosen devices, so Alexa Media Player does the device targeting.
  • Alexa Media Player is ONLY a soft dependency: if it’s not installed or its login is down, speak/announce fail with a clear error and quiet keeps working.

Benefits over current bridge:

  • One action instead of a bridge, a REST command and a script.
  • No open HTTP endpoint, so the unauthenticated-/notify risk goes away completely.
  • Credentials live in HA’s config entry instead of an .env file.
  • Errors show up in HA’s logs and repairs instead of a container log.

Effort to make happen: 300–400 lines of Python across __init__.py, config_flow.py, services.yaml, manifest.json and translations. The bridge’s /history endpoint could become a “last notification” sensor if wanted.

6

Thanks for sharing your thoughts!

Just to clarify a few architectural details and how both the Alexa API and the Add-on actually work under the hood:

  1. Targeting individual devices:

    The official Amazon Proactive Events API strictly targets an Amazon Customer ID (the whole household) by design—there is no parameter in Amazon’s API to trigger a yellow LED ring on a specific Echo serial number. The persistent visual alert is meant to be ambient across the home so you can ask whichever Echo is closest to read it. If you want targeted voice announcements in a specific room, calling notify.alexa_media alongside this bridge in a simple 2-action Home Assistant automation already achieves that without tightly coupling two unrelated integrations.

  2. Endpoint security and local network:

    The bridge runs strictly within your private local network (or internal Home Assistant Docker network) with zero need to expose any ports to the internet. Furthermore, the bridge already supports API Key authentication (configurable directly in the Add-on UI and passed via x-api-key header), so the endpoint is fully secured if you want to restrict local access.

  3. Credentials and UI config:

    The Home Assistant Add-on already uses the native Home Assistant UI for credentials (via the Add-on Configuration tab), so there is no need to touch .env files or manage manual volumes when running HA OS/Supervised.

  4. The real friction vs. Privacy and DIY:

    The real friction and complexity does not lie in configuring the bridge itself—which is now just filling in fields in the Add-on UI—but in creating the custom skill and configuring the Amazon Developer Console. That step is completely unavoidable regardless of whether this runs as an add-on or a native integration. The only way to eliminate the developer console would be running a public, multi-tenant cloud skill like the old Notify Me. Doing that would completely defeat the self-hosted, private, and DIY spirit of the project, introducing cloud hosting costs and routing your home alerts through external third-party servers.

  5. Standalone bridge vs. Custom Component:

    Keeping this as a lightweight bridge allows it to remain platform-agnostic (usable by Node-RED, curl, scripts, or external webhooks, not just HA). A native HACS custom component could be an interesting side project for HA Container users who don’t run add-ons, but for HA OS, the Add-on + a REST command gets the job done cleanly without adding maintenance overhead.

It is true that turning this into a HACS integration wouldn’t be particularly difficult and would feel slightly more user-friendly within Home Assistant, but as mentioned, that isn’t where the real bottleneck lies.

7

understood… I have a proposal for a minor addition (not an actual change) to allow your add-on to route commands to AMP… this it becomes the single entry point and is easier for uses to have ‘one place’ for Alexa notifications. I’ll post it on the repo for discussion