Metric Tons of Imperialism

I agree with you when it comes to spending money on real security. I spent ~$250 for everything including accessories for final placements of camera housing and cabling, and have some surplus to place another 2 cameras. If I had a nicer place or kids at home I'd scale up that budget considerably. In this particular setup, I believe RPi Zero W lacks the processing power to impose meaningful end-to-end encryption on the transmissions. Should we use more powerful Pi boards then it stops being cost-effective for its purpose. So there's that for me.

motioneyeOS offers 'surveillance credential' option, but the credentials are really transmitted in plain text (found out thru trying to set up in my NAS software...) this is a major limitation in its security that I have no ways to overcome with my knowledge. Right now all my satellite cameras are connected to bridge router with WPA2-personal keys, I might try to deploy a RADIUS server at the parent router level to see whether it helps. I don't even know whether motioneyeOS takes this kind of login so have to try out. As for defending attacks from within, I guess that's related to my housekeeping skills

First of all I'm a complete normie and can only work with existing materials or code pieces... A bit more than 2 months ago I started deploying my home surveillance setup with PI Zero Ws and a Pi 3B (right when Pi 4B turned up but motioneyeOS had not supported Pi 4 at that time, I did get one afterwards and you'll see in a bit) For the most part I installed motioneyeOS on Pi Zero W boards (I call them satellites) with one CSI camera attached to each. the Pi 3 model B board with no camera attached is serving as the hub, motioneyeOS installed. As for networking, I initially connected all satellites to my router via wifi, Pi Zero W supports only 2.4GHz so I spared 5GHz bands for laptops and other modern devices. hub was connected with a cable to the router. I have a DS218j NAS wired to the router as well, so naturally I planned to record directly to the NAS. I finished setting up this first loadout step-by-step from what's in the original post (big thanks for putting the info together btw). From the browser frontend, the monitoring quality seems fine, I had every satellite on 800x600@15FPS and hub recording with H.264/OMX encoder, leaving enough bandwidth for my other wireless devices. #H.264/OMX (as opposed to H.264) means it uses hardware encoding offered by Raspberry Pi's GPU, significantly reduces CPU usage on hub, H.264/OMX is currently NOT usable in Pi 4B version of motioneyeOS(20190911), see https://github.com/ccrisan/motioneyeos/issues/2043 note: latest motioneyeOS dev build(dev20191031) will show OMX for Pi 4 but it will NOT output recorded files unless you apply fixes specified by the author and collaborators, info can be found in his github, I'm too dumb to understand how the fixes work... There's also a V4L2 encoder in this dev build but it's meant for ODroid XU4 and if you force it on RPi the video will has a green overlay. Anyway, using Pi 3B as hub was fine until I realize ALL recorded footage during daytime have very low FPS(2~3), at first I thought it's a processing power issue so I OC'd all satellite to turbo in motioneyeOS settings. It didn't help much and making it worse, my satellite boards were heating up that it will crash without rebooting. It's only recently that I realize wifi signal was the issue. so I pulled out my surplus wifi router and set it as wireless bridge mode, placing it physically closer to satellites (all at first floor, surrounding living room, kitchen and garage). Then I move the hub to be physically connected to the bridge router, to have shortest latency and strongest connection with satellite boards (hopefully, lol), AND set to record footage directly to onboard micro SD card(128GB). Recorded footage's FPS is greatly improved, I finalized satellite settings at streaming 1024x768@10FPS,quality 10%, all with medium OC. And hub is set to record motion triggered footage, using H.264/OMX encoder@75%quality, directly to onboard microSD card, and upload via SFTP protocol to my NAS after each footage is recorded, onboard footages are kept for 1 week to save space. #NAS write speed was another issue, I have 2 Toshiba 8TB HDD in it and they are good for backup and archival purpose, but real-time CCTV recording was apparently something they are not up for. After I switched from directly recording to NAS to rather upload media files to NAS via SFTP protocol, this problem is considered resolved to me. I shortened time-to-keep period on hub to 1 week and if things run stable, I will further shorten it to 1-2 days to achieve a cleaner running environment (and security concerns as well cause I'm not sure about encryption status of the micro SD cards). Now that it's November 2019, after the latest firmware update for Pi 4 rolled out that helps greatly with thermal management (apply fix manually or automatically in Raspbian), I installed latest Raspbian on it and set up motioneye with default loadout. #The author, Calin Crisan, provided most information you need together in his github pages. Specifically, I followed instructions here to set up motioneye in Raspbian https://github.com/ccrisan/motioneye/wiki/Installation #You will notice that Mr. Crisan recommends the use of motioneyeOS for SBCs like Raspberry Pi, but since Pi 4 support is very early stage and it has a much stronger CPU than every Pi before it, I believe running motioneye in Raspbian on Pi 4B is a better choice for now, and you do have better customization with this setup if you know your way around it. This hub setup can record footage from all 3 satellite during daytime (where output data is at peak due to the nature of motion JPEG) and at much lower CPU usage (15~20%, only in motioneye+Raspbian, NOT in motioneyeOS, I don't know why, maybe early optimization issue). I also noticed significantly higher monitoring FPS from browser (on another PC ofc, monitoring in Raspbian's Chromium browser while acting as a hub completely tanks your CPU). #If you followed installation instructions, the motioneye session will start automatically when Raspbian is booted up, essentially as hassle-free as using motioneyeOS. #The catch for motioneye+Raspbian setup, is that you lose certain options to conveniently set things up via browser frontend, such as ALL expert settings and options to record to NAS directly(you have to manually config it through terminal, not a problem for pro people I think), etc, while available in motioneyeOS. However, H.264/OMX is usable on Pi 4B in this setup, so it can bypass some optimization issue that a specially build motioneyeOS img has to overcome. Further testing shows that vedio encoding still very slow and outputs large low FPS vids. It might still be broken for Pi 4 and the option was probably just there as a place holder. I have finished testing and plan to replace my Pi 3B hub with newly configured Pi 4B hub. Might update soon. Nope, the Pi 3B hub works fine and will stay in place until major update hits Pi 4. #please note the difference between motioneyeOS and motioneye, the latter is developed first and can be installed on existing OS, mainly Linux distros like Ubuntu or Debian, but also Raspbian, WSL and Windows 10 virtual machine. I hope this is helpful to some people.