Raspberry Pi · IoT · Reef June 2026

A 24/7 Livestreamed Reef
with a Raspberry Pi Brain

Two of my interests collided on this one: marine reef keeping and tinkering with Linux. The result is a bare bottom nano reef that streams live to YouTube around the clock, with a Raspberry Pi quietly logging water parameters into a Grafana dashboard. Here is how the home lab came together.

The Idea

I run a small bare bottom nano cube, a 40x40x40 cm tank with a floating reef aquascape built on acrylic supports. Like any reef tank, it is a living system where small changes cascade: temperature drift, parameter swings, equipment failures. I wanted two things. First, to be able to watch the tank from anywhere, at any time. Second, to have real, logged data on what the water is actually doing rather than relying on spot checks with a test kit.

So the project split naturally into two halves: a 24/7 video livestream, and a sensor monitoring stack. Two separate machines, two separate jobs.

Part One: The Livestream

The camera is a Wyze Cam v2 pointed at the tank. The challenge with these cameras is getting a clean, reliable video feed off them without depending on the manufacturer's cloud app. The answer was a small Linux box running docker-wyze-bridge, which exposes the camera as a standard RTSP stream that anything can consume.

→
docker-wyze-bridge running in Docker pulls the camera feed and republishes it as RTSP, giving a clean local stream URL on the LAN.
→
ffmpeg pulls that RTSP stream and pushes it to YouTube over RTMP, with a keyframe interval tuned for streaming and a silent audio track, which YouTube requires for a valid live broadcast.
→
systemd service keeps the whole pipeline alive with auto-restart, so the stream comes back on its own after a reboot or a hiccup, with an ntfy alert if something goes wrong.

The Networking Lesson

The most interesting problem of the whole build was a networking one. Running the bridge on Docker's default bridge network, the camera connection kept timing out with an IOTC_ER_TIMEOUT error on local connections, while connections relayed through the manufacturer's servers worked fine.

The cause: the camera uses a peer-to-peer handshake to establish a direct LAN connection, and that handshake could not complete back through Docker's NAT layer. Relay traffic, which is outbound only, had no such problem, which is exactly why it masked the issue at first.

The fix Running the container with host networking puts it directly on the LAN, so the peer-to-peer handshake completes and the local connection is stable. The difference between a stream that works for a day and one that works for months often comes down to a detail like this.

One smaller but equally annoying lesson: a multi-line shell command with backslash line continuations was silently failing because of trailing spaces after the backslashes. Collapsing it to a single line solved it instantly. Hours can disappear into invisible whitespace.

Part Two: The Raspberry Pi Sensor Stack

The video answers "what does it look like right now". The sensors answer "what is the water actually doing over time". For this I used a Raspberry Pi running a headless Linux setup, dedicated entirely to reading sensors and logging data.

→
1-Wire and I2C enabled at the OS level, ready for temperature probes and other digital sensors. A quick check of the device tree and an I2C scan confirmed both interfaces were live before any sensor was even attached.
→
InfluxDB 2 as a time-series database, deployed via Docker Compose, storing readings in a dedicated bucket with infinite retention so the full history is always there.
→
Grafana for visualization, connecting to InfluxDB over the Docker network and rendering live graphs of the logged parameters.
→
Python in a virtual environment, using the InfluxDB client library to read the sensors and push measurements on a schedule.

Before any hardware arrived, I validated the entire pipeline with a small Python script pushing simulated temperature data every few seconds. Watching that fake data appear as a live line on a Grafana panel confirmed the full chain, from script to database to dashboard, was working. When the real probes arrive, only the data source changes; the plumbing is already proven.

Why test with fake data first Standing up the database, dashboard, and logging script against simulated data means that when the real sensors arrive, you are debugging one thing (the sensor reading) instead of five things at once. It is the same principle as building any system in testable stages rather than wiring everything together and hoping.

The Crossover

What I enjoy most about this project is that it sits exactly between two hobbies that look unrelated. Reef keeping is patience, chemistry, and observation. Linux tinkering is networking, containers, and automation. But the mindset is identical: a reef tank and a small server stack are both systems where monitoring matters, where small problems compound if ignored, and where the satisfying outcome is something that just quietly runs.

The same instincts that make me test a pipeline in stages, watch the logs, and set up an alert before walking away are the ones that keep a reef tank alive. The hardware is different. The discipline is the same.

What's Next

The immediate next step is wiring up the real temperature probe and expanding to other sensors over time. Longer term, the two halves can talk to each other: overlaying live parameter readings onto the video stream, or triggering an alert that is visible to anyone watching. For now, the tank streams, the data logs, and both run on their own.