MotionEye on DietPi on Raspberry Pi: keeping an eye on things

You know you have a Raspberry Pi problem when you start searching around for projects just to use them up. But then, admitting you have a problem is the first step to recovery…

PiHole? Check. PDP-8 (plus intranet server and MQTT broker)? Check. Alarm clock? Check. Retro radio thing? Work in progress. Dream machine? Also in progress. Dot matrix printer server? More work in progress. Kodi on LibreELEC? Yup (but not sure if this one’s a keeper).

Raspberry Pi 3B with a hole hacked into the case for the camera. This is a Rev1.3 camera, not the latest, fancy 8MP version.

But I have this RPi 3B with a camera I mounted into the case. I’d experimented (or, to use the wife’s terminology, ‘pratted about’) with this setup for a while, then put it in a drawer. With all the other RPis.

However, a YouTube video about MotionEyeOS made me think that what my life was missing was a surveillance camera. So out came the Pi again.

Installing MotionEyeOS is as easy as installing any other OS – just burn the image to an SD card. It’s a vary pared-down version of Linux, created by Calin Crisan, with just enough of the OS to run his MotionEye application. This, in turn, is a web-based front end to the venerable motion application that has been available in Linux (and elsewhere, for all I know) for a long time. I once used motion to try to capture pictures of a fouine (stone marten) that had taken up squatting rights in our attic. That was with an old-fashioned USB webcam connected to a desktop PC. We’ve come a long way. I never did get the pictures of the marten. The little bastard spent every winter for years in our attic.

Anyhoo, once MotionEyeOS is installed, you connect to your Raspberry Pi using a browser. And it works, just like that.

But you can see that this post doesn’t end here, so you probably suspect that things didn’t go quite that smoothly. Well, you’re right.

B0rked again…

I decided that I would rather not have the admin web interface for MotionEye on the standard HTTP port 80, as MotionEyeOS has it. (It’s more common for MotionEye to use port 8765 out of the box.) So I changed it to 8081 in the configuration.

That was a mistake.

What I didn’t know is that port 8081 is already used by MotionEye to provide a constant video stream. (And by the way, this video stream is on by default, with no authentication required, which seems a serious security flaw – as does the way MotionEyeOS allows admin login with no password by default and without forcing you to change it on first use.)

When you connect to MotionEye on 8081, you get the video image but no access to the management pages. Trying port 80 again after my change didn’t work because it’s no longer listening there. It’s a flaw in the software that it allows you to reconfigure the main port to one that’s already in use.

I posted a question on the Github page about this, but figured I was probably looking at reflashing the SD card and starting again. No big deal. But then I remembered something…

The DietPi way

I’d recently been playing around with DietPi, which is a distro I like a lot. It’s lean but easily configurable. And it works especially well if you want to use a single board computer (SBC) for a dedicated application.

The MotionEye admin screen.

I’d already used it successfully once to install NextCloud on the Pine A64 and had been pratting around with putting NextCloud on the Odroid HC1 (that’s a whole other story; in brief, it works but needs a bit of fiddling about with the install sequence). In the process, while using the dietpi-software utility, my eye had been caught by the existence of MotionEye on the optimised software list. Hmm…

So, with DietPi downloaded and installed on the Raspberry Pi, I was back in business. It works at least as well as MotionEyeOS, but on an OS build that is more capable) in case you want to do other stuff in the background) but still pleasingly lightweight.

Storing images

By default, MotionEye stores its still images and video files on the Raspberry Pi’s SD card. That’s sub-optimal. Doing lots of writes of lots of files to an SD card might be more stress than it enjoys. And it would be easy to fill the card. Filling up a storage device is annoying enough, but when it’s the one from which the OS is running, that can make life difficult.

Luckily, MotionEye makes it easy to store images elsewhere.

On the MotionEyeOS installation earlier, I’d noticed an option to put the files on a network share. So I configured it to save files to my NAS box via SMB (I set up a special user and share on the NAS for this purpose). That worked fine.

But the MotionEye installation on DietPi didn’t have this option. I thought that maybe the SMB client wasn’t installed on DietPi by default, which turned out to be true. I installed it via dietpi-software, but that didn’t fixed the problem.

What did fix it was using dietpi-drive_manager to set up a connection to the NAS independently of MotionEye. I chose a mount point of /mnt/nasiot (the second part is arbitrary – choose whatever suits you) and then, in MotionEye, entered that as the path to store images.

A better way

I still wasn’t happy, though. My experience with NAS and SMB shares is that they drop offline when you most need them. Having a surveillance camera be reliant on a network connection seems a sub-optimal solution.

File storage is set to use the SMB share on my NAS that I’ve mounted at /mnt/nasiot. I’ve also opted to upload all image and video files to a folder on Dropbox.

During my pratting about, I tried a couple of other options. One was to plug in a USB thumb drive and use that for storage. (Again, the mount point can be set permanently with dietpi-drive_manager or by editing fstab directly.) A 64GB drive will offer plenty of space and, even if it fills up, won’t impinge on the OS. That means the camera always has local storage of the files. So this is what I’m going to do as soon as the small USB sticks I’ve ordered from Amazon arrive.

Then there are useful parallel solutions. MotionEye gives you the option of uploading files to a remote server or service. To try this out, I configured my NAS to provide FTP services, created a user and fed the FTP account credentials into MotionEye. It means that copies of any still images or video files saved locally are also automatically uploaded to the NAS as a backup. Belt and braces.

But then I settled on yet another option – Dropbox. You can obtain an API key and authorise MotionEye from within the app itself. Not sure if you already need a developer account (I have one) but they’re free anyway – for ‘development’ purposes, that is. The advantage of using Dropbox over the NAS is that I get automatic offsite storage of all the files, as well as local copies on my Mac.

I’ll set the local files on the USB stick to auto-delete after a week, to stop the thumbdrive filling up, while Dropbox keeps an archive of the files.

As you can see, MotionEye is highly configurable, although there are some bugs. For example, I tried switching on automatic brightness, decided this made the image way too washed-out and switched it off again. Or, at least, I deselected the setting. But the image remained washed out until I changed the manual brightness level to another setting, then changed it back again.

Similarly, the exposure level setting seems to be a tad random – or easily and adversely affected by bright areas in the image. That can probably be overcome by careful placement of the camera – eg, if you’re using it indoors, don’t include a window. In the image above, of my extremely messy office, there is a bright window. A moment after I grabbed this screenshot, the image went very dark, fooled by the brightness of the scene outside.

But apart from some minor foibles, MotionEye is a great app, and an excellent use of a Raspberry Pi. So that’s another one accounted for. Now, many other do I have to use up? I’m too embarrassed to say…

3 thoughts on “MotionEye on DietPi on Raspberry Pi: keeping an eye on things

  1. KiraMayuri

    Thank you for posting this experience with DietPi and Motioneye. I am currently testing my way through some of the surveillance options for the rpi family. Atm running 8x Rpi Zero and a Rpi 3B with MotioneyeOS. Been brewing the thought of having DietPi with Motioneye on a dedicated board as server (Rpi3) and DietPi with Rpi-cam-web-interface on the multiple cameras (Rpi Zero’s). Hoping this setup will give me most performance aswell as the value Motioneye provides.

    Reply
  2. Andrey

    Thanks, this was really helpful. I quite dig DietPi as an underlying system as well, its just great in its features.
    Replicating your setup went well, also the samba mounting method, but now i hit a problem trying to record motion triggered clips.
    My motioneye would save pictures (manually triggered) on the NAS, but no videos. So i changed the movie format to MPEG4(.avi) and it works, suggesting there is some missing codecs for the hardware accelerated h265/omx(.mp4) option. I think that option would be the fastest due to hardware encoding?

    Since performance is quite an issue on such a small device, how would i be able to activate that codec in this setup/get it running?

    Thanks
    Andrey

    Reply
    1. Machina Post author

      To be honest, I haven’t even tried video – takes up too much disk space! When I get a chance I might experiment.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.