Ring Intercom can remain available while the Ring runtime/listener is unhealthy; reload fixes it

[rndm2]

The problem

I have a Ring Intercom configured through the official Home Assistant Ring integration.

Sometimes the Ring Intercom stops responding. The most visible symptom is that the intercom/open-door capability still appears available/active in Home Assistant, but the actual intercom does not respond. Reloading the Ring integration fixes the problem.

From the current Ring integration architecture, the user-facing availability of Ring event/binary entities is mainly tied to listen_coordinator.event_listener.started. That is not enough to prove that the Ring Intercom/API/listener path is actually healthy. In practice, Home Assistant can continue to present the integration as usable while the Ring runtime is degraded and a reload is required.

What I expected to happen

If the Ring runtime/API/listener becomes unhealthy, the integration should either:

• mark affected Ring Intercom entities unavailable/degraded, or
• recover/restart the affected listener/coordinator internally, or
• expose enough diagnostics for Home Assistant to show the connection problem clearly.

The open-door/intercom capability should not look healthy if the underlying Ring runtime is no longer able to operate it.

What happened instead

The Ring Intercom may continue to look available/active in Home Assistant, but it does not respond. Reloading the Ring integration restores operation.

Why I think this is a Ring integration health-model issue

I built a small external watchdog as a workaround. The initial entity-state based approach was not useful because the entities could look healthy while the connection was not.

The useful workaround was to monitor the Ring config entry runtime instead:

• entry.runtime_data.devices_coordinator
• entry.runtime_data.listen_coordinator
• listen_coordinator.event_listener.started
• devices_coordinator.last_update_success
• active API probe through the devices coordinator
• controlled reload of the Ring config entry when the runtime appears degraded

That workaround exists only because the official integration does not expose a reliable runtime health signal for Ring Intercom/listener/API state.

Proposed direction

The Ring integration should track and expose runtime health for the Ring config entry, for example:

• last successful devices coordinator update
• listener started/stopped state
• listener start failure
• listener/API degraded reason
• optional repair issue if the listener/API is unhealthy
• internal restart/reload path for the listener/coordinator when degraded

This would avoid users needing custom watchdogs that inspect private Ring runtime internals.

What version of Home Assistant Core has the issue?

core-2026.6.1

What was the last working version of Home Assistant Core?

Unknown. I do not know whether this is a regression or a long-standing missing health model.

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Ring

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ring/

Diagnostics information

I can provide diagnostics/logs if needed. The important observation is that reloading the Ring config entry restores the Intercom behavior.

Additional information

I am not reporting the custom watchdog as a Home Assistant issue. The custom watchdog was only used to validate that monitoring Ring runtime/coordinator health is more useful than monitoring entity states.

[home-assistant]

Hey there @sdb9696, mind taking a look at this issue as it has been labeled with an integration (ring) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ring can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign ring Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the issue.

_{^{(message by CodeOwnersMention)}}

---

@rndm2 Thanks for reporting this issue!

Before we dive in, please make sure this isn't a duplicate by searching through existing issues. Also check recently closed issues, as your problem might already be fixed but not yet released.

https://github.com/home-assistant/core/issues?q=%20label%3A%22integration%3A%20ring%22%20
_{^{(message by IssueContext)}}

---

ring documentation
ring source
_{^{(message by IssueLinks)}}

[rndm2]

What I built as a workaround / proof of concept

I built a small custom helper integration:
https://github.com/rndm2/ring_intercom_health

[rndm2]

I have more precise information about the failure mode.

This does not look like the Ring Intercom command path being completely broken. In my case, the command/API path can still work, including opening the door. What breaks is the feedback path:

• event.entrance_hall_door_doorbell stops firing
• event.entrance_hall_door_button stops firing
• sensor.entrance_hall_door_timestamp stops updating
• automations depending on those entities become unusable
• manually reloading the Ring integration restores the feedback path

The relevant logs show the Firebase/FCM receiver failing and shutting down:

firebase_messaging.fcmpushclient: Unexpected exception during read
TimeoutError: SSL shutdown timed out
firebase_messaging.fcmpushclient: Shutting down push receiver due to 3 sequential errors of type ErrorType.CONNECTION

Around the same time, Home Assistant also logs:

homeassistant.components.ring.coordinator: Error fetching devices data: Error communicating with Ring API

So the likely failure mode is:

Ring command/API path may recover or continue working,
but the Ring realtime feedback path dies after the FCM push receiver shuts down.
The Ring integration does not appear to recover that listener/push path by itself.
A manual Ring config-entry reload recreates the runtime/listener and restores feedback.

This also explains why entity availability is misleading. The Ring event/binary entities can still appear available because availability is tied to event_listener.started, but that flag does not necessarily prove that the underlying FCM receiver is still alive or delivering notifications.

Related issues that look similar:

• Ring Intercom ding event does not update #131527 Ring Intercom ding event does not update
• Ring addon doesn't detect Ding or motion #134431 Ring addon doesn’t detect Ding or motion
• Ring intercom integration does not update ding binary sensor #115466 Ring Intercom integration does not update ding binary sensor
• Ring integration stops updating motion event requiring integration reload #128597 Ring integration stops updating motion event requiring reload
• Ring „Ding“ event not updating #157764 Ring “Ding” event not updating

I think the Ring integration needs a listener-health/recovery model, not just entity availability based on event_listener.started.

Possible fixes in Home Assistant Core:

• expose Ring listener runtime health as diagnostics
• detect when the underlying push/FCM receiver has stopped or become inconsistent
• restart/recreate the Ring listener when the receiver shuts down
• fall back to config-entry reload only when listener restart is not possible
• mark feedback entities unavailable/degraded if listener delivery is not actually healthy

I built an external watchdog as a workaround. The useful part was not watching entity states, because the entities can be stale/misleading. The useful part was watching Ring runtime internals: devices_coordinator, listen_coordinator, event_listener.started, and private listener/receiver flags. That is why I think this belongs in the official integration or in the underlying python-ring-doorbell listener implementation.

[MultivitaminJuice]

Thorough write-up — and the FCM traceback you quoted (TimeoutError: SSL shutdown timed out → 3× ErrorType.CONNECTION → shutdown) is a known root cause, with fixes already in flight upstream in firebase-messaging, the library the Ring listener uses:

• Recover from transient read failures instead of aborting the client sdb9696/firebase-messaging#38 treats that TimeoutError (and IncompleteReadError) as transient and reconnects without advancing the abort counter, so the receiver no longer shuts itself down — exactly the case you hit. Harden encrypted push payload decoding sdb9696/firebase-messaging#37 hardens the related decrypt path, and FCMPushClient._listen() waits longer for _connect_with_retry() if necessary sdb9696/firebase-messaging#36 makes the listener wait long enough to reconnect. All are CI-green; I've run the first two on a Ring setup for weeks with no more shutdowns.

Your health-model idea is still valuable as defense-in-depth, though: even with the receiver no longer dying for this reason, having the integration detect/surface/recover a degraded listener would catch other failure modes and the "looks available but isn't" gap. So they're complementary — fix the root cause in the library, and harden the integration in case the listener ever does die. (The same maintainer owns firebase-messaging, python-ring-doorbell and the HA Ring integration, so all three land in one place.)

[rndm2]

I am wondering, should I close this issue then

[MultivitaminJuice]

I'd keep it open. The firebase-messaging PRs fix the root cause (the receiver dying), but your proposal — a listener health/recovery model so the integration stops showing "available" while the feedback path is dead — is a separate layer they don't cover, and would still help with other failure modes. Since the specific FCM shutdown is being handled upstream, you might (if you like) keep the focus on the health-model side and let the Ring code owner decide how to track it — but that's entirely your call.

[zondajag]

What happened with those other PR's. It ooks like the people who raised them just gave up instead of answering the reviewers questions?

[zondajag]

sdb9696/firebase-messaging#44
This appears to hint at the problem many are facing. Ring do appear to be changing things around how encryption keys are handled so that could also be related to how this API has degraded recently (something I read on their website about lock and throw away the key)