Question regarding timeout (lost event subscription) messages from reolink_aio.baichuan.baichuan

[jim_os]

First of all: I don’t know if the topic of Baichuan host timeout times has already been discussed here. Unfortunately, I couldn’t find anything about it when searching.

I am using a Reolink Wi-Fi doorbell here, and because of this error message…

Logger: reolink_aio.baichuan.baichuan
Quelle: runner.py:280
Erstmals aufgetreten: 02:00:01 (1 Vorkommnis)
Zuletzt protokolliert: 02:00:01

Baichuan host 192.168.1.191: lost event subscription after 25.12 s and failed to reestablished connection

it seems there is a hard-coded timeout period that triggers this kind of connection error. In this specific instance, it occurred when the Reolink performed its weekly “maintenance reboot.”

Since I have also integrated the Reolink doorbell with my Dahua NVR, I can see in its logs that the doorbell disconnected around 2:00 AM (Note: In this case, the time on the NVR and HA is not 100% synchronized.)

with a user logout occurring - and then, about 60 seconds later, a user login took place once the camera became available again after rebooting.

01:55:29 = Disconnected
01:55:30 = User logout
01:56:33 = User login

In other words, rebooting the Reolink Doorbell Wi-Fi (in my case) takes about ~ 60 seconds. I’m wondering if that timeout period - which currently seems to be set to something under 30 seconds - could or should be increased to, say, 60 seconds plus a margin, so that these error messages don’t pop up “immediately” during brief connection drops, such as this maintenance reboot.

Yes, of course it makes sense for the Reolink integration to detect and report a loss of connection; the only question is how much time must - or should - elapse before such a notification is issued.

BTW: I am not a software developer, so I don’t know what the specific requirements are for HA; however, if increasing the timeout duration isn’t an option, perhaps that timeout message should be logged as a warning rather than an error.

Otherwise, I would/should also include them there as “critical” instead of “error”

logger:
  default: info
  logs:
    pychromecast.socket_client: critical
    homeassistant.components.camera: critical
    homeassistant.components.onvif: critical
    reolink_aio.baichuan.baichuan: critical

…assuming that works with reolink_aio.baichuan.baichuan.

While there are notes in the documentation

Entities intermittently become unavailable - Reolink

the timeout issue isn’t addressed there in any further detail.

Presumably, @starkillerOG can speak directly to this, but - in case the topic has already been raised here - any other user could, of course, do so as well.

[starkillerOG]

So the error you are seeing here is raised because the always active TCP connection is unexpectedely lost.

HA keeps a TCP connection allive to the doorbell. In order to do this it sends a hearthbeat message every 30 seconds. The time you are seeing in the error is the time since the last (heartbeat) message was send to the doorbell. If no message is sent within something like 45 seconds, the doorbell will close the connection.

So its not a timeout. It only helps you understand why the camera might have dropped the connection. (If this number is >30 seconds there may be something wrong in the code and the heartbeat was not send in time, causing the doorbell to drop connection).

When a unexpected connection drop occurs, 3 attempts are made to reastablish the connection. If they succeed the heartbeat interval is dynamically adjusted to prevent these drops. If the re-connection fails a error is logged since this means HomeAssistant will no longer receive motion/AI push updates and automations will not work. Then every 1 minute a re-connection is attempted to restore normal operation.

Indeed a reboot will cause a unexpected drop in connection and therefore give this error 1x in the log.

For now I dont think its a big deal.
In the future I could lookup the schedualed reboot time and supress this warning during a 5 minute window around this. But for now I have more pressing issue to adress in the Reolink code.

[jim_os]

OK, thanks for the explanation. I think I’ll consider suppressing that notification in the logger using reolink_aio.baichuan.baichuan: critical. Error messages in the Core log - even if they are technically correct - “kind of bother me”. Especially when I can’t (really) prevent the error myself.

[ShadowFist]

Do you actually need that Auto reboot toggle enabled? What could go wrong if you disable it?

[jim_os]

That’s a good question. I’ve actually always had the settings for a weekly (maintenance) reboot enabled on all my cameras (various Dahua models and the Reolink Doorbell) as well as on my Dahua NVR. I can’t really say whether the RAM might otherwise fill up or something similar without this (maintenance) reboot, because I’ve never given it any thought or tested it out. But I assume the manufacturers had a reason for including it - otherwise, it wouldn’t be enabled in the default settings.

[ShadowFist]

My best guess is that it’s enable by default so that if a support issue comes along, the customer service guys don’t have to ask if the camera was rebooted (and the eventual lies from the customers who say it was when it wasn’t).

There’s a thread over on reddit about it here. A couple of scenarios are absurd, but most of the rest make sense. I suggest you either disable the auto reboot function entirely for a few weeks, or at least change the default reboot time.

[jim_os]

I’ve actually gone ahead and looked for a reason for this (maintenance) reboot, and Reolink, for instance, simply states: “An automatic reboot can optimize your Reolink device after prolonged operation.”

Gemini, for example, suggests the following reasons for this:

The setting for an automatic reboot (often scheduled once a week in the middle of the night) is a standard feature for IP cameras, routers, and NVR systems. The primary reason for this is to ensure long-term system stability.

IP cameras are essentially small, specialized computers that run continuously 24/7. A regular, scheduled reboot serves several critical functions:

** Clearing Memory Leaks: Even well-written firmware can contain minor code bugs. Over days or weeks, certain processes may fail to fully release the temporary memory (RAM). This causes the memory to slowly fill up, making the camera sluggish or causing it to freeze. A reboot completely flushes the RAM.*
** Cleaning the Cache: During continuous operation, temporary data and system logs accumulate. Clearing these temporary files allows the software to run smoothly again.*
** Refreshing Network Connections: IP cameras must maintain a constant connection with the local network, routers, cloud services, or DDNS servers. Occasional micro-drops or IP conflicts can cause the camera to lose connection or become unresponsive on the network. A reboot forces a fresh IP assignment and a clean reconnection.*
** Preventative Maintenance: Instead of waiting for the camera to freeze and fail to record—which could happen during a critical security event—the scheduled reboot proactively prevents the system from reaching a breaking point.*
** Fixing Hardware & Storage Glitches: For Pan-Tilt-Zoom (PTZ) cameras or models using MicroSD cards for local storage, a reboot helps clear read/write errors on the card and recalibrates the lens motors.*

Summary: The automatic reboot is a maintenance tool. It resets the camera to a clean, optimal state once a week at a time when security risks are usually lowest (e.g., Sunday at 3:00 AM).

But let me put it this way: I’ve been using IP cameras here for about ~ 15 years now, and this (maintenance) reboot is enabled by default on all of them - and I’ve always just left it that way. I’m not going to change anything about it now, just because of the error message from the Reolink Doorbell/Integration in the HA log. It’s not that important to me.

@ShadowFist

or at least change the default reboot time.

There isn’t much to change there. You can only select the day of the week and the time for the reboot to take place, but you cannot, for example, specify that the reboot should occur only once a month (or something similar).