I like this time of year, a chance to reflect on the last 12 months and take stock of accomplishments and realise the achievements. And something I like to gauge a success on is the longevity of a solution, and a time-lapse comparison 6 months apart is seemingly my go to example.
To elaborate on this achievement, earlier this year was the setup of a homebrew CCTV solution using an array of Raspberry Pi’s with cameras, and a VM Cent OS server acting as a PVR host. A surplus Pi W Zero was pointed at the hills and used as a time-lapse experiment.
The real achievement is that since its conception in early June,
it has been stable enough to run in the background, capturing footage for such an
occasion.
So here I present my latest time-lapse, a split screen video on the difference between a June day and a December day:
If you’d ever searched for Raspberry Pi projects that
involved a camera then the results would certainly include Motioneye OS, an
easy to use self-contained operating system that is truly (write then) plug and
play.
Looking for a CCTV project earlier this year I too was drawn in by this, and with my small abundance of RPi spares it was the cheapest choice, using a couple of RPi 3B+ for video, and a Zero W for time-lapse image capture. All processing was self-contained on each Pi with capture data passed over via SMB to a Windows file share.
This worked, but had a couple of problems that prevented it
from being trustworthy. Firstly, it stops recording video after a few days of
uptime, by creating empty files. And secondly the time-lapse camera seemed to
reset every few minutes that created in white out image capture as the camera’s
exposure setting recalibrated, ruining a time-lapse video.
Looking wider there was also the performance issue. In
Motioneye OS’ default state of managing all features, the highest FPS seemed to
max at 15 fps even on the Pi 3B+. Forums suggest this is due to the motion eye
daemon handling all the image processing in software, putting a strain on the Pi’s
modest CPU.
The idea and goal is to move the processing and IO
responsibilities to my server, which would be far more capable than the then
latest available RPi, and as I have chosen Cent OS to be my go-to Linux OS of
choice, this is what I’ll be using.
A gateway to make this possible is an option in Motioneye OS, Fast Network Camera. This when set relinquishes the Pi of all processing duties and serves to just stream the camera capture as best as possible via MJPEG.
Here’s how to set up Motioneye on a Cent OS server to be a central data hub for a network of RPi Motioneye OS cameras.
For a while I have been looking for simple CCTV solution, where video is captured on a long loop, so when the storage is full the earliest dated footage is deleted to make way for new. And of course, footage is available for immediate review.
Many newer IP cameras, including my Trendnet TV-IP572W comes equipped with a microSD slot for recording on a rotating basis. However, this has two main caveats, firstly the investment in a microSD card to be used solely for this purpose and of a high enough capacity to record enough footage, especially with the introduction of HD capture. Secondly is accessing the footage, as it is effectively held on the IP camera it is the gateway to the data. In my experience this process is slow, with having to download each video file manually and slow transfer speeds.
Imagine wanting to view an event that could have happened over a span of a few hours, and with video captured in segments of 5 minutes at most, the whole process can become tedious very quickly.
Therefore, I came up with another solution, one that uses my server’s hard disks for video storage to save on money while allowing larger video retention than a micro SD card. Also the ability to automatically delete older files to make way for new. This method uses Samba settings of an IP camera to save video to a Windows Server, and on the server itself, employing Disk Quota management to effectively trick the camera into thinking it only has a certain amount of disk space, to allow the cyclic video retention and prevent the footage taking up a whole drive on the server.
