2-Way audio with Amcrest AD410

[BlackBeltPanda]

I'm currently working on getting 2-way audio working with my Amcrest AD410 video doorbell. The configuration is fairly simple, but I may have misconfigured or overlooked something. If I open the 2-way stream on the Go2RTC dashboard, 2-way audio works just fine as long as another stream to it isn't open. However, while the microphone button does appear in the frigate card, using it does not seem to be working for me; no audio appears to be transmitted to the camera. I double-checked that there was no other consumer for the 2-way audio stream except the frigate card.

Frigate config:

mqtt:
  host: localhost
  user: "{FRIGATE_MQTT_USER}"
  password: "{FRIGATE_MQTT_PASSWORD}"

detectors:
  coral:
    type: edgetpu
    device: pci

ffmpeg:
  hwaccel_args: preset-nvidia-h264
  input_args: preset-rtsp-restream-low-latency
  output_args:
    record: preset-record-generic-audio-copy

go2rtc:
  streams:
    doorbell:
      - rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@{FRIGATE_CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
      - "ffmpeg:doorbell#backchannel=0#audio=aac"
    doorbell_2way_audio:
      - rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@{FRIGATE_CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0
  webrtc:
    candidates:
      - localhost:8555
      - stun:8555

birdseye:
  enabled: false

cameras:
  doorbell:
    ffmpeg:
      inputs:
        - path: rtsp://localhost:8554/doorbell
          roles:
            - record
            - detect
    objects:
      track:
        - person
      filters:
        person:
          mask:
            - 1280,672,1128,634,1026,698,1280,885
            - 486,432,660,425,657,487,481,486
            - 674,412,916,412,910,499,672,501
    record:
      enabled: true
      retain:
        days: 3
        mode: motion
    zones:
      porch:
        coordinates: 0,960,0,701,65,673,383,732,917,703,1249,960
    mqtt:
      required_zones:
        - porch

detect:
  width: 1280
  height: 960
  stationary:
    interval: 25
  max_disappeared: 50

objects:
  filters:
    person:
      threshold: 0.65

snapshots:
  enabled: true
  clean_copy: false

ui:
  live_mode: webrtc

Go2RTC Config:

api:
  origin: '*'
log:
  format: text
rtsp:
  default_query: mp4
streams:
  doorbell:
  - rtsp://${CAMERA_USERNAME}:${CAMERA_PASSWORD}@${CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
  - ffmpeg:doorbell#backchannel=0#audio=aac
  doorbell_2way_audio:
  - rtsp://${CAMERA_USERNAME}:${CAMERA_PASSWORD}@${CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0
webrtc:
  candidates:
  - localhost:8555
  - stun:8555

Card Config:

type: custom:frigate-card
cameras:
  - camera_entity: camera.doorbell
    live_provider: go2rtc
    go2rtc:
      modes:
        - webrtc
      stream: doorbell_2way_audio
    frigate:
      camera_name: doorbell_2way_audio
      url: https://<Frigate URL>
view:
  default: live
live:
  auto_mute: never
  auto_unmute: all
  microphone:
    always_connected: true
  layout:
    fit: contain
menu:
  style: outside
  position: bottom
  buttons:
    frigate:
      enabled: false
    cameras:
      enabled: false
    fullscreen:
      enabled: false
    microphone:
      enabled: true

[dermotduffy]

Just to confirm: You can correctly use 2-way audio, for this same camera, via the go2rtc UI on this same device + microphone?

[BlackBeltPanda]

Just to confirm: You can correctly use 2-way audio, for this same camera, via the go2rtc UI on this same device + microphone?

That's correct, if I use the 2-way-aud link in the go2rtc UI, 2-way audio works normally from the same device + microphone for the same camera as I'm testing with the frigate card.

[dermotduffy]

@BlackBeltPanda Thanks for being so explicit. Your config looks fine, not sure what's going on here. On the card, you hold down the microphone button (does it turn red?), you speak, then let go the button, but nothing is coming out on the other end?

[dermotduffy]

@SusithAbeythunga This sounds similar to the issue you just filed -- do the circumstances sound identical? (If yes, I'll close the other issue).

[BlackBeltPanda]

On the card, you hold down the microphone button (does it turn red?), you speak, then let go the button, but nothing is coming out on the other end?

That's correct; the button on the card is red while I'm holding it down, I speak while holding it down, then let go of the button. No sound is emitted from the camera when I do this.

[dermotduffy]

That's correct; the button on the card is red while I'm holding it down, I speak while holding it down, then let go of the button. No sound is emitted from the camera when I do this.

Video is working fine I assume? Anything interesting in the Javascipt console logs that looks relevant (F12 in Chrome). Anything in the go2rtc logs?

[SusithAbeythunga]

@SusithAbeythunga This sounds similar to the issue you just filed -- do the circumstances sound identical? (If yes, I'll close the other issue).

Not quite. I can see the microphone button and it turn red when I press. Browser even prompt Microphone access. 2-Way audio work fine without the #backchannel=0 in go2rtc, but then the doorbell button doesn't work.

[BlackBeltPanda]

Video is working fine I assume? Anything interesting in the Javascipt console logs that looks relevant (F12 in Chrome). Anything in the go2rtc logs?

@dermotduffy Video is working fine, correct. No errors in the Javascript console logs, just FRIGATE-HASS-CARD Version 5.2.0. Go2rtc logs only contain:

[INFO] Preparing go2rtc config...
[INFO] Not injecting WebRTC candidates into go2rtc config as it has been set manually
[INFO] Starting go2rtc...
go2rtc version 1.2.0 linux/amd64
[api] listen addr=:1984
[rtsp] listen addr=:8554
[srtp] listen addr=:8443
[webrtc] listen addr=:8555
[INFO] Starting go2rtc healthcheck service...

Not quite. I can see the microphone button and it turn red when I press. Browser even prompt Microphone access. 2-Way audio work fine without the #backchannel=0 in go2rtc, but then the doorbell button doesn't work.

@SusithAbeythunga You need to create two streams, one with the #backchannel=0 for Frigate to consume, and one without for 2-way audio, like in the Frigate config I posted above. As long as something is consuming the 2-way audio stream, the doorbell button won't work.

[BlackBeltPanda]

Well, I made some progress. I can get 2-way audio to sort-of work; when using the frigate card, there's a significant delay between speaking into the microphone and the audio playing on the camera and, unfortunately, all go2rtc streams crash once I close the 2-way audio stream. The audio delay is not present when connecting to the go2rtc stream in the go2rtc UI. I updated go2rtc to v1.6.2 by dropping the binary into frigate's config folder. I also added - "ffmpeg:doorbell_2way_audio#audio=aac" to the go2rtc streams under doorbell_2way_audio in the frigate config. Lastly, I set the network_mode to host in the docker compose config for the frigate container. I am seeing some errors in the go2rtc log, though, probably from the stream crashing:

[INFO] Preparing go2rtc config...
[INFO] Not injecting WebRTC candidates into go2rtc config as it has been set manually
[WARN] Using go2rtc binary from '/config/go2rtc' instead of the embedded one
[INFO] Starting go2rtc...
INF go2rtc version 1.6.2 linux/amd64
INF [api] listen addr=0.0.0.0:1984
INF [rtsp] listen addr=0.0.0.0:8554
INF [webrtc] listen addr=0.0.0.0:8555/tcp
INF [srtp] listen addr=0.0.0.0:8443
[INFO] Starting go2rtc healthcheck service...
WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error="read tcp <frigate ip>:39340-><camera ip>:554: i/o timeout" url=rtsp://<camera_username>:<camera_password>@<camera ip>:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error="read tcp <frigate ip>:51722-><camera ip>:554: i/o timeout" url=rtsp://<camera_username>:<camera_password>@<camera ip>:554/cam/realmonitor?channel=1&subtype=0
WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error=EOF url=ffmpeg:doorbell#backchannel=0#audio=aac
WRN [streams] json locked
WRN [rtsp] error="read tcp <frigate ip>:41418-><camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:41398-><camera ip>:554: i/o timeout,exec: exit status 1,read tcp <frigate ip>:51128-><camera ip>:554: i/o timeout" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:49908-><camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="dial tcp <camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:51110-><camera ip>:554: i/o timeout,exec: exit status 1,dial tcp <camera ip>:554: i/o timeout" stream=doorbell
WRN [rtsp] error="dial tcp <camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="dial tcp <camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="dial tcp <camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="dial tcp <camera ip>:554: connect: no route to host,exec: exit status 1" stream=doorbell
WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error="read tcp <frigate ip>:45534-><camera ip>:554: i/o timeout" url=rtsp://<camera_username>:<camera_password>@<camera ip>:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error="read tcp <frigate ip>:45540-><camera ip>:554: i/o timeout" url=rtsp://<camera_username>:<camera_password>@<camera ip>:554/cam/realmonitor?channel=1&subtype=0
WRN [rtsp] error="read tcp <frigate ip>:50120-><camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:50094-><camera ip>:554: i/o timeout,exec: exit status 1,read tcp <frigate ip>:36438-><camera ip>:554: i/o timeout" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:41058-><camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell
WRN [rtsp] error="read tcp <frigate ip>:41080-><camera ip>:554: i/o timeout,exec: exit status 1" stream=doorbell

Edit: I'm also seeing upwards of 3 receivers sometimes in the 2-way audio stream in go2rtc, but the only thing connected to that stream is the frigate card and I only have one instance of it open. Not sure if that's relevant:

[SusithAbeythunga]

Video is working fine I assume? Anything interesting in the Javascipt console logs that looks relevant (F12 in Chrome). Anything in the go2rtc logs?

@dermotduffy Video is working fine, correct. No errors in the Javascript console logs, just FRIGATE-HASS-CARD Version 5.2.0. Go2rtc logs only contain:

[INFO] Preparing go2rtc config...
[INFO] Not injecting WebRTC candidates into go2rtc config as it has been set manually
[INFO] Starting go2rtc...
go2rtc version 1.2.0 linux/amd64
[api] listen addr=:1984
[rtsp] listen addr=:8554
[srtp] listen addr=:8443
[webrtc] listen addr=:8555
[INFO] Starting go2rtc healthcheck service...

Not quite. I can see the microphone button and it turn red when I press. Browser even prompt Microphone access. 2-Way audio work fine without the #backchannel=0 in go2rtc, but then the doorbell button doesn't work.

@SusithAbeythunga You need to create two streams, one with the #backchannel=0 for Frigate to consume, and one without for 2-way audio, like in the Frigate config I posted above. As long as something is consuming the 2-way audio stream, the doorbell button won't work.

Thanks for the suggestion. However, where does the frigate consume that stream? I checked your frigate card but it only calls for 2way audio stream.

[masdgaf]

I wanted to chime in on this issue as I am seeing it as well on both an Amcrest AD410 and an Amcrest IP4M-1041B PTZ camera with 2-way audio support. I have 3 streams setup in go2rtc for these cameras, 1 that is audio only for Frigate to consume for recording and use as the live view, 1 for the sub channel for Frigate detection, and 1 for 2-way audio that is only used by the Lovelace cards. 2-way audio works flawlessly from the go2rtc page. The microphone button shows up on the card and 2-way audio will work sometimes, but often when opening the page with the lovelace card, 2 or more consumers from the same IP will show up on the go2rtc page like @BlackBeltPanda described. This number usually drops to 1 after a short time, but the persisting stream won't send audio.

[BlackBeltPanda]

I think what's happening is the first consumer in go2rtc is created when the card loads, and then the second consumer is when the card is refreshed (either after pressing the microphone button or automatically). Problem is, the 2-way audio only works on the first consumer.

Edit: If that's the case, an option to specify which stream should open when using the microphone should fix it. That way you could configure it to open the main live stream initially and then only switch to the 2-way audio stream when it refreshes upon pressing the microphone button.

[masdgaf]

I think what's happening is the first consumer in go2rtc is created when the card loads, and then the second consumer is when the card is refreshed (either after pressing the microphone button or automatically). Problem is, the 2-way audio only works on the first consumer.

Edit: If that's the case, an option to specify which stream should open when using the microphone should fix it. That way you could configure it to open the main live stream initially and then only switch to the 2-way audio stream when it refreshes upon pressing the microphone button.

This was my assumption as well. The docs for the card describe it as loading without microphone and then reloading the stream and connecting it when the mic button is pushed. I tried configuring the card to always have the mic connected so the stream doesn't reload and I'm still seeing the same behavior with multiple consumers being created when the card loads.

[dermotduffy]

I think what's happening is the first consumer in go2rtc is created when the card loads, and then the second consumer is when the card is refreshed (either after pressing the microphone button or automatically). Problem is, the 2-way audio only works on the first consumer.

That's really unfortunate behavior. For WebRTC, once the stream is established, the microphone stream cannot be dynamically added to it without tearing down the connection, so the card will always need to have this "video only at first, then reset if the microphone button is pressed" behavior as far as I can determine. The only way around this is just to connect the microphone from the very start with the always_connected option (but see below).

This was my assumption as well. The docs for the card describe it as loading without microphone and then reloading the stream and connecting it when the mic button is pushed. I tried configuring the card to always have the mic connected so the stream doesn't reload and I'm still seeing the same behavior with multiple consumers being created when the card loads.

Theory: For card-load performance, the microphone stream is initialized on card load in the background (i.e. async / in parallel) with the go2rtc channel being setup, so it's possible that stream is established briefly before the microphone is initialized -- which would reset the stream. This would happen so fast you don't see it. I could change it so that the microphone is required to be initialized before the card is loaded at all if this fixes 2-way audio for some users. It will marginally slow down the card load time, but likely not a big deal -- but I wouldn't do it unless it actually fixed something :-)

If anyone is code savvy, this would not be hard to experiment with -- you'd just need to move the microphone initialization code from _initializeBackground to _initializeMandatory, then rebuild, clear your cache and test it out (code).

[masdgaf]

If anyone is code savvy, this would not be hard to experiment with -- you'd just need to move the microphone initialization code from _initializeBackground to _initializeMandatory, then rebuild, clear your cache and test it out (code).

I can likely take a look at this in the coming days. Thanks for the direction!

[TomK]

I've attempted to move this code around, but so far no luck. I still get a stream reload when clicking the microphone button. I'm certain that i'm missing something simple.

[BlackBeltPanda]

Been a while since I had any time to play with this, but quick question: Would it be possible to just add an optional dedicated 2-way audio stream? That way, when the stream is first loaded, it loads the default stream. When reloading to enable 2-way audio, it could pull up the specified 2-way audio stream with the microphone connection active. This would also allow for a live view of Amcrest cameras without affecting the doorbell button (which stops working when a 2-way audio stream is open) until the 2-way audio is explicitly accessed.

[dermotduffy]

OK, I've moved the microphone initialization logic to before the card is rendered. If I add debug logging, I can see before this change a WebRTC connection was initiated without 2-way audio, then immediately with it. After this change, there's only a single connection.

Configuration to always have the microphone connected is simple:

live:
  microphone:
    always_connected: true

... when configured like this there is no connection reset on unmuting the microphone.

With that said, I have no idea if this will fix the issues you have been seeing -- if someone wants to test out the dev branch and report back, go for it!

[jarkastr]

@dermotduffy I have tested this and it worked with no delay!

However the amcrest doorbell (and I think all other amcrest cameras have a unique issue that needs to be accommodated: when the RTSP connection with 2way is being used, the doorbell button cannot be pressed.

It appears the current logic after you turn off the microphone, the RTSP feed stays on the 2way connection. It should revert back to the original one as to not keep open the RTSP feed with backchannel.

@BlackBeltPanda your settings above have been a life saver. Never would have gotten this far without them. Thanks!

[jarkastr]

After further investigation, I think I just need the ability to conditionally select which feed to pull. By default it should pull the feed without backchannel, when you hit the microphone, it should switch to the feed with the backchannel and when I mute the microphone, it should switch me back to the original feed.

[esand]

Configuration to always have the microphone connected is simple:

live:
  microphone:
    always_connected: true

... when configured like this there is no connection reset on unmuting the microphone.

With that said, I have no idea if this will fix the issues you have been seeing -- if someone wants to test out the dev branch and report back, go for it!

So, this has been available for a while now I believe and I have been (trying) to use it. Pros: not having to press the mic button to first establish the connection is much nicer - simply visiting the card opens the mic connection. Cons: it doesn't drop the connection... like, ever. You have to kill the app or close the tab to break the connection to that backchannel stream. On the Amcrest/Lorex/Dahua doorbells in question (they're all Dahua products), this seems to be a real issue since it stops the doorbell press from working until backchannel is released, and it only allows one consumer to be active.

I noticed you tagged v6 with possibly being the release with a fix to this issue... are you looking in to ways to release the mic too? If not, please add that to the list of things to do; the mic needs to be released if the app no longer is in the foreground, or the view the card is on loses focus, and possibly with a max timeout that forces it to drop no matter what.

[jarkastr]

@esand I just tried the timeout function. Seems to work as described and kills the stream (I think)

[esand]

@esand I just tried the timeout function. Seems to work as described and kills the stream (I think)

What timeout function? You mean disconnect_seconds? That gets ignored (says so in docs) if you use always_connected. If there's another timeout setting that kills the mic, which setting is that?

[jarkastr]

@esand: here is my whole setup to deal with the AD410 limitation of not being able to press the doorbell while streaming. Frigate setting:

go2rtc: streams: Doorbell:

• rtsp://admin:PASS@192.168.0.185:554/cam/realmonitor?channel=1&subtype=0#backchannel=0
• "ffmpeg:doorbell#backchannel=0#audio=acc" Doorbell_2way_audio:
• rtsp://admin:PASS@192.168.0.185:554/cam/realmonitor?channel=1&subtype=0 Doorbell_sub:
• rtsp://admin:PASS@192.168.0.185:554/cam/realmonitor?channel=1&subtype=1#backchannel=0
• "ffmpeg:doorbell_sub#backchannel=0#audio=acc"

Default camera view using frigate card. Note that I use the one without backchannel for general viewing/listening. If i want to use talkback or get a notification on HA app, I link directly to my lovelace subchannel of doorbelltalkback:

type: custom:frigate-card cameras:

• camera_entity: camera.doorbell live_provider: go2rtc go2rtc: modes:
  • webrtc stream: Doorbell camera_name: Doorbell view: default: live timeout: 30 live: auto_mute: all microphone: always_connected: false layout: fit: contain menu: style: outside position: bottom buttons: frigate: enabled: false cameras: enabled: false fullscreen: enabled: false elements:
• type: custom:frigate-card-menu-icon icon: mdi:microphone tap_action: action: navigate navigation_path: doorbelltalkback

Doorbell Talkback frigate card (only displayed if I press the microphone link in my "normal card" or direct from app). Note that the timeout function disconnects the connection after 30 seconds of closing the subview so that than it shuts down the feed with backchannel:

type: custom:frigate-card cameras:

• camera_entity: camera.doorbell live_provider: go2rtc go2rtc: modes:
  • webrtc stream: Doorbell_2way_audio camera_name: Doorbell view: default: live timeout: 30 live: auto_mute: never auto_unmute: all microphone: always_connected: false layout: fit: contain menu: style: outside position: bottom buttons: frigate: enabled: false cameras: enabled: false fullscreen: enabled: false microphone: enabled: true type: toggle screenshot: enabled: true live: enabled: false clips: enabled: false snapshots: enabled: false timeline: enabled: false download: enabled: false media_player: enabled: false

[esand]

@jarkastr - Thanks; that's exactly how I have mine set up. I have a sub-view that I link to when I want microphone access. The sub-view has only the frigate card and it's where I access my dedicated sub-stream with backchannel audio... just like you've got.

However, two differences in your configs. One, you reference an unknown timeout property under view. The current Frigate card doesn't seem to have such a setting, at least exposed via UI. Second, your card doesn't use always_connected - it's set false.

What I am mentioning is that when always_connected is true, we need a way to force the closure of the stream even if you're no longer viewing the Frigate card, view or app itself. Android doesn't seem to be keen on actually closing an app when you close an app; it prefers to put it to sleep in case you want to access it again. Because of this, the connection remains open because the Frigate card and HA don't seem to do anything special when the app has lost focus. Using the mic on a doorbell is a very active/foreground-only activity, so the connection should be killed the instant the Frigate card is no longer being interacted with in the foreground.

I'm in agreement with some others in asking for a way to configure a mic-only stream, so that the card knows what it can fall back to for a stream when the mic is not in use (such as before you've pressed the mic button to establish 2-way, or if the mic stream is to be disconnected but card is still being viewed). I'm almost wondering if it would make more sense to have go2rtc establish an audio-only stream for the audio, but no video at all. Then, the card could use 2 streams - one for regular audio/video, then a second for 2-way audio only. That way, it could perhaps ad-hoc open/close the mic stream purely for talking only and it wouldn't need to keep it open all the time - just when you press the mic button.

[jarkastr]

@esand I believe the timeout function is behaving like timeout_seconds: https://github.com/dermotduffy/frigate-hass-card?tab=readme-ov-file#view-options

A numbers of seconds of inactivity after user interaction, after which the card will reset to the default configured view (i.e. 'screensaver' functionality). Inactivity is defined as lack of mouse/touch interaction with the Frigate card. If the default view occurs sooner (e.g. via update_seconds or manually) the timer will be stopped. 0 means disable this functionality.

The above timeout property appears to shut down the RTSP feed as soon as I close the subview (or at least within 30 seconds). I have the microphone off by default, intentionally, and then chose to turn it on when I go into that subview (for better or worse - just a preference).

I have only set this up a few days ago, so I haven't yet found a flaw. I am sure there could be one.

A mic only stream would be ideal, but my current solution will keep me sufficiently satisfied having a local doorbell work with 2 way audio. I saw Roger Tech Talk's solution on youtube and thought it would be great, but it seems to be a security nigtmare as it exposes a public feed of your camera to the web (with the ability to talkbalk). The Frigate Card keeps the feed out of the public view!

[esand]

@esand I believe the timeout function is behaving like timeout_seconds: https://github.com/dermotduffy/frigate-hass-card?tab=readme-ov-file#view-options

It seems you're right, and it led me down a few ideas and I think I've actually solved the issue with existing features!

So, I configured my view with a single frigate card for 2-way audio to ensure that lazy load was true, and lazy unload was all. Then I set your timeout_seconds to 15 (I felt your 30 might be a bit much if you've actually not interacted with the card), and then I think the magic trick was I defined a second camera and moved it to the first camera so it's the default. The first camera is the non-backchannel feed for the same camera, and then I also hid it in the UI so that you only see the secondary camera which is the 2-way audio.

What happens when you leave the view (even if you just background it) is that lazy unload triggers (and/or your timeout) and unloads the 2-way audio view and defaults back to the default camera, which is the hidden non-backchannel feed. My tests on both Windows and Android showed that the backchannel was successfully unloaded about 10-15 seconds after I no longer had the view in the foreground, even if I don't close the tab/window.

type: custom:frigate-card
cameras:
  - camera_entity: camera.front_doorbell
    live_provider: go2rtc
    id: main
    hide: true
    go2rtc:
      modes:
        - webrtc
        - mse
  - camera_entity: camera.front_doorbell
    live_provider: go2rtc
    id: 2way
    go2rtc:
      modes:
        - webrtc
        - mse
      stream: Front_doorbell_2way
    frigate:
      camera_name: Front_doorbell_2way
view:
  default: live
  timeout_seconds: 15
menu:
  buttons:
    microphone:
      enabled: true
      type: momentary
      icon: mdi:microphone
    mute:
      enabled: false
  style: outside
  position: bottom
  alignment: right
live:
  controls:
    builtin: false
  microphone:
    always_connected: false
    disconnect_seconds: 1
  auto_unmute: all
  draggable: false
  layout:
    fit: fill
  lazy_unload: all
performance:
  profile: high
dimensions:
  max_height: 90vh

The one thing I haven't tested is with always_connected: true, but I don't think that has any effect on the backchannel being opened or not (I could tell when it was open by the doorbell "flashing"); mic or no mic, it still opened the backchannel.

[esand]

The one thing I haven't tested is with always_connected: true

Tested and similar results, so it seems this config will do the job just fine until something better comes along.

[jarkastr]

@esand Tried testing your card above. While trying to test it and monitoring webrtc, it looks like the default stream it shows is the 2way stream, which prevents the doorbell from being rang - If you are ok with that. As long as you aren't watching the doorbell then someone will be able to ring, but if you are watching the doorbell, then a person won't get an audible ding that the bell has been rang.

[esand]

@esand Tried testing your card above. While trying to test it and monitoring webrtc, it looks like the default stream it shows is the 2way stream, which prevents the doorbell from being rang - If you are ok with that. As long as you aren't watching the doorbell then someone will be able to ring, but if you are watching the doorbell, then a person won't get an audible ding that the bell has been rang.

Yes, this is correct - this card opens the 2way audio backchannel when viewed, and that's the purpose. This card is specifically for 2-way communication if required. The "fix" that this setup provides is that it will drop the backchannel once the card isn't focused and it times out. Without the dual camera stream setup, it wouldn't drop the backchannel until you closed your browser tab or app.

Until something is added to the frigate lovelace card that allows us to have the mic button tied to a specific stream, there's no other way for it to work... and I believe that's the feature that's being discussed here - we want some way that the mic button, when activated, opens the backchannel stream only when pressed, thus allowing us to have the mic button present on a camera view where a camera supports 2-way audio, but it's only when you try to activate the mic that we want the backchannel stream opened.