Posts made by Steven Kan_61128021664

I'd like to put an RLC-410 up by my mailbox and trigger a recording any time my mailbox gets opened, along with the standard pre- and post-trigger time. I can't use motion detection because cars drive by 100x a day.

Some other camera brands have hardware triggers available, so that I could put a switch in my mailbox, and when it's opened, it triggers the hardware switch and captures a recording.

None of the Reolink cameras has a hardware trigger feature, as far as I know, but I was thinking I could detect the switch opening with a Raspberry Pi, if I could then send a software command (e.g. an HTTP request) to my Reolink camera to trigger a recording.

Note that I don't want to capture the recording on the Pi; I just want to send a command to the camera so that the camera does what it would normally do if it detected motion (e.g. record on the internal SD card and send the alert email, etc). Then I can log into the camera later and view the recording.

I've read through the CGI commands and I don't see any way to do this:

https://reolink.com/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf

Thanks!

Attached.

There really isn't an issue with my unit; it's just a general observation on all of your zoom cameras. They don't store focus points, and I was trying to figure out why.

Because they can't store focus, they rely on autofocus or manual focus, and manual focus has proven itself to be very difficult to use over high latency links, and I was trying to figure out why.
RLC-423_SystemInfo.png

You can request a JPG from a Reolink camera any time by using a URL such as:

http://192.168.1.11/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=abcde&user=anonymous&password=password

where:

1. 192.168.1.11 should be replaced by the IP address of your camera


2. abcde can be any string of characters (e.g. it's a dummy input, but required)


3. user and password are defined in your camera settings

If you have any sort of always-on computer available to run a script, such as a Raspberry Pi, you can set up a bash script using curl to take snapshots every X minutes and save them to a different filename, and then afterward use QuickTime Player 7 or ffmpeg or some other utility to concatenate them into a timelapse movie:

#!/bin/bash
cd /Users/steven/Documents/Beekeeping/BeeCam/TimeLapse/
while true
do
outfile=$(date +%Y-%m-%d-%I-%M)
outfile+=.jpg
curl -o $outfile "http://192.168.1.11/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=abcde&user=anonymous&password=password"
sleep 60s
done

Thanks! I'll try this sometime next week when my Raspberry Pi breadboard comes in and I can build my visible LED panel.

So this sorta works and sorta doesn't. I have two bash scripts set up. The first gets a token, so that I can authenticate commands for the next hour:

#!/bin/bash

ReolinkToken='curl -s GET "http://192.168.1.11/cgi-bin/api.cgi?cmd=Login&token=null" -d '[{"cmd":"Login","action":0,"param":{"User":{"userName":"admin","password":"MyActualPassword"}}}]' | jq -r '.[].value.Token.name''

echo $ReolinkToken

[if you attempt to copy/paste that into a real bash script, it will fail until you replace the single quotes ' around the curl command with other kind of quote character, `

I can't paste that into the forum, because it screws up the formatting]

This will return a token like "411d80b6c8c4dd0"

Then I have another script that accepts a token, a command, and a pause value in seconds:

#!/bin/bash

ReolinkToken=$1
Cmd=$2
Pause=$3

curl -s POST "http://192.168.1.11/cgi-bin/api.cgi?cmd=PtzCtrl&token=$ReolinkToken" -d '[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"'$Cmd'","speed":32}}]'

sleep $Pause

curl -s POST "http://192.168.1.11/cgi-bin/api.cgi?cmd=PtzCtrl&token=$ReolinkToken" -d '[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"Stop"}}]'

So if I execute:

./CommandPauseStop.sh 411d80b6c8c4dd0 ZoomDec 0.1

it will command the camera to Zoom Out, pause 0.1 seconds, and then Stop the camera.

It works for ZoomDec and ZoomInc, with pause intervals as short as 0.1. After each zoom event the camera autofocuses, and I have no control over that. But it appears to work properly.

FocusInc and FocusDec don't seem to work as well. Sometimes the commands appears to work, and sometimes they appear to do nothing, although I always get a rspCode of 200, which is "success".

FocusInc/Dec appears to work more reliably with a longer pause duration, but then that makes them less useful, since I have less granular control. It's possible that it takes a fraction of a second for the focus motor to start moving, so the Stop command comes in before it's actually done anything.

I'm still experimenting with this. But if the focus motor does have some latency and/or hysteresis, then this approach might require a firmware change, so that the timer runs internally to the camera instead of just on the client. If the focus motor latency is highly variable and the firmware has no way to detect whether it's actually moving or not, then it's possible that none of this might work. But I doubt that, because the firmware is capable of starting and stopping the focus motor quickly during autofocus, so somewhere inside its tiny brain it's capable of controlling it in small steps. We just need to be able to figure out how to tap into that control from the outside world.

I did some snooping of the http traffic from the client to the camera, and I now understand why manual focus is nearly unusable. Here's what the web client sends when you depress Focus In, e.g. a MouseDown() event:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"FocusInc","speed":32}}]

and when you release the mouse button, e.g. a MouseUp() event:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"Stop"}}]

The focus motor doesn't increment to a numerical position or by a numerical amount; it goes forward (or backward) until it's explicitly told to Stop, and timing of the Stop is based on a MouseUp() event in the browser. With the inherent latency in the video preview and the high latency of controlling this over the internet, accurate focusing based on visual feedback is virtually impossible.

I've also observed that changing the Speed value in the slider has no apparent effect on Focus and Zoom. The commands appears to change, but the Focus and Zoom motors appear to move just as fast at "speed":1 as they do at "speed":32.

So here's my proposed solution, which should be doable in software:

1. Interpret the Speed slider as a duration instead of as a speed indicator


2. Accept mouse clicks as discrete events instead of using MouseDown() and MouseUp()


3. Set a timer of X milliseconds, based on a factor of the Speed slider value


4. Run the selected motor for X milliseconds and then Stop, on each click of the mouse

It wouldn't be as good as a true numerically encoded position, but it would far, far better than what we have now. We'd be able to slowly increment the zoom or focus in or out, until we can visually verify the results we want, and it wouldn't be subject to the latency of the viewer or the connection.

In fact I might even try this from a .js application and see how well it works, since it can be done purely on the client side.

Got a compleately different answer from your support: due to hardware limitations it’s not possible to store focus information with the view presets.

This makes the RLC-423 a toy and not a surveillance camera. In more than 80% of the situations, the camara is not able to get a sharp picture after changing the view position.

I haven't had nearly this level of problem; my RLC-423 focuses correctly 90% of the time. But I certainly understand the issue.

I did some snooping of the http traffic from the client to the camera, and I have a theory as to why storing the focus is not possible. Here's what the web client sends when you depress Focus In:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"FocusInc","speed":32}}]

and when you release the mouse button:

[{"cmd":"PtzCtrl","action":0,"param":{"channel":0,"op":"Stop"}}]

The focus motor doesn't increment to a numerical position; it goes forward (or backward) until it's explicitly told to Stop.

My theory is that the focus motor has no position sensor or encoder. It's just forward/reverse commands with hard stops or software stops. The camera can't store position because there is no position to store.

This is not something that can be fixed in firmware. I suppose Reolink could create an algorithm to "accumulate" motion from the last known hard stop, and then home itself against a hard stop and attempt to recover the position with a timer, but that's unlikely to be more accurate than the current autofocus algorithm, which appears to work by detecting contrast.

If I'm correct, the focus/autofocus will never get any better without a hardware revision.

It's not a problem for me, because my camera focuses well enough for my application, but I can see why it would be in other applications.

Interesting. I haven't had that problem (yet). I have the RLC-423 staring right at the entrance to one of my established hives, and the bugs never both the camera at night. Then again I don't have the motion trigger turned on, because the bees are always moving during the day:

https://www.youtube.com/user/IAmTheWaterbug/live

Unfortunately the original article where I found that PDF link specifically said something like, "Not for personal use" or something like that, e.g. they don't support regular users like me. It's not really a public API.

Yes, I do have the latest firmware on all my cameras.

I could use a tiny camera inside the hive, but I wanted better image quality, so I've mounted the camera one the outside, like this:

http://www.kan.org/pictures/InteriorCameraThruBaffle.jpg

looking through a piece of glass:

http://www.kan.org/pictures/CameraFromInside.jpg

Hmmm. Here's an interesting anomaly. I have 4 Reolink cameras right now. Using that same "snap" command:

http://192.168.1.14/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=abcde&user=anonymous&password=password

and changing only the IP address for each of the four cameras, here's the size of the resulting JPG I get:

RLC-423 at .11 outputs 1536 × 864 despite video set for 2304 x 1296.
RLC-411 at .13 outputs 2304 x 1296, matching the video settings.
RLC-411 at .9 outputs 2560 x 1440, matching the video settings.
RLC-410 at .14 outputs 2304 x 1296, matching the video settings.

So why does the RLC-423 output the JPG at a different size from the video stream?

Ah, I just found this!

https://home-cdn.reolink.us/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf

It works! I just have to figure out how to get a Pi to turn on a set of visible LEDs and snap a photo every 10 minutes.

I know I can get emailed when motion occurs. I want to trigger a capture based on a external hardware trigger, like a signal from a Raspberry Pi, or on a software trigger, like a cgi command/http request.

Is there any way to use an electrical signal or software signal to cause an RLC-410 or RLC-411 to capture an image and upload it via FTP?

I want to do a time-lapse video inside a dark box (a beehive), but I want to turn on a light very briefly, once every 10 minutes, just to take an image and then shut the light off again, so I don't disturb the bees.

I don't want to use motion detection (caused by the light going on) because I'd have to collect a gazillion video clips and extract the frames I want. I want to leave my camera in daytime mode (even though it's dark), turn on the light every 10 minutes, wait 2-3 seconds for the camera to adjust, then take 1 still image and FTP it.

I going to set up two cameras looking into a dark box. I want Camera 1 to be in night vision mode all the time with its LEDs on, no matter what the illumination level. I want Camera 2 to be in daytime mode all the time, with its LEDs off, no matter what the illumination level. Separately I'm going to turn on a visible light every 10 minutes, so I can do a time lapse with Camera 2 (via FTP).

The problem is that Camera 1's LEDs are going to mess up the Camera 2's light sensor, and the periodic "strobe" is going to push Camera 1 out of night mode.

Is there a way to program these modes to On or Off, so that they're not dependent on the light level?

More detail:

I have an RLC-410 and an RLC-411 looking at a "swarm trap," intended to capture a wondrous event, as a feral swarm of bees moves in:

https://www.youtube.com/channel/UCIVY11504PcY2sy2qpRhiMg/live

and

https://www.youtube.com/channel/UC7FH1CCSdg1-W9mlJ52cceQ/live

I capture this type of event last spring, but with a terrible camera. I want to do this again, with two good cameras:

https://www.youtube.com/watch?v=Zwl-NjRIn6k&feature=youtu.be&t=2h44m0s

I also want to add a 3rd camera, looking in from the side, to build a time-lapse video of the honey comb being built, similar to what this guy did in 2010:

https://www.youtube.com/watch?v=MRuAMkRgnEE

Actually it looks like the image sensor difference might be a typo. The 5 MP sensor is taller, and should have the 1/2.7" sensor, whereas the 4 MP sensor should be 1/3.0". But my question about the power supply compatibility is the real question.

I need one more inexpensive camera, and I'm considering either the RLC-410 or the RLC-410W. The 410W model is actually less expensive right now, despite have the WiFi option (in addition to wired Ethernet).

Otherwise the specs look nearly identical except for:

RLC-410 Image Sensor 1/3" CMOS Sensor
RLC-410W Image Sensor 1/2.7" CMOS Sensor
which I assume is just rounding, e.g. I'm guessing they're the exact same sensor

and:

RLC-410 Power Supply 12V DC or 48V PoE (802.3af)
RLC-410W Power Supply DC12V

Does the 410W actually lack the 802.3af input? Or is that just an inadvertent omission? It would be most logical if the cameras were identical except for the WiFi addition, but I need to power this over 802.3af so I need to be sure. Thanks!

source:
https://reolink.com/files/docs/specs/RLC-410W-4MP-IP-Camera-Specifications.pdf
https://reolink.com/files/docs/specs/RLC-410-4MP-IP-Camera-Specifications.pdf

Allow lower resolutions via pixel binning, such as 1920 x 1080.

I'm going to reiterate this request. I'm trying to use a Raspberry Pi to put the RTSP stream from the RLC-423 directly out to a TV via HDMI, but the maximum resolution that the Pi can handle 1920 x 1080. The software (omxplayer) simply can't handle anything larger than that. There is no down-sampling option in the Pi because the decoding is done in hardware, and that hardware is limited to 1920 x 1080.

Doing the downsampling in software, via something like ffmpeg, won't work on a Pi because there's not enough computing power.

I just updated my BeeCam to v2.0.0.1288, and the image quality seems to be significantly improved!

Did Reolink actually do anything to the IQ? Or is the auto-focus improved?

Or is just me imagining things?

Watch this at 1080p; the bees look really sharp!

https://www.youtube.com/user/IAmTheWaterbug/live

I agree that saving the focus point as a part of each preset would be a very nice feature to add.

My BeeCam is a Raspberry Pi3/Raspbian Stretch w/freshly compiled ffmpeg version N-89882-g4dbae00bac running this as a service:

#!/bin/bash
cd /usr/local/bin/
while true
do
./ffmpeg -re -thread_queue_size 512 -rtsp_transport tcp -i 
"rtsp://anonymous:password@192.168.1.11:554" -i WilliamTellOverture.mp3 
-vcodec copy -acodec copy -t 00:11:51 -f flv 
"rtmp://a.rtmp.youtube.com/live2/my-youtube-streaming-key"
sleep 10s
done

where 192.168.1.11 is my spiffy new Reolink RLC-423S, and -t 00:11:51 is the length of my royalty-free MP3. This normally works quite well:

https://www.youtube.com/user/IAmTheWaterbug/live

and it loops continuously. The YT stream will glitch when it restarts, but the stream resumes with only about 15 seconds of video lost. It ran continuously overnight for at least 8 hours (e.g. many loops) before I started fiddling with it.

I changed the sleep to 5s, and that doesn't seem to bother it.

But on occasion I've done a sudo systemctl stop StreamToYouTube followed by sudo systemctl start StreamToYouTube, within 1-2 seconds (e.g. as fast as I can type Up Up Up and Enter), and sometimes when I do that, the stream fails, and ffmpeg starts dumping:

[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq e680 expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq 93ab expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq 93ac expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq e682 expected=0b49

endlessly.

Rebooting the Pi doesn't fix this (e.g. the YT stream still fails, and sudo systemctl status StreamToYouTube returns the same stream of "bad cseq" errors), but rebooting the RLC-423S does fix it. I'm wondering what exactly that error means.

During the "failed" state, the camera appears to be working properly from other clients, e.g. I can launch the Reolink.app on my Mac or view the camera's web page from any browser, and the video looks fine.

But for some reason the RTSP stream goes funky in a way that ffmpeg can't resolve.

It's quite repeatable if I stop/start the service quickly, but restarting with a 5 second pause in my script doesn't seem to bother it.

Thanks!
BadCseq.png