Embedded / 2026
Raspberry Pi Control Server
A Raspberry Pi server with a Flask dashboard for system metrics, file management, and Arduino device control.
Context
The problem
Bring three different jobs—observing a server, managing its files, and controlling a device—into one usable interface. The browser has to connect software actions to physical behavior.
How it fits together
Architecture & approach
The application runs on Raspberry Pi and crosses a Linux-to-Arduino boundary. System metrics, stored files, and physical device state represent different kinds of information.
- BrowserInterface
- Flask · PiMetrics + files
- Node-REDHTTP → USB serial
- ArduinoLED + servo
My contribution
What I worked on
- Built Flask routes and views for CPU, memory, disk, uptime, and network monitoring.
- Added file uploads, downloads, and deletion on the Raspberry Pi.
- Connected browser controls to Arduino LEDs and a servo through Node-RED and USB serial.
Technical choices
The choices behind the work
Keeping files on the Pi and device state in a local JSON file makes the prototype straightforward to run. It also ties storage and runtime state to that machine.
The interface saves the requested LED and servo state after sending an HTTP request. The Arduino code does not report a physical-state acknowledgement, so the displayed value should not be mistaken for a measured hardware position.
The repository describes a trusted-local-network prototype. Authentication, production serving, connection recovery, and secure remote access remain future work.
Looking back
Results & current status
Functional local-network prototype with source code, interface screenshots, and demonstration videos. The interface records requested device state; physical-state acknowledgement and secure remote access remain future work.
Testing and evidence
The repository documents functional checks for monitoring, file operations, LED/servo controls, and the Flask–Node-RED–Arduino connection, with software and hardware demonstration links. These are project documentation and demos, not an independently reproduced reliability benchmark.
What I learned & what comes next
The code makes the distinction between a requested state and a confirmed physical state concrete. A next iteration would add acknowledgement, timeouts, and a visible disconnected state before treating a command as complete.
From the project
Screenshots
Keep exploring