Native Doorbell / Intercom Incoming Session Experience in the Home Assistant Companion

[pr4y27n2yn-oss]

Describe the feature

I'd like the Home Assistant Companion App to support a first-class incoming Doorbell / Intercom experience.

When Home Assistant detects that someone is ringing a doorbell or video intercom, the Companion App should be able to present it as a prominent real-time incoming interaction, similar to the experience provided by dedicated video-doorbell apps, rather than only as a conventional push notification.

The intended flow is:

Doorbell rings → Home Assistant → Companion App → native incoming interaction → Answer → open the relevant Home Assistant intercom view.

When the user taps "Answer", the Companion App should open directly to a configurable Home Assistant destination (for example, a dashboard/view containing the live camera, two-way audio where available, door/gate controls, etc.).

The feature should be vendor-neutral. The Companion App should not need to know whether the event originated from BTicino, UniFi Protect, Reolink, DoorBird, KNX, MQTT, ESPHome, SIP, or another integration.

Conceptually, Home Assistant would expose a semantic presentation type such as "doorbell" or "intercom", with information such as:

• a unique session/event ID;
• the Home Assistant URI/view to open when answered;
• an optional timeout;
• cancellation/expiration of the ringing event.

The exact API and naming should of course be determined by the Home Assistant maintainers.

Importantly, I am not proposing that an ordinary notification should simply be disguised as a telephone call.

The Companion App should use the most appropriate Apple-supported native presentation mechanism for the actual capabilities of the session. If a call-style native interface is not technically or policy-compliant for a particular scenario, it should gracefully fall back to the strongest appropriate time-sensitive/actionable notification.

The important feature is the Home Assistant abstraction: a doorbell/intercom event is a real-time incoming interaction with a lifecycle (ringing → answer/decline/cancel/timeout), rather than just another notification.

Use cases

My immediate use case is a video intercom integrated into Home Assistant.

Home Assistant already knows that somebody has rung the doorbell and can provide the camera and the controls required to interact with the entrance.

The missing part is the mobile experience.

Today, the event can be delivered as a notification. Even a critical or actionable notification, however, is semantically different from somebody actively waiting at the door.

A typical daily interaction should look like this:

1. A visitor presses the front gate or door intercom.
2. Home Assistant receives the ringing event.
3. My iPhone immediately presents a prominent incoming Doorbell / Intercom interaction.
4. I can Answer or Decline.
5. If I press Answer, Home Assistant Companion opens directly to my intercom dashboard/view.
6. I can immediately see the visitor and, depending on the underlying integration, talk to them, unlock the door, open the gate, or use other Home Assistant controls.
7. If the visitor leaves before I answer, Home Assistant can cancel the incoming interaction so that it does not remain as a stale notification.

This would be useful far beyond one specific intercom.

For example, the same mechanism could be used with:

• video doorbells;
• apartment intercoms;
• driveway/gate intercoms;
• local SIP-based intercoms;
• KNX installations;
• ESPHome or MQTT DIY doorbells;
• other Home Assistant integrations capable of detecting a ringing event.

It would also be particularly valuable for people who deliberately use Home Assistant as their unified interface and do not want to keep each manufacturer's mobile app installed simply to obtain a good incoming-doorbell experience.

The key difference from a critical notification is:

A critical notification means:
"Something important happened."

A doorbell/intercom session means:
"Someone is waiting for me right now and expects a response."

That interaction naturally has ringing, Answer, Decline, Cancel and Timeout states.

Examples

Dedicated video-doorbell/intercom applications already provide this kind of experience.

For example, Netatmo's doorbell experience can present an incoming doorbell event to the iPhone in a call-like, high-attention interface, allowing the user to immediately respond to the visitor.

This is the kind of user experience I am proposing for Home Assistant, but implemented as a vendor-neutral Home Assistant capability.

The Home Assistant version could be even more flexible because "Answer" would not have to open a manufacturer-specific interface. It could open a user-configurable Home Assistant dashboard/view.

For example:

Front Gate rings

    ↓

iPhone displays:

    FRONT GATE
 Incoming doorbell

[Decline]   [Answer]

    ↓ Answer

Home Assistant Companion opens:

/dashboard-intercom/front-gate

    ↓

Live camera
Two-way audio (if supported)
Open gate
Unlock door
Entrance lights
Other HA controls

The important point is that Home Assistant already provides many of these individual building blocks. The proposed feature would connect them into a first-class incoming-doorbell mobile workflow.

Anything else?

I think it is important to separate the desired Home Assistant abstraction from the specific Apple implementation.

I am NOT proposing misuse of PushKit/CallKit simply to make arbitrary Home Assistant notifications look like phone calls.

Apple places specific requirements on VoIP pushes and communication sessions, so the Companion App should use CallKit or other communication frameworks only where the underlying session and Apple's current requirements make that appropriate.

The proposal is instead for Home Assistant to define a first-class Doorbell / Intercom incoming-session concept and let the Companion App choose the best platform-supported presentation.

A possible incremental implementation could be:

Phase 1:

• semantic doorbell/intercom incoming event;
• prominent native presentation;
• Answer / Decline;
• configurable Home Assistant deep link;
• timeout.

No new audio/video transport would be required.

Phase 2:

• unique session ID;
• server-side cancellation;
• ringing-state synchronization;
• expiration.

Phase 3:

• where the underlying Home Assistant integration exposes genuine two-way communication capabilities, investigate richer native communication integration.

There should always be graceful fallback to the existing time-sensitive/critical/actionable notification mechanisms where the richer native presentation is unavailable.

Security-sensitive operations should remain under Home Assistant's existing authentication and authorization model. Pressing Answer should open the interaction; it should not automatically authorize actions such as unlocking a door or opening a gate.

This also makes the proposal compatible with multiple Home Assistant servers: the incoming session should retain its originating server context so that Answer opens the correct server and view.

If the maintainers consider this abstraction appropriate for the Companion App, I would be interested in helping move it beyond a feature request, including requirements refinement, testing on a real video-intercom installation, UX testing, documentation, and potentially contributing to or sponsoring implementation work.

I would particularly appreciate maintainer feedback on whether extending the existing Companion notification infrastructure with a semantic incoming-session type is the preferred architectural direction.

[lboue]

I think this is becoming especially relevant now with Matter 1.5 and the upcoming support for Matter Video Doorbells in Home Assistant.

For Matter doorbells, I see two distinct layers that would be useful to keep separate:

1. Ring detection: the doorbell reports an incoming call/ring to Home Assistant, which can trigger automations and notifications.
2. Incoming session UX: the Companion App could present the ring as an actual incoming interaction (Answer / Decline), rather than just a regular notification, and then open the appropriate HA view for video/audio.

The second part is where this discussion seems particularly valuable. A vendor-agnostic “Doorbell / Intercom Session” abstraction could work not only for Matter, but also for existing integrations such as Reolink, DoorBird, UniFi, SIP, etc.

This would also allow Matter support to evolve incrementally: start with ring detection + a proper incoming notification/session, then add video and two-way audio as the underlying Matter support matures.

I’d be very interested in seeing this discussion revived, especially in the context of the current Matter Video Doorbell work.

[Particpant]

This is probably one of the largest "missing pieces" in HA / Companion, on Android or iOS.
People can cludge together something, but it's difficult, brittle, and in most cases, not really ready as an experience for a nontechnical audience.