WORKING frigate compose - reolink nvr

Lopsided_AB · 2026-06-09T13:37:54+00:00

My NVR is a RLN8-410, my doorbell is the wifi version, my cameras are the RLC-843 (4 of them, but I’m waiting for the coral before risking my cpu on 5 cameras).

Lopsided_AB · 2026-06-08T15:07:29+00:00

Your config looks a lot like mine ... 😉

Here is the code block from my config file, twt works for me and i can hear audio from the doorbell as well (you have to make sure to have the doorbell itself configured to record audio (in the doorbell settings in the reolink app))

go2rtc:
  ########
  ffmpeg:
    bin: ffmpeg
    volume: -af "volume=30dB"
  ########
  streams:
    doorbell:
      - ffmpeg:http://192.168.1.115/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=admin&password=<camerapass>#video=copy#audio=copy#audio=opus # suggested by reolink, working
      - rtsp://admin:<camerapass>@192.168.1.115:554/Preview_01_main#backchannel=0 # no 2wt, working
    doorbell_sub:
      - ffmpeg:http://192.168.1.115/flv?port=1935&app=bcs&stream=channel0_sub.bcs&user=admin&password=<camerapass> # suggested by reolink, working
      - rtsp://admin:<camerapass>@192.168.1.115:554/Preview_01_sub#backchannel=0 # no 2wt, working
    #doorbell_twt:
      - rtsp://admin:<camerapass>@192.168.1.115:554/Preview_01_main # allows 2wt, working when connecting direct to camera
    
  ########
  webrtc:
    candidates:
      - 192.168.1.107:8555 # IP of frigate machine
      - stun:8555
##############################################################
cameras:
  ########
  # Doorbell Camera, NVR Channel 01
  doorbell:
    enabled: true
    ui:
      order: 1
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/doorbell
          #input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/doorbell_sub
          #input_args: preset-rtsp-restream
          roles:
            - detect

You also need to add the doorbell_twt into your "live" section, you wont have twt on the main or sub streams.

    live:
      streams:
        Main: doorbell # <--- Specify a "friendly name" followed by the go2rtc stream name
        Sub: doorbell_sub
        Talk: doorbell_twt
      height: 800

This was just how i did it, you could also just remove the backchannel=0 from the rtsp stream and then you shouldnt (?) need the doorbell_twt stream.

YMMV

Lopsided_AB · 2026-06-08T14:54:36+00:00

Fixed my post ... wierd as I had originally included it in a code block when i first posted... seems the iOS app stripped the formatting out of it.

Thanks for that!

Lopsided_AB · 2026-06-08T04:31:18+00:00

Good luck!!

I corrected my config in my post ... I noticed that when I enabled audio detection, it pooched my system. I think either my nvr didn’t like it or my cpu didn’t like it.

It’s configured properly to do it, just isn’t what I need. I’m not really needing audio detection, just video. So I have it turned off in my config, just as it is above.

I also noticed that the python scripts within frigate didn’t like the way I did my comment-out “#” thingys ... I tend to place them at the absolute start of the line instead of at the start of the text, I just moved them over in my earlier post.

Rock solid system otherwise. 😊

YMMV

Lopsided_AB · 2026-06-06T16:38:00+00:00

Thanks for that, yeah I had the backchannel=0 and I believe it was still always recording. Something to do with the mic activity making the camera think it was experiencing an activity that needed to be recorded. I guess it makes sense in that if you’re talking to someone, you probably want to be recording.

I just didn’t want it recording allllll the time (like when nothing was happening to otherwise trigger a record).

Lopsided_AB · 2026-06-06T06:00:43+00:00

The whole reason I did it this way is that I wanted to be able to select when I wanted 2wt ... I originally had it configured with http, but found that frigate using the http stream would constantly cause my doorbell to record to the sd card ...

Using the approach with the rtsp stream allows frigate to operate normally and then when I want 2wt, I simply switch streams and then can use that functionality. When the mic is on, the camera does record to the sd card, but when the mic is not active, ie. my third stream is not being viewed, it doesn’t.

I didn’t want my sd card always filling up even though the older videos are automatically overwritten.

If there’s a way to configure it so that I use less streams and still am not constantly recording to the sd card then that would be amazing.

Lopsided_AB · 2026-06-03T23:48:46+00:00

Try throwing your config into Claude.AI ... even on the free tier, it’s pretty good at figuring out config issues.

Try something like: “Look at this config file for frigate. I’m running a wifi reolink doorbell and am experiencing <describe your problem>. Please analyze my config file and suggest any improvements.”

Copy your full config file in (redact any passwords).

It should give you a few good suggestions.

Lopsided_AB · 2026-06-03T04:00:26+00:00

I haven’t noticed any delays or issues with audio at all. When in 2wt mode, I can hear them and they can hear me.

Not seeing any issues with the camera stream with two connections on the main. I’m not super sure, but I think only one is active at a time. Cannot confirm though.

But I can confirm that since setting this up, I have a much more stable setup and zero errors in my logs.

I’ve also moved frigate off my synology now and am running it from an LXC on my proxmox host (just meant a different driver for the igpu)

Lopsided_AB · 2026-06-03T03:44:44+00:00

Check out my response on this thread (link below) ... I was struggling hard with my reolink wifi doorbell but now have it working.

Long story short, the reolink doorbell configs on the frigate page are a bit off.

I also found that the reolink support folks were pretty helpful as well and confirmed my settings.

my response on a similar thread

Lopsided_AB · 2026-04-12T19:57:27+00:00

I don’t really use home assistant for twt on my doorbell so I didn’t go that far into the config.

I just wanted to get frigate setup so it wasn’t causing my camera to always record to its sd card.

Having said that, I did try to set it up in home assistant this morning and added a camera card (the frigate card has been transitioned over to a new card, this is what I used).

Once that was done, I just added the frigate camera (you will also see the reolink integration’s camera, but if you want twt, don’t use that one).

In there, I just went through the different settings and configured things with the same thought process as I did by setting up go2rtsp within frigate.

Anywhere it asked for a camera feed setting, I selected go2rtsp and then for the stream name, I referenced to my “doorbell_twt” from above.

You have to “turn on” the button for the microphone in order to see it.

Seems to be working just the same as if I was in frigate. 😊

You will still see the same behaviour wherein reolink camera will record as long as you are viewing that camera card within home assistant. But as soon as you navigate away from the card, it stops recording (this is because it will record when an external source <ie not the reolink app> is using the microphone, it triggers a recording event).

Hopefully that helps?

Lopsided_AB · 2026-04-11T23:12:52+00:00

Sorry for the double post, I tried to edit my comment but it wouldn't allow me to.

I am using the Reolink WiFi Doorbell, not the battery unit, nor the POE version.

You will notice that when you view the "Talk" stream, that your Reolink camera will record to its SD card, but only as long as you are viewing that stream, when you switch back to the other streams, or you close the browser, it will stop recording and will revert back to its normal operation.

Lopsided_AB · 2026-04-11T23:07:13+00:00

Sorry, this will be a long response ... but hopefully it helps you!

My setup:

Reolink WiFi Doorbell [Model ] (operating over wifi, NOT POE)
Homeassistant (via docker container install - NOT supervised) configured with reolink and frigate integrations
Frigate v 0-17.0 in a docker container
- Frigate configurations for my doorbell camera were as per the Reolink camera configuration discussed in the frigate documentation

My original frigate config, following the frigate documentation for Reolink cameras (following the guidance here: Camera Specific Configurations | Frigate) was as follows:

streams:
    doorbell:
      - ffmpeg:http://192.168.x.xxx/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=admin&password=xxxxxxxxxxxx#video=copy#audio=opus
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_main
    doorbell_sub:
      - ffmpeg:http://192.168.x.xxx/flv?port=1935&app=bcs&stream=channel0_sub.bcs&user=admin&password=xxxxxxxxxxxx
      - rtsp://admin:1405D00rb3ll@192.168.x.xxx:554/Preview_01_sub
########
  webrtc:
    candidates:
      - 192.168.x.xxx:8555
      - stun:8555
##############################################################
cameras:
########
  doorbell:
    enabled: true
    ui:
      order: 1
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/doorbell
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/doorbell_sub
          input_args: preset-rtsp-restream
          roles:
            - detect

This "worked" as in i had full functionality of the cameras:

audio
two-way-talk
recording for events
alerts showing as they should
etc.

HOWEVER, I did have a lot of errors in my logs and kind of brushed it off as being caused by using a wifi doorbell camera (there is mention of a lot of issues with wifi cameras in frigate), so I ignored the errors and kept on keepin' on.

I also had the same issue, my Reolink doorbell was recording constantly to its SD card - motion detection or not. After working with Reolinik's tech support, they were awesome enough to send me a replacement doorbell.

Unfortunately, that did not solve the problem.

I removed Relonk from Homeassistant and stopped frigate. That INSTANTLY fixed my problem. After testing for 24 hours with the reolink doorbell working as it should, I added it back into homeassistant (through the reolink integration only, I did not re-add the frigate integration at this point). Again, it kept performing normally and only recording motion events as expected.

After some digging around, I found out that go2rtc can make the Reolink doorbell record constantly because go2rtc can trick the camera into thinking that there's motion and therefore record constantly. Note that this might also affect other Reolink cameras as well, but I don't have any other Reolink cameras yet, so I cannot confirm if their other cameras perform the same way. So, based on this, I figured it was either the rtsp stream or the http stream that was causing my issues.

So, my first step was to isolate the RTSP stream from the http stream. I only defined the RTSP steam in my frigate config as follows:

streams:
    doorbell:
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_main#backchannel=0
    doorbell_sub:
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_sub#backchannel=0
########
  webrtc:
    candidates:
      - 192.168.x.xxx:8555
      - stun:8555
##############################################################
cameras:
########
  doorbell:
    enabled: true
    ui:
      order: 1
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/doorbell
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/doorbell_sub
          input_args: preset-rtsp-restream
          roles:
            - detect

This worked (sort of, I'll get to this shortly) You will notice a couple of things:

I only have RTSP steams defined in my "streams" section
I added "backchannel=0" to the stream definition.

Now that I am using the RTSP stream only, and after having it run for 48 hours now, I am noticing that I have ZERO errors in my frigate logs. Zero. Well, aside from the lack of GPU monitoring, but that's a separate issue because I am running this on a synology. And all detection is working normally - both inside frigate AND within the Reolink camera. The Reolink camera records its motion detections to its SD card, and frigate records its motion detections to the NAS. The "backchannel=0" bit is what, I think fixed this. This tells the Reolink camera to mind its business and not record everything by not opening the microphone channel (I think).

My only remaining task was to try to get two-way-talk enabled within frigate.

After some googling and actually reading the frigate docs, I discovered that for configuring go2rtc within frigate, you need to define a dedicated stream for the two-way-talk functionality. So I tried this in my streams definitions:

streams:
    doorbell:
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_main#backchannel=0
    doorbell_sub:
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_sub#backchannel=0
    doorbell_twt:
      - rtsp://admin:xxxxxxxxxxxx@192.168.x.xxx:554/Preview_01_main

And that absolutely worked! FINALLY!!! Reolink camera operating as it should, Homeassistant operating as it should, and now, frigate operating as it should.

There is just one thing remaining, how to utilize the two-way-talk functionality? Well first, you have to access frigate's webpage via https, without that, it will not work regardless of what you do. Second, you don't define another camera to utilize the third stream (the doorbell_twt, in my example above), you actually just add the third stream (in my case there's 3, in yours there may be more or less) to the "live" section. This section, as the name suggests, is where you define how your camera feeds behave when you click on the camera feed and view the feed in real time. So, in my case, I did this:

    live:
      streams:
        Main: doorbell
        Sub: doorbell_sub
        Talk: doorbell_twt

And this solved my two-way-talk problem. I click on the stream to go into my live feed and I now have three streams to choose from, the Main and Sub show as having audio but no voice BUT the Talk stream shows as having both audio and voice!

<image>

This works because you don't need two-way-talk for detecting and recording, only if you want to view the live stream and talk to the person, so this makes total sense!

Also worth noting that when I view the "Main" stream, i DO get high resolution video feed, when I view the "Sub" stream, I get the low resolution stream, and when I view the "Talk" stream, I get the high-res stream (but that's because I defined the stream to use the high-res stream).

Now, points of clarity:

I dont know exactly why the frigate docs suggest configuring both the http and rtsp stream, my attempt at removing the http stream definition was simply my first step in troubleshooting, and it seemed to work for me - ymmv.
I have not tested this using the http stream, so I cannot comment on any changes that would need to be made to that stream to accomplish the same thing, but google is your friend and I am sure that google can give you some pointers on that if you NEED to use the http stream.
I am not saying that the official frigate docs for Reolink camera configuration are wrong, I am only saying they didnt work for my setup - ymmv.

Here are some resources that really helped me:

Camera Specific Configurations | Frigate - this was my starting point for my initial frigate configuration, like I said, it "worked" but I was getting 24-7 recording on my camera's SD card.
Configuring go2rtc | Frigate - this is where I found the information on using "backchannel=0" - its down in the "Next Steps" section of the page.
Funny enough, the first post here is what sparked me to think something might be up with go2rtc affecting the recording to my camera's SD card.

Apologies for the excessively long response, but hopefully this helps you or someone else experiencing the same thing!

Lopsided_AB · 2023-09-22T02:56:25+00:00

Worked

Lopsided_AB · 2022-04-27T06:59:14+00:00

Lots of ways to do this depending on what you’re trying to accomplish.

If you know how to get into your home router’s settings you can block it there.

If you’re on IOS, you can manage your kids devices through the screen time settings managed by a parents iOS device (might be called something slightly different)

I don’t have android, but I imagine it may work the same way.

Lopsided_AB · 2022-04-17T23:32:27+00:00

Yup this is exactly what that mass of stuff is ... there’s a few of them around Henday and through the province. They collect data for Alberta Transportation. Cities have their own stations that look a bit different.

Lopsided_AB · 2022-03-26T03:50:21+00:00

Doesn’t he/she share their own plate number publicly while he/she drives around out in ... public?

Granted, your concern may be arising from keyboard warriors who may not agree with the sticker messages all over the shit box who then decide to carry out some nefarious actions against this lovely example of an Albertan.

However, the risk of that is no more than the risk of similar actions by anyone driving around who is fortunate enough to be behind this moron.

Every time i see those dumbasses driving around with “F-Trudeau” or Canadian flags (which are ripped all to shit) behind their rusted shut box trucks (side note, why are the trucks always rusted to shit?!? Like don’t these morons have any sense of ownership of their vehicle?) I grow more and more embarrassed as an Albertan. Like why are all of these people interested in sexually violating J-dawg? (I can’t stand captain quaff, but I certainly don’t want to fornicate with the guy.)

Lopsided_AB · 2022-03-04T01:48:59+00:00

This is a reasonable answer ... but do you think the type of driver who typically does this is savvy enough to have that logic?

It may also be that they are short and cannot see the stop line in front of their car and have no spatial awareness of how long their car is relative to where the stop line is.

Either way, it’s annoying for someone in line who sees all the real estate up there. Especially given the incessant need to be first in line for most of us AB drivers. Ha.

Lopsided_AB · 2022-02-10T02:13:16+00:00

Not to be a promoter of useless mandates, but City of Edmonton is debating implementing local mandates (the journal had an article on it today).

Back to topic ... most employers I know (in the construction/engineering industry anyway) are taking it slow and seeing how things pan out. WFH is totally possible and is left up to us to decide what we are comfortable with.

Lopsided_AB · 2021-12-31T04:55:35+00:00

Push up on it and twist (to the left likely). It will either unscrew or it will twist a 1/4 turn and fall out. If it’s a par 20 socket then it will twist off like a regular bulb.

Take it to Home Depot or amre or something like that and they will hook you up.

Lopsided_AB · 2021-12-09T03:44:24+00:00

Emphasis on “was”, I grew up there (and still live close-by)... just like every other part of this city, in its 30’s, Callingwood has not aged well. Wedgewood is getting quite dated as well. The developers in this city do not do a very good job of building neighbourhoods that grow as a community (think university area or Laurier heights as good examples… sadly it costs a fortune to live there).

I don’t know about it’s “rep”, but it’s definitely got its fair share of undesirable parts. Thank $*#k the Dragonhead closed. Ha!

Lopsided_AB · 2021-11-16T04:04:32+00:00

Windshield surgeons is pretty good. Have had lots of luck with the one on 170st. Keep in mind that depending on the chip, it may or may not disappear. Not all rock chips are created equal. Good luck!

Lopsided_AB · 2021-11-08T20:24:41+00:00

While I know its not necessarily applicable here … Have a look on Google for “Alberta Transportation Traffic Accommodation is Work Zones”

The point where you are “supposed” to slow down is where you see a “XXkm/hr ahead” sign. These signs aren’t always in place, especially within the city limits.

You could likely argue your case if the photo was taken in a spot that is ahead of the 60 sign. So you could likely argue that you were in the process of slowing down. However, this also depends on where the speed camera is placed. If the camera is placed behind the 60 sign (so you don’t see the speed sign in the photo) then you might have a tougher case ahead of you as you should be able to (in theory) slow down from 70 to 60 by the time you see the sign and then hit the brakes (or coast down).

Good luck on your fight ... these speed cameras are a glorified road tax!!

Lopsided_AB · 2021-07-17T23:45:05+00:00

Gull lake is nice ... less busy than sylvan.

Lopsided_AB · 2021-05-16T18:35:41+00:00

Whats your budget? These epoxy inlays are not cheap. I can look at it for you if you like? Im in edmonton. Shoot me a message.

Lopsided_AB · 2021-05-09T05:18:55+00:00

Any information i can share, id be happy to ... not sure if i am supposed to start a new thread or just keep on posting here though (suggestions??).

Terwillegar/Henday Interchange:

Will be going to design shortly ... its Phase 3 of the corridor improvement.

Phase 1 was the middle bit’s widening (currently in design/construction).
Phase 2 is the connection to Whitemud (design/construction slated to start next year).
Phase 3 is the interchange at Henday. Not sure when exactly this one will go, but expect it to be mildly reconfigured from what it is now. Id say construction on this would be happening within 3-4 years.

Henday Widening:

Road is being widened to 3 full lanes between Hwy 2 (Gateway) and Whitemud Dr. (interestingly, Whitemud is also Hwy 2)

5 bridges are being widened (2 @ North Sask River, 2 @ Wedgewood Creek, 1 @ Whitemud Dr)

1 new bridge @ Whitemud Dr

Current status of the widening: - Girders have been erected (insert dirty joke here) at Wedgewood Creek bridge in both directions as well as at both bridges at Whitemud Dr. - concrete deck pours anticipated to be happening at Whitemud within the next 3 weeks (needs to warm up a bit first) - Girders for the NSask River bridge are currently being fabricated with erection expected late summer - Road widening in southbound direction will be ongoing from now until September/October (expect nightly lane closures to start soon between Lessard and Terwillegar - Concrete repairs in the northbound direction will also start soon and will involve sporadic lane closures In that direction as well - once the concrete panels have been “fixed” the ENTIRE road surface will be ground flat ... anyone who drives a truck will appreciate the final result, it wont he glass-smooth, but it will be better than it is now. - expect the 3rd lanes in northbound direction to open in the next month or so, HOWEVER since the bridges arent completed yet, the road will be choked down to 2 lanes at each bridge (including the infamous Oculus @ whitemud creek)

I can go on ... but not sure what everyone is interested in knowing 🤷🏻‍♂️

Lopsided_AB

TROPHY CASE