SmartCam Edge Platform

Engineering challenge

Sites needed self-hosted camera monitoring with low-latency live view, local recording, and remote device configuration. Core capture, streaming, and storage had to run on Raspberry Pi at the edge — without requiring an external cloud service for those functions.

Objectives

• Deploy on Raspberry Pi with constrained CPU, memory, and disk
• Provide WebRTC live view suitable for browser clients
• Record to local storage with explicit retention and rotation policy
• Expose remote administration for configuration and health checks
• Run capture and streaming under systemd for restart and supervision
• Keep cloud off the critical path for recording and live view

Constraints

• Raspberry Pi CPU, memory, and thermal limits bound encode and stream concurrency
• Local disk capacity required retention and rotation under continuous recording
• Network conditions at the edge include variable uplink and NAT traversal for WebRTC
• Core functions must operate when external cloud services are unavailable
• Remote administration must not become a single point of failure for capture or recording

Solution architecture

Edge pipeline: camera capture → local encode → WebRTC signaling for live view, with parallel write to filesystem recording under retention rules. A lightweight administration API manages configuration; systemd units supervise long-running processes and recover from failure on the Pi.

Technology stack

• Raspberry Pi
• WebRTC
• Python
• systemd
• Local storage
• Remote administration

Implementation approach

• Built the capture and encoding path for Raspberry Pi camera hardware
• Implemented WebRTC signaling and media for browser-based live view
• Added filesystem recording with rotation and retention controls
• Developed remote administration for config and device status
• Packaged services as systemd units with restart policy and logging

Engineering decisions

• Kept recording and live view on-device so cloud is optional for core surveillance, not mandatory
• Chose WebRTC for browser live view to avoid proprietary viewer clients at the edge
• Separated capture/encode, WebRTC signaling, and administration into systemd units for independent restart
• Applied filesystem retention and rotation as first-class policy rather than relying on manual disk cleanup
• Sized encode settings for Raspberry Pi thermal and CPU budgets instead of desktop-class defaults

Operational considerations

• systemd restart policy and journal logging are the primary recovery path after process failure
• Disk usage must be observable before retention fails; storage health is part of day-two checks
• WebRTC sessions need operator guidance for NAT and firewall conditions at the site
• Remote administration credentials and API exposure require hardening on field-deployed devices
• Image and unit updates must preserve local recording continuity across restarts

Challenges

• Fitting encode and stream load within Raspberry Pi CPU and thermal limits
• Keeping WebRTC sessions stable across variable uplink and NAT conditions
• Preventing disk fill under continuous recording on finite local storage

Deliverables

• Raspberry Pi edge capture and encoding pipeline
• WebRTC signaling and browser live-view path
• Local recording with retention and storage rotation
• Remote administration API and configuration surface
• systemd unit definitions for process supervision

Lessons learned

• Encode settings that work on a bench Pi still need thermal soak testing under continuous recording
• Retention policy must be enforced in software; operators will not reliably prune disks by hand
• Splitting services under systemd isolates failure modes better than a single long-lived process
• WebRTC reliability at the edge depends as much on signaling and NAT handling as on encode quality

Future improvements

• Add hardware-accelerated encode paths where the Pi generation supports them
• Expose storage health and retention status through the administration API
• Improve NAT traversal documentation and optional TURN configuration for restricted sites
• Support multi-camera capture on a single host where CPU budget allows