New Reolink Wired POE Doorbell Cam ?

[David L]

After various further tests, I am now fairly certain that the hardware (CPU + RAM) used in the Reolink Doorbell WiFi is simply too weak to reliably establish and maintain multiple simultaneous connections. I can now consistently reproduce these connection drops at will.

As previously mentioned, my Reolink Doorbell WiFi is connected via Wi-Fi and linked to the Reolink app, a Dahua NVR (via ONVIF), and Home Assistant (via the Reolink integration). Even this setup occasionally causes the Reolink Doorbell to "drop out" and become unreachable. If I then add it to a second Home Assistant VM, for instance, things essentially grind to a halt, and the Reolink Doorbell WiFi fails completely - becoming inaccessible even through the Reolink app itself. Naturally, this triggers corresponding warnings and error messages in Home Assistant. Example:

View attachment 248609

It only becomes reachable again once I reduce the number of active connections to the Reolink Doorbell WiFi - for example, by disconnecting it from Home Assistant.

Yes, anyone using the Reolink Doorbell solely via the Reolink app - or perhaps adding a lightweight integration with software like Frigate, Agent DVR, Blue Iris, or similar - likely won't encounter these issues. However, various other users have confirmed that the hardware Reolink uses is somewhat underpowered. The Home Assistant Reolink integration documentation itself explicitly points this out:

"Reolink cameras can support a limited amount of simultaneous connections. Therefore using third-party software like Frigate, Blue Iris, or Scrypted, or using the ONVIF integration at the same time can cause the camera to drop connections."

Yes, a problem like that might well occur with video doorbells from other manufacturers too - even though I didn't experience it with my previous Dahua OEM video doorbell (Imou DB61i). In that sense, I don't necessarily want to fault Reolink for it, but it is worth knowing that you might encounter this kind of issue with the Reolink Wi-Fi doorbell.

In other words, the question of where these timeouts come from - such as when I adjust settings in the Reolink Doorbell WiFi web GUI - and why other connection drops occur from time to time is now resolved for me. At least, that is my own explanation for it.

You need to use/try RTMP. I had problems with RTSP and this ReoLink in BI. Once I switched to RTMP I had and still have Zero Drops...and I have the WiFi version...


I too use HA and have had zero problems...also have Blue Iris Integration going to. The ReoLink DB can handle Main and Sub streams fine...

If you want to really do a test, have the DB stream to multiple VLC connections/windows...I think I had 4 going in my test awhile back when I first got the DB. Thinking 3 main streams was no problem, 4 was pushing it...

Use this for Media/Open Network Stream in VLC

 

[Jim_OS]

Thanks for the information and suggestions. I’ve already run plenty of tests over the last few weeks, and I’m aware that switching the streams to RTMP has helped some users.

However, in my opinion, total resource consumption isn't actually the problem; I could address that by lowering the stream quality - for instance, by reducing the frame rate - which is something I’ve already done.



Looking at the NVR, for example, you can see that the bitrate for the Reolink Doorbell (Channel 4) isn't particularly high.



To me, it looks more like the camera struggles when "too many" processes are running - or need to run - simultaneously. I’m not sure if it’s running out of RAM, if the CPU simply can't handle processing that many tasks, or if there are entirely different reasons involved.

Besides that, when integrating via ONVIF, I can't always choose whether to use RTMP or RTSP for the streams; for example, that’s not possible with my Dahua NVR



(though it is possible with the Home Assistant Reolink integration).

As previously mentioned, I’ve tried to figure out exactly where the problem with the Reolink Wi-Fi doorbell lies and what might be causing it. To me, it seems the camera gets overwhelmed when pushed "too hard" - something I didn't experience with my Dahua OEM doorbell. That said, the Dahua model did have fewer features than the Reolink Wi-Fi doorbell.

But sure, anyone facing similar issues might want to give the RTMP stream a try. That said, as far as I know, the original reason for preferring RTMP was a bug in older firmware versions that caused frame dropping in the RTSP stream - though that has likely been fixed by now.

PS: It remains a mystery to me how Reolink could decide not to allow the motion detection function to be disabled at all. I have no need for motion detection in this instance, yet it creates unnecessary load and consumes system resources.

 

[David L]

Thanks for the information and suggestions. I’ve already run plenty of tests over the last few weeks, and I’m aware that switching the streams to RTMP has helped some users.

However, in my opinion, total resource consumption isn't actually the problem; I could address that by lowering the stream quality - for instance, by reducing the frame rate - which is something I’ve already done.

View attachment 248615

Looking at the NVR, for example, you can see that the bitrate for the Reolink Doorbell (Channel 4) isn't particularly high.

View attachment 248616

To me, it looks more like the camera struggles when "too many" processes are running - or need to run - simultaneously. I’m not sure if it’s running out of RAM, if the CPU simply can't handle processing that many tasks, or if there are entirely different reasons involved.

Besides that, when integrating via ONVIF, I can't always choose whether to use RTMP or RTSP for the streams; for example, that’s not possible with my Dahua NVR

View attachment 248617

(though it is possible with the Home Assistant Reolink integration).

As previously mentioned, I’ve tried to figure out exactly where the problem with the Reolink Wi-Fi doorbell lies and what might be causing it. To me, it seems the camera gets overwhelmed when pushed "too hard" - something I didn't experience with my Dahua OEM doorbell. That said, the Dahua model did have fewer features than the Reolink Wi-Fi doorbell.

But sure, anyone facing similar issues might want to give the RTMP stream a try. That said, as far as I know, the original reason for preferring RTMP was a bug in older firmware versions that caused frame dropping in the RTSP stream - though that has likely been fixed by now.

PS: It remains a mystery to me how Reolink could decide not to allow the motion detection function to be disabled at all. I have no need for motion detection in this instance, yet it creates unnecessary load and consumes system resources.

Yeah the Dahua DB connected to the Dahua NVR would not need ONVIF, I could see where it would be a better match. How old is your Dahua NVR?

I run Max bitrate on my DB, and pretty high bitrates on all my cameras. I have an Enterprise network with Enterprise Manage Switches...she runs great...



In looking at BI, decided to up my bitrates on the CAMS. Gonna try 8192 up from 6144

Also, recently changed all my cameras from 15FPS to 30. Here, our new home in the woods, not really using the cameras as surveillance Cams like we did in our other house in the city. Here capturing wildlife/critters. There is a slight increase in CPU usage in Blue Iris but nothing to be concerned about. We will see when 5 more cameras are added.

 

[David L]

So I bought a used POE DB from a member here awhile back. Just noticed it has a newer firmware with the I-Frames.



One of the main reasons I did not up my firmware is the Diagnostic Logs I had available on the WiFi DB where many here stated they did not have that option with newer firmware but since I can Export a Diag. Log on this newer firmware POE DB I think I will be upping the firmware on my older WiFi DB My guess now is the Windows Client version I am using is what allows the Diag. Log...



As you can see I am running an older (Windows) Client:


What made me even notice the firmware difference was seeing this icon pop up when our dog was in view/motion. I put the POE DB in the Living Room temporarily, we wanted to see what our dogs do when we were away, all they do is sleep, no parties, lol.



I really want the I-Frames in BI to be 1.00 like all my other Cameras.

Ok, don't rib me about my Camera Naming, haha, I am still working on it, I want the location AND the direction of the view in the description, still trying to figure out a good naming scheme.

Here is a small example of this big Log file, it has alot, alot of info in it...which may be useful one day...

 

[Jim_OS]

the Dahua NVR would not need ONVIF, I could see where it would be a better match.

That said, connecting via ONVIF versus directly via API and port 37777 doesn't actually make a difference regarding the RTSP stream load. Of course, I don't know if there might be differences in terms of specific underlying processes.

How old is your Dahua NVR?

Old. It’s from late 2021 - and yes, it reached EOL a long time ago. Nevertheless, it continues to perform very well here.

My network setup here certainly isn't the problem. I’m using 2.5G managed switches (e.g., from Zyxel), and the Wi-Fi runs on an Asus XT8 mesh system dedicated solely to wireless connectivity.

Doorbell Wi-Fi Signal



As I mentioned earlier, I don't think the total load from various streams is the issue; rather, it likely comes down to the number of simultaneous processes the Reolink Wi-Fi doorbell can handle. Of course, I also can't rule out the possibility that a) there are additional bugs in the current firmware or b) integrating the doorbell with the NVR is having some sort of negative impact. I recently noticed again that whenever I throw another application (another HA VM) at the Reolink Wi-Fi doorbell, timeouts and connectivity issues start to pile up - which points to an "overload" situation, whatever the exact cause might be.

Right now, I don't have the time or inclination to keep looking for the exact potential cause. My new Dahua IPC-PTS2449C-4E3Z-S-PV-PRO should arrive next week; I’ll integrate it with the NVR to replace my Imou Cruiser Dual Lens. I’ll need to make a few changes in HA anyway at that point, so I’ll also consider whether to keep the Reolink Wi-Fi doorbell integrated with the NVR. I also won't need the motion detection (MD) feature currently activated via the Reolink's own MD function anymore; instead, I’ll use the NVR’s IVS functions (AI-by-recorder) for the Reolink. In fact, I haven't used standard motion detection for years - I’ve always used IVS with line detection. I am currently using the NVR's two available 2-channel perimeter detection slots (AI by NVR) for my Imou Cruiser Dual; however, since the IPC-PTS2449C-4E3Z-S-PV-PRO can handle this itself (--> AI by camera), that function on the NVR will become available again, allowing me to use it for the Reolink Doorbell Wi-Fi. I'll see...

After all, it would be boring otherwise if you weren't constantly tinkering with something - or having to.

I think I will be upping the firmware on my older WiFi DB

I’ll keep my fingers crossed that the problems don’t crop up for you as well when you update the firmware now.

 

[David L]

So I Did It!!! haha, after owning this WiFi DB since 01-2023, I finally upgraded the firmware, haha. And Yes the Diag. Log is still there, kewl so I can now confirm it is Client version related. Decided to stay with same firmware the POE DB had...so not the latest...2026-06-08 version...
Maybe Home Assistant will stop barking at me to upgrade my firmware now


I-Frame finally fixed in BI too. All 1.00s now...nice...


As those here that know me, I am not one to chase the latest firmware's. Not a good practice...unless your device is connected to the Internet, which also is not wise, and there is a new security update.

 

[David L]

That said, connecting via ONVIF versus directly via API and port 37777 doesn't actually make a difference regarding the RTSP stream load. Of course, I don't know if there might be differences in terms of specific underlying processes.

Old. It’s from late 2021 - and yes, it reached EOL a long time ago. Nevertheless, it continues to perform very well here.

My network setup here certainly isn't the problem. I’m using 2.5G managed switches (e.g., from Zyxel), and the Wi-Fi runs on an Asus XT8 mesh system dedicated solely to wireless connectivity.

Doorbell Wi-Fi Signal

View attachment 248629

As I mentioned earlier, I don't think the total load from various streams is the issue; rather, it likely comes down to the number of simultaneous processes the Reolink Wi-Fi doorbell can handle. Of course, I also can't rule out the possibility that a) there are additional bugs in the current firmware or b) integrating the doorbell with the NVR is having some sort of negative impact. I recently noticed again that whenever I throw another application (another HA VM) at the Reolink Wi-Fi doorbell, timeouts and connectivity issues start to pile up - which points to an "overload" situation, whatever the exact cause might be.

Right now, I don't have the time or inclination to keep looking for the exact potential cause. My new Dahua IPC-PTS2449C-4E3Z-S-PV-PRO should arrive next week; I’ll integrate it with the NVR to replace my Imou Cruiser Dual Lens. I’ll need to make a few changes in HA anyway at that point, so I’ll also consider whether to keep the Reolink Wi-Fi doorbell integrated with the NVR. I also won't need the motion detection (MD) feature currently activated via the Reolink's own MD function anymore; instead, I’ll use the NVR’s IVS functions (AI-by-recorder) for the Reolink. In fact, I haven't used standard motion detection for years - I’ve always used IVS with line detection. I am currently using the NVR's two available 2-channel perimeter detection slots (AI by NVR) for my Imou Cruiser Dual; however, since the IPC-PTS2449C-4E3Z-S-PV-PRO can handle this itself (--> AI by camera), that function on the NVR will become available again, allowing me to use it for the Reolink Doorbell Wi-Fi. I'll see...

After all, it would be boring otherwise if you weren't constantly tinkering with something - or having to.


I’ll keep my fingers crossed that the problems don’t crop up for you as well when you update the firmware now.

So you did not have the issues until a newer firmware? I will update if I have any issues with this newer firmware though since my POE DB has the same firmware and has been running fine kinda doubt my WiFi will present any issues, but we will see.

Curious to know if your new NVR has any issue(s) with the ReoLink DB. As we know, all cameras have their limits on streaming, CPU speeds, memory, etc. Can't say this ReoLink is in the same league as our Dahua CAMs but it does preform better than my previous Hik DB which I ran for 3+ years prior to this ReoLink which is almost 4 years old.

Also, the RTSP vs. RTMP issue was more of a Blue Iris thing, I may try RTSP now with this new firmware, though I think I already have the answer to this since I have been running the Living Room POE for a few months now using RTSP
So it must of been the older firmware...



Thanks for all your post, you got me to upgrade my firmware, lol, which this old man don't budge much, lol Also learned I could of upgraded a long time ago, in that I did not lose the Diag. Log.

 

[David L]

Well so much for HA stopping messaging about upgrading firmware

No biggies, I am use to Skipping Update...

 

[Jim_OS]

So you did not have the issues until a newer firmware?

However, this problem was already present in older firmware versions. I had a Reolink Doorbell WiFi here for testing last year, and it was running older firmware at the time. It exhibited the same behavior back then, too - specifically, intermittent timeouts and a loss of connectivity whenever the doorbell was integrated into multiple applications or services (HA, NVR, app, etc.) simultaneously.

I observed this again this morning while using a dedicated HA test VM - which, as the name implies, I use solely for testing purposes. In this instance, I was testing the HA Core update 2026.9. When I integrated the NVR (which also includes the Reolink Doorbell WiFi) into this test VM, the doorbell immediately lost its connection and became unreachable - neither via the Reolink app nor through my production HA VM.

The fact that the Reolink Doorbell WiFi becomes unreachable in these situations is also recorded in the HA Core logs.

2026-09-05 10:18:25.401 ERROR (MainThread) [reolink_aio.baichuan.baichuan] Baichuan host 192.168.1.191: lost event subscription after 31.96 s and failed to reestablished connection
2026-09-05 10:18:36.347 ERROR (MainThread) [homeassistant.components.reolink.coordinator] Error fetching reolink.Doorbell data: Host 192.168.1.191:443: Timeout error:
2026-09-05 10:21:09.345 WARNING (MainThread) [reolink_aio.api] Error while logging out: Host 192.168.1.191:443: Timeout error:
2026-09-05 10:23:08.388 INFO (MainThread) [homeassistant.components.reolink.coordinator] Fetching reolink.Doorbell data recovered
2026-09-05 10:28:46.346 ERROR (MainThread) [homeassistant.components.reolink.coordinator] Error fetching reolink.Doorbell data: Host 192.168.1.191:443: Timeout error:
2026-09-05 10:29:07.592 ERROR (MainThread) [reolink_aio.baichuan.baichuan] Baichuan host 192.168.1.191: lost event subscription after 31.64 s and failed to reestablished connection
2026-09-05 10:31:19.346 WARNING (MainThread) [reolink_aio.api] Error while logging out: Host 192.168.1.191:443: Timeout error:
2026-09-05 10:34:20.102 INFO (MainThread) [homeassistant.components.reolink.coordinator] Fetching reolink.Doorbell data recovered
2026-09-05 10:37:01.501 ERROR (MainThread) [reolink_aio.baichuan.baichuan] Baichuan host 192.168.1.191: lost event subscription after 31.74 s and failed to reestablished connection
2026-09-05 10:37:23.344 ERROR (MainThread) [reolink_aio.api] Error while unsubscribing push: Host 192.168.1.191:443: connection timeout exception.
2026-09-05 10:37:23.346 ERROR (MainThread) [homeassistant.components.reolink.coordinator] Error fetching reolink.Doorbell data: Host 192.168.1.191:443: Timeout error:

Quite simply, the Reolink Doorbell WiFi cannot handle being integrated into "too many" applications if those applications trigger processes on the device; it just crashes or drops the connection.

In my setup, this means: when the Reolink Doorbell WiFi is connected to the Reolink app, the NVR (via ONVIF), and HA (via the Reolink integration), things generally run smoothly, with timeouts and connection drops occurring only rarely. When they do happen, it is often at night - for example, when motion detection (MD) picks up an animal or something similar. Presumably, this is because the IR function places an additional load on the doorbell at night - or for some other reason.

However, as soon as I access the doorbell's web GUI from a client (PC) during the day - or integrate it into another application, such as a separate Home Assistant installation or NVR software - the doorbell can no longer handle the load, and the problem arises.

I cannot say for certain whether the specific application accessing the doorbell - and the resulting "load" it places on the device - plays a role, though it almost certainly does. I likely wouldn't be dealing with this issue at all if I had integrated the doorbell solely with Home Assistant rather than also connecting it to my Dahua NVR. Ultimately, all I can do is try to keep the load on the doorbell as low as possible - for instance, by not enabling or using certain features and/or by reducing the frame rate (which I have already done), and so on....

In my opinion, trying to hunt down a specific "error" here - wherever it might be - makes absolutely no sense.

 

[David L]

Quite simply, the Reolink Doorbell WiFi cannot handle being integrated into "too many" applications if those applications trigger processes on the device; it just crashes or drops the connection.

In my setup, this means: when the Reolink Doorbell WiFi is connected to the Reolink app, the NVR (via ONVIF), and HA (via the Reolink integration), things generally run smoothly, with timeouts and connection drops occurring only rarely. When they do happen, it is often at night - for example, when motion detection (MD) picks up an animal or something similar. Presumably, this is because the IR function places an additional load on the doorbell at night - or for some other reason.

This is where I and most everyone here disagrees. This Thread would be full of complaints if this was the case for this Doorbell, there are very few here, I have been here since the start of this Thread.
I am not discrediting your problem, it may just be a bad DB, but we have done many test here and this DB has passed...I have my DB connected to Blue Iris, to HA (via VM), and sometimes I pull up a VLC stream on a PC or two and have had zero issues as you mentioned...pretty much the same with others here and some use the App too...personally I don't think firmware is playing a role in your issues, we have many here that has climbed the firmware upgrade ladder and have only mentioned feature changes, not streaming or reset issues.

I am throwing things out here to try. What about your power supply? It is very well known that these Video Doorbells need more AMPs, they draw more load. Now this is usually when they are in circuit (wired) with a chime. Can your transformer handle the load? I know you will point to your Dahua DB that worked fine but this is a different DB. Just something to look at...

If you take the DB off your NVR, do VLC testing even with HA connected, what are the results? Maybe the new NVR will be your fix?

As far as at night, IR will draw more power from the DB. There have been countless cases where people complained about their DB dying/resetting at night. Not so much here for the ReoLink, actually can't remember one complaint about that, think you are the first here, but probably because many here have already upgraded their transformers from previous DBs, but definitely in the Hik DB Thread.

I will share my story back 6 years ago, when I got my Hik DB, connected to my mechanical chime, sure enough I eventually figured out my 16V 10VA transformer was under powered, could not handle the extra load, when I upgraded to a 16V 30VA, no more issues...

 

[David L]

I think I am good with the firmware upgrade, no problems so far. You know i will share if so...

 

[Jim_OS]

Thanks for giving this further thought and suggesting possible solutions. I am well aware of everything you’ve mentioned; I’ve been using IP cameras (~ 20 years) and video doorbells (~ 6 years) for quite some time now.

And no, the doorbell transformer is a 24V model; it has reliably powered various video doorbells over the years without causing issues like this.

And no, it’s unlikely that my current Reolink Wi-Fi doorbell is simply "defective," because - as I mentioned earlier - I observed the exact same behavior last year with a different Reolink Wi-Fi doorbell.

While I haven't read through every single one of the roughly 2,000 posts in this thread over the past four years, the problem I described is reported - and thus confirmed - by other users if you look for it. It is also common knowledge that Reolink cameras don't exactly feature "high-end" hardware (CPU/RAM), and people frequently point out that you shouldn't "overload" them with processes. Even the developer of the Home Assistant Reolink integration mentions this, and it comes up regularly in the HA forum and GitHub discussions. Just to cite one example of a discussion on this topic:

www.reddit.com/r/reolinkcam/comments/1ixl2e8/constant_connection_issues_with_wifi_doorbell/

Even though this load-related issue can naturally stem from a wide variety of causes, and the problems described by users cannot be compared one-to-one.

It’s great if you and other users here aren't experiencing any load-related issues with the doorbell, but that doesn't automatically mean the problem doesn't exist. The actual cause can vary widely, so you can't necessarily draw conclusions based solely on the fact that it affects one user but not another. In any case, I am absolutely certain that I am experiencing this load issue with the doorbell, and I have already described how I am dealing with it. I am not going to waste any more time on this, as I have by now ruled out all possible causes - except for the doorbell itself.

Of course, I appreciate you trying to help me (and continuing to do so), but believe me: if you were sitting at my PC, you would eventually come to the conclusion that the Reolink Wi-Fi doorbell has a "load issue" here - one that you can't permanently solve, but can only try to mitigate.


Edit: Just an additional note on this, since the Reolink Wi-Fi Doorbell also occasionally "treats" me to this error message in Home Assistant::

Logger: aiohttp.server
Quelle: /usr/local/lib/python3.14/site-packages/aiohttp/web_protocol.py:546
Erstmals aufgetreten: 10:48:52 (1 Vorkommnis)
Zuletzt protokolliert: 10:48:52

Error handling request from 192.168.1.150
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_proto.py", line 143, in connection_lost
    uncompleted = self._parser.feed_eof()
  File "aiohttp/_http_parser.pyx", line 590, in aiohttp._http_parser.HttpParser.feed_eof
aiohttp.http_exceptions.TransferEncodingError: 400, message:
  Not enough data to satisfy transfer length header.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_protocol.py", line 575, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_app.py", line 559, in _handle
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 96, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 86, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 24, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 261, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 39, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 92, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/reolink/views.py", line 150, in get
    return await self.get(
           ^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/components/reolink/views.py", line 187, in get
    async for chunk in reolink_response.content.iter_chunked(65536):
        await response.write(chunk)
  File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 46, in __anext__
    rv = await self.read_func()
         ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 448, in read
    await self._wait("read")
  File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 365, in _wait
    await waiter
aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'>

Even though I don't really put much stock in answers from AIs, according to Gemini, a possible cause for this would be:

3. Too many simultaneous streams
Reolink cameras have very limited CPU processing power. If the official Reolink smartphone app is open, an NVR (Network Video Recorder) is recording, and Home Assistant is trying to fetch the stream all at the same time, the camera's internal web server can crash under the heavy load.

• Solution: Reduce the number of devices or apps accessing the camera stream simultaneously.

 

[David L]

Thanks for giving this further thought and suggesting possible solutions. I am well aware of everything you’ve mentioned; I’ve been using IP cameras (~ 20 years) and video doorbells (~ 6 years) for quite some time now.

And no, the doorbell transformer is a 24V model; it has reliably powered various video doorbells over the years without causing issues like this.

And no, it’s unlikely that my current Reolink Wi-Fi doorbell is simply "defective," because - as I mentioned earlier - I observed the exact same behavior last year with a different Reolink Wi-Fi doorbell.

While I haven't read through every single one of the roughly 2,000 posts in this thread over the past four years, the problem I described is reported - and thus confirmed - by other users if you look for it. It is also common knowledge that Reolink cameras don't exactly feature "high-end" hardware (CPU/RAM), and people frequently point out that you shouldn't "overload" them with processes. Even the developer of the Home Assistant Reolink integration mentions this, and it comes up regularly in the HA forum and GitHub discussions. Just to cite one example of a discussion on this topic:

www.reddit.com/r/reolinkcam/comments/1ixl2e8/constant_connection_issues_with_wifi_doorbell/

Even though this load-related issue can naturally stem from a wide variety of causes, and the problems described by users cannot be compared one-to-one.

It’s great if you and other users here aren't experiencing any load-related issues with the doorbell, but that doesn't automatically mean the problem doesn't exist. The actual cause can vary widely, so you can't necessarily draw conclusions based solely on the fact that it affects one user but not another. In any case, I am absolutely certain that I am experiencing this load issue with the doorbell, and I have already described how I am dealing with it. I am not going to waste any more time on this, as I have by now ruled out all possible causes - except for the doorbell itself.

Of course, I appreciate you trying to help me (and continuing to do so), but believe me: if you were sitting at my PC, you would eventually come to the conclusion that the Reolink Wi-Fi doorbell has a "load issue" here - one that you can't permanently solve, but can only try to mitigate.

Well I wish you the best of luck. Maybe it is time for you to move on to another DB. I have three of these, 2 POEs and a WiFi and have not experienced what you are mentioning, one POE I bought end of 2022 and WiFi Jan. 2023, the recent POE I picked up used here. If it were me I would of written the DB off long ago...you and me know a firmware is not going to fix your issue, as you stated, you believe it is a CPU issue, which works for me and many others here. There is a reason this Thread is quiet...

I am no way a ReoLink fan, many here are not either, most here have Dabua and Hik CAMs. I would of never owned a ReoLink but this DB is top dog presently...

Best Regards,
David

 

[David L]

Thanks for giving this further thought and suggesting possible solutions. I am well aware of everything you’ve mentioned; I’ve been using IP cameras (~ 20 years) and video doorbells (~ 6 years) for quite some time now.

And no, the doorbell transformer is a 24V model; it has reliably powered various video doorbells over the years without causing issues like this.

And no, it’s unlikely that my current Reolink Wi-Fi doorbell is simply "defective," because - as I mentioned earlier - I observed the exact same behavior last year with a different Reolink Wi-Fi doorbell.

While I haven't read through every single one of the roughly 2,000 posts in this thread over the past four years, the problem I described is reported - and thus confirmed - by other users if you look for it. It is also common knowledge that Reolink cameras don't exactly feature "high-end" hardware (CPU/RAM), and people frequently point out that you shouldn't "overload" them with processes. Even the developer of the Home Assistant Reolink integration mentions this, and it comes up regularly in the HA forum and GitHub discussions. Just to cite one example of a discussion on this topic:

www.reddit.com/r/reolinkcam/comments/1ixl2e8/constant_connection_issues_with_wifi_doorbell/

Even though this load-related issue can naturally stem from a wide variety of causes, and the problems described by users cannot be compared one-to-one.

It’s great if you and other users here aren't experiencing any load-related issues with the doorbell, but that doesn't automatically mean the problem doesn't exist. The actual cause can vary widely, so you can't necessarily draw conclusions based solely on the fact that it affects one user but not another. In any case, I am absolutely certain that I am experiencing this load issue with the doorbell, and I have already described how I am dealing with it. I am not going to waste any more time on this, as I have by now ruled out all possible causes - except for the doorbell itself.

Of course, I appreciate you trying to help me (and continuing to do so), but believe me: if you were sitting at my PC, you would eventually come to the conclusion that the Reolink Wi-Fi doorbell has a "load issue" here - one that you can't permanently solve, but can only try to mitigate.

Oh and Voltage is only one part, what is your amperage on your Transformer? Upping amperage is never a bad thing...

Here in the states, builder grade Doorbell Transformers don't cut it with these Video Doorbells...

 

[Jim_OS]

but this DB is top dog presently

I do have one more thing, actually. Since you’ve been using the Reolink Doorbell for so long, perhaps you can tell me how to prevent those pointless recordings that happen when it switches between day and night modes (and vice versa). I actually asked about this in another post a while back.

I’ve already set motion detection (which I don't need or want anyway) - which could be a possible cause - down to level 1. The recording mode is currently still set to "Auto," and IR is active for the night (naturally).



Yet, every single day, I get these two pointless recordings. Here’s an example from yesterday:



06:21:23 = Switching to day mode
06:43:48 = A cat
20:37:48 = Switching to night mode

The only other idea I have is to go into the Reolink app under Display —> Day and Night, switch the settings for “Color Day Mode” and “Black & White” from Auto to Manual, and then "play around" with the threshold values. But surely that can’t be the intended solution?

I’m not used to the day/night switch triggering a recording either - neither with my Dahua cameras nor with the doorbells I’ve used previously.

 

[David L]

I do have one more thing, actually. Since you’ve been using the Reolink Doorbell for so long, perhaps you can tell me how to prevent those pointless recordings that happen when it switches between day and night modes (and vice versa). I actually asked about this in another post a while back.

I’ve already set motion detection (which I don't need or want anyway) - which could be a possible cause - down to level 1. The recording mode is currently still set to "Auto," and IR is active for the night (naturally).

View attachment 248688

Yet, every single day, I get these two pointless recordings. Here’s an example from yesterday:

View attachment 248687

06:21:23 = Switching to day mode
06:43:48 = A cat
20:37:48 = Switching to night mode

The only other idea I have is to go into the Reolink app under Display —> Day and Night, switch the settings for “Color Day Mode” and “Black & White” from Auto to Manual, and then "play around" with the threshold values. But surely that can’t be the intended solution?

I’m not used to the day/night switch triggering a recording either - neither with my Dahua cameras nor with the doorbells I’ve used previously.

I am afraid I won't be much help to you on this since I do not use their App, mybe someone else will chime in. As far as Day/Night, I have my Dahuas setup this way but not for what this Doorbell does/offers, it only turns IR On/Off from what I can tell for Day/Night setting, Auto, Color will keep IR Off and Night will keep it On all the time from me just playing with it. For the Dahuas, Day/Night profile helps when switching and has many different options/settings, like shutter speed for one at night to mention one.

But you did get me to just now look at the local recordings, which I have not done since original setup, good to know my SD-Card is still recording



Since the switch of firmware I just now revisited the Record options (Thank You, your post is getting me to revisit the DB settings), since we have alot of bugs at night that seem to like the DB's IR as you can see in the above, I just turned Off Any Motion which hopefully will fix this. So, this is just for the SD-Card, I do not rely on the DB's motion for Blue Iris, I normally have ONVIF turned off since I use ProjectCode.ai for motion events, but since you have been posting I have turned it back On in BI to test...

Vehicle seems new, I don't remember, Pet, of course is new (beta) in this newer firmware.


Moth:
View attachment Doorbell-20260906011925-20260906011954.mp4

 

[David L]

Well look what I just found in BI after turning ONVIF back On.


View attachment DBWiFi.20260906_IR_turned_Off.mp4

 

[David L]

Well I am wrong about the Day & Night setting. IR does not stay On when choosing Black & White, so I am wrong in my thinking about what this Day & Night does. Dawn/Dusk type setting? Auto/Color/Black & White Force Color at Night is all I can tell now, or force Black & White during the day?

Guess I am thinking of Profiles in the Dahua CAMs.

 

[Jim_OS]

Well look what I just found in BI after turning ONVIF back On.

It’s reassuring to know that recordings actually get triggered for you, too - meaning I’m just too dense to set it up right.

I have my Dahuas setup this way

Yes, with Dahua, the day/night switchover isn't an issue at all, and it doesn't trigger any recordings. I’m pretty sure I just left that on the default setting - Auto - for all my Dahua cameras.

I only recall getting recordings back in the day - about ten years ago or so - when I was using Foscam cameras. They had that problem back then also with the day/night switching trigger. Perhaps Reolink is stuck in the past in that regard.

I just turned Off Any Motion which hopefully will fix this.

As I see it, the setting you changed under "Schedule" - specifically unchecking the "Any Motion" box - only applies to the recording times, and that is how I have mine configured as well.



However, that doesn't prevent a recording from starting - for instance, if the camera switches to night mode at 8:37 PM - even though the scheduled recording window is currently set only for the period between 8:00 PM and 7:00 AM.

If no user here - or in the HA forum where I also asked about this - has a sensible, working solution, then I’ll likely disable the Reolink doorbell’s recording function entirely; that way, it won’t matter if the day/night switching triggers anything. I’ll handle everything through my Dahua NVR instead.

 

[David L]

It’s reassuring to know that recordings actually get triggered for you, too - meaning I’m just too dense to set it up right.

Yes, with Dahua, the day/night switchover isn't an issue at all, and it doesn't trigger any recordings. I’m pretty sure I just left that on the default setting - Auto - for all my Dahua cameras.

I only recall getting recordings back in the day - about ten years ago or so - when I was using Foscam cameras. They had that problem back then also with the day/night switching trigger. Perhaps Reolink is stuck in the past in that regard.


As I see it, the setting you changed under "Schedule" - specifically unchecking the "Any Motion" box - only applies to the recording times, and that is how I have mine configured as well.

View attachment 248718

However, that doesn't prevent a recording from starting - for instance, if the camera switches to night mode at 8:37 PM - even though the scheduled recording window is currently set only for the period between 8:00 PM and 7:00 AM.

If no user here - or in the HA forum where I also asked about this - has a sensible, working solution, then I’ll likely disable the Reolink doorbell’s recording function entirely; that way, it won’t matter if the day/night switching triggers anything. I’ll handle everything through my Dahua NVR instead.

So I thought this RECORD section under Surveillance was a local Record for the SD-Card since it has an Overwrite setting?





I do see in the FTP section that it has its own Schedule and Overwrite setting which further makes me believe the RECORD section is for SD-Card...but I may be wrong...