New Reolink Wired POE Doorbell Cam ?

[David L]

The switch is Ubiquiti USW-Pro-48-Poe with the newest firmware (and control software is also the newest publicly available version). All ports in use (48x1G+4x10G). 10+ ports are feeding PoE/+/++ power to devices.
These Reolink PoE doorbells are the only devices that does this connect/disconnect. Both this new one and the older one does this regardless of the connected port.
It is not also about power because I have tested with PoE and PoE+ and PoE++ connections. All other devices works fine like CCTVs in the same switch (Hikvision and Dahua).
Also it is not about the cable. Already tested this multiple times with multiple cables. The cables used are CAT7 sftp cables which are in perfect condition.

There is no port sleep ability in Ubiquiti switches, or timed PoE on/off ability. And still DB respond immediately when manually connected even when the log says it is disconnected.

I have noted that during those log claimed disconnect times no records are made to NAS either. Is there events to be recorded during those disconnect times is what I do not know and am worried about.
What I am worried is that what happens during those log claimed disconnected times. Is Reolink alive or not? Will all the events be recorded or not? How deep is the "sleep"? Is it the switch that interprete the device to go offline when there is no traffic?
What I know that if events happens often (like <15mins from event to next, dont know exact time) it does not disconnect (no makings to log). But if doorbell is inactive longer it goes offline (marking to log).
When in disconnect status (by switch log) when I connect directly to Reolink either by Reolink Android app or VLC/WinApp by Win11 computer it works fine immediately.

Either doorbell goes to active sleep (shutdown the connection/network) or markings in the log are faulty. Weird thing.

If the Doorbell does go to sleep, I am not aware of it since I have a RTMP stream 24/7 going to Blue Iris with No Disconnects or interruptions. Maybe that is what you need to do, You mentioned NAS, Synology? Try a steady 24/7 stream instead of motion events recording...or both, if Surveillance Station allows two streams, assume it would. On BI I have 24/7 stream to capture all footage and a motion detection stream with CPAI to send me notifications when people/animals/etc. are in view, also if someone rings the doorbell...

Unless I missed it in your post, I would try not using your switch power and power the Doorbell with an PoE Injector to eliminate any possible power compatibility issues. If on a VLAN, test a port without.

I will turn off my 24/7 stream for a couple of days to see if my Doorbell goes to sleep (disconnects on my pfSense router logs and or my TP-Link Managed Switch) I run an Enterprise network too, I have all Business switches...My Doorbell installed is the WiFi version, so my disconnects would be via RF if it went to sleep. But my logs should tell me.

 

[Zak]

You mentioned NAS, Synology?

Qnap

If the Doorbell does go to sleep, I am not aware of it since I have a RTMP stream24/7 going to Blue Iris with No Disconnects or interruptions. Maybe that is what you need to do,

I have 10 cams all running 20-30fps in 4K at very high bitrate. Would need an extremely powerful computer farm to run BI for all of those simultaneously which would need a small power plant to run that computer system and cost a fortune. FTP to NAS has been fine for now. These smart cams has analytics enough for my purposes. And if something happens that needs more attention I can use other video tools to clarify the case.

Try a steady 24/7 stream instead of motion events recording...or both, if Surveillance Station allows two streams, assume it would. On BI I have 24/7 stream to capture all footage and a motion detection stream with CPAI to send me notifications when people/animals/etc. are in view, also if someone rings the doorbell...

Unless I missed it in your post, I would try not using your switch power and power the Doorbell with an PoE Injector to eliminate any possible power compatibility issues. If on a VLAN, test a port without.

No VLANs for now. A private network behind couple of layers of very expensive corporate level firewalls and other security devices and arrangements.

Maybe later I will try injector(s).

But yesterday I tried the action you suggested above. I left the older DB as it was (recording by events) and set the new one in the cabinet to record constantly (20fps/2k res/6k bitrate) to see if the DB goes offline during the operation. Shortly; it stay steadily online. Not a one disconnection (again according to the switch log). The new DB in the cabinet has been running constantly now for about 20 hours and not a single connection drop out (and recorded 45Gb of data to NAS). Meanwhile during the same time event based older DB has dropped offline (and then back online) for 26 times! I tested earlier the newer doorbell by leaving it to cabinet for the whole night and the result was that it went (according to switch log) offline at 00.12 at night a while after I close the cabinet doors and went back online at 12:51 in the afternoon when I opened the cabinet again and the DB saw movement. Accoring to switch log it was offline for the whole time because obviously there happened nothing inside the cabinet (not even a curious mouse running around).

So all of this refer very strongly to some kind of sleep function in DB. But I cannot find a mention of it from anywhere, and there is no adjustment for it nowhere. If the DB sleeps and still is conscious enough to react to events and goes online to record the events then everything is fine. Only the log notes are confusing. But if it misses events because of this "sleep" then I have a problem (and all users should know about it too). Nothing else indicates that both DBs goes offline (disconnect) but the log of the switch. Which one is right, DB sleep or switch log? I just do not know.

I just want to be sure that DB records all events because it is a very important security issue. So am I the only one to note such behaviour?

 

[David L]

Qnap


I have 10 cams all running 20-30fps in 4K at very high bitrate. Would need an extremely powerful computer farm to run BI for all of those simultaneously which would need a small power plant to run that computer system and cost a fortune. FTP to NAS has been fine for now. These smart cams has analytics enough for my purposes. And if something happens that needs more attention I can use other video tools to clarify the case.


No VLANs for now. A private network behind couple of layers of very expensive corporate level firewalls and other security devices and arrangements.

Maybe later I will try injector(s).

But yesterday I tried the action you suggested above. I left the older DB as it was (recording by events) and set the new one in the cabinet to record constantly (20fps/2k res/6k bitrate) to see if the DB goes offline during the operation. Shortly; it stay steadily online. Not a one disconnection (again according to the switch log). The new DB in the cabinet has been running constantly now for about 20 hours and not a single connection drop out (and recorded 45Gb of data to NAS). Meanwhile during the same time event based older DB has dropped offline (and then back online) for 26 times! I tested earlier the newer doorbell by leaving it to cabinet for the whole night and the result was that it went (according to switch log) offline at 00.12 at night a while after I close the cabinet doors and went back online at 12:51 in the afternoon when I opened the cabinet again and the DB saw movement. Accoring to switch log it was offline for the whole time because obviously there happened nothing inside the cabinet (not even a curious mouse running around).

So all of this refer very strongly to some kind of sleep function in DB. But I cannot find a mention of it from anywhere, and there is no adjustment for it nowhere. If the DB sleeps and still is conscious enough to react to events and goes online to record the events then everything is fine. Only the log notes are confusing. But if it misses events because of this "sleep" then I have a problem (and all users should know about it too). Nothing else indicates that both DBs goes offline (disconnect) but the log of the switch. Which one is right, DB sleep or switch log? I just do not know.

I just want to be sure that DB records all events because it is a very important security issue. So am I the only one to note such behaviour?

You may want to reach out to ReoLink and see what they say.

Also, you would be surprised how Blue Iris handles 10 cameras, there are several here that have closer to 20 with no problems on a single older PC. I have had up to 6 CAMs on my 4th Gen PC running 24/7 streams Maxed bitrates, 4 were running at 30FPS with no problem. Since these are Security CAMS, I dropped the FPS to 15, the sweet spot for Security CAMS with matched iFrames which work best in BI. As far as expense, an older PC cost much less than one of your switches May be worth a try, you can do a trial with BI I think once you see all the benefits/options from BI you will drop the FTP fed. You could continue using your NAS in BI for storage.

I love my QNAP too. Six 16s gives me plenty of storage...

I will add one more comment, if you are running your 10 CAMS 24/7 then you will not miss any footage, but if not, I would not rely on the CAMS motion only. Motion events are good for getting notified when they properly detect but that is about it. In BI, it is very easy to see/find triggered events in its timeline...plus add CPAI in BI and you have even better individual detection.

HTH

 

[Zak]

You may want to reach out to ReoLink and see what they say.

Also, you would be surprised how Blue Iris handles 10 cameras, there are several here that have closer to 20 with no problems on a single older PC. I have had up to 6 CAMs on my 4th Gen PC running 24/7 streams Maxed bitrates, 4 were running at 30FPS with no problem. Since these are Security CAMS, I dropped the FPS to 15, the sweet spot for Security CAMS with matched iFrames which work best in BI. As far as expense, an older PC cost much less than one of your switches May be worth a try, you can do a trial with BI I think once you see all the benefits/options from BI you will drop the FTP fed. You could continue using your NAS in BI for storage.

I love my QNAP too. Six 16s gives me plenty of storage...

I will add one more comment, if you are running your 10 CAMS 24/7 then you will not miss any footage, but if not, I would not rely on the CAMS motion only. Motion events are good for getting notified when they properly detect but that is about it. In BI, it is very easy to see/find triggered events in its timeline...plus add CPAI in BI and you have even better individual detection.

HTH

Thanks for your comments David and for help. I really appreciate it.

A brief update to this weird behavior I wrote earlier:
I contacted Reolink support. Reolink first said that there is nothing which could make these marking to log and suggested that it is due to my network setup.

But eventually when the issue went all the way down to the R&D they found out that there really is an undocumented "sleep" mode which developers call as "low power mode". It seems that only very sophisticated systems acknowledge this power reduction somehow and my system interpret that as disconnection. It is not a deep "sleep", pretty shallow sleep and it should stay alive enough to react. So there really this phenomenon caused by the doorbell. Me and my systems were right! There are in average about 40 markings per day to the switch log caused by this low power mode. Not much, but that makes about 14600 garbage lines to the switch log every year. Useless disinformation.

Now, I have tested more (requested and instructed by Reolink R&D). There seems to be an "easy" solution to prevent the device from sleeping (=low power mode). It is to allow the doorbell(s) to call home = UID mode ON (=connecting to Reolink server which keeps the doorbell buzy enough that it don't get bored and fall a sleep => turning low power mode ON). Based on my testing that really seems to prevent those uninformative waste lines appearing to the switch log. But there is a catch in my case. A really BIG catch. Now because of security reasons my firewall is blocking the doorbell attempts to WAN and the doorbell is intensively trying to hammer by force through the wall about 300 times AN HOUR. That makes 2.62 MILLION lines of garbage per doorbell in a year to the log of my firewall. That is completely in the next level.

I just wrote this that if someone has also noted such weird connection/disconnection log events, it is caused by automatic undocumented low power mode which you do not know and cannot adjust in any way. You just need to live with it. And if you use UID mode and block it from connecting to WAN your firewall log is going to choke on gargabe.

I'll comment this BI thing a bit later.

 

[David L]

Thanks for your comments David and for help. I really appreciate it.

A brief update to this weird behavior I wrote earlier:
I contacted Reolink support. Reolink first said that there is nothing which could make these marking to log and suggested that it is due to my network setup.

But eventually when the issue went all the way down to the R&D they found out that there really is an undocumented "sleep" mode which developers call as "low power mode". It seems that only very sophisticated systems acknowledge this power reduction somehow and my system interpret that as disconnection. It is not a deep "sleep", pretty shallow sleep and it should stay alive enough to react. So there really this phenomenon caused by the doorbell. Me and my systems were right! There are in average about 40 markings per day to the switch log caused by this low power mode. Not much, but that makes about 14600 garbage lines to the switch log every year. Useless disinformation.

Now, I have tested more (requested and instructed by Reolink R&D). There seems to be an "easy" solution to prevent the device from sleeping (=low power mode). It is to allow the doorbell(s) to call home = UID mode ON (=connecting to Reolink server which keeps the doorbell buzy enough that it don't get bored and fall a sleep => turning low power mode ON). Based on my testing that really seems to prevent those uninformative waste lines appearing to the switch log. But there is a catch in my case. A really BIG catch. Now because of security reasons my firewall is blocking the doorbell attempts to WAN and the doorbell is intensively trying to hammer by force through the wall about 300 times AN HOUR. That makes 2.62 MILLION lines of garbage per doorbell in a year to the log of my firewall. That is completely in the next level.

I just wrote this that if someone has also noted such weird connection/disconnection log events, it is caused by automatic undocumented low power mode which you do not know and cannot adjust in any way. You just need to live with it. And if you use UID mode and block it from connecting to WAN your firewall log is going to choke on gargabe.

I'll comment this BI thing a bit later.

Wow, what a journey. Interesting about the low power mode on the DB. So motion wakes it up? Wonder if you sent continuous pings to it, will that keep it awake? If so, have a script running on one of your 24/7 machines. Of course, 24/7 streaming would also keep it awake, which many do here...

So noted, thank you for sharing this info...