mirror of
https://github.com/skoelle/moonweb-site.git
synced 2026-09-18 01:10:25 +00:00
content improve 2
This commit is contained in:
@@ -11,7 +11,10 @@ layout: base.njk
|
||||
<p>A Raspberry Pi Zero W mounted near the balcony acts as a small,
|
||||
self-contained smart-balcony controller: light control, an internet
|
||||
radio player, sensor readings, and its own backup/monitoring, all on
|
||||
very modest hardware.</p>
|
||||
very modest hardware. The goal is to make the balcony a more pleasant
|
||||
space — light control when it gets dark, background music while sitting
|
||||
outside, and temperature readings to know what to expect before stepping
|
||||
out.</p>
|
||||
|
||||
<h2>What it does</h2>
|
||||
<ul>
|
||||
@@ -21,6 +24,16 @@ very modest hardware.</p>
|
||||
<li><strong>Internet radio</strong> via a lightweight command-line audio player, controlled by a small custom tool ported from an earlier bathroom-Pi project.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Hardware details</h2>
|
||||
<p>The Pi Zero W is connected to an ESP32 microcontroller that handles
|
||||
the actual light switching via a relay module. Communication happens
|
||||
over HTTP — the Pi sends a simple request to toggle the relay, and the
|
||||
ESP32 responds with the current light state. The ESP32 also reads a
|
||||
DHT22 temperature and humidity sensor, publishing the values to MQTT
|
||||
for the home dashboard. This split makes sense: the Pi handles the
|
||||
user-facing logic (audio, buttons, internet radio), while the ESP32
|
||||
handles the real-time hardware control.</p>
|
||||
|
||||
<h2>Monitoring & backup, even on tiny hardware</h2>
|
||||
<p>Despite the very limited RAM, this Pi still participates in the same
|
||||
Prometheus monitoring pattern as the rest of the fleet — with the metrics
|
||||
@@ -33,6 +46,7 @@ configuration to the NAS over the internal network.</p>
|
||||
<ul>
|
||||
<li>Adding a USB webcam stream, mirroring the pattern already used for the 3D printer.</li>
|
||||
<li>Migrating onto the planned isolated IoT network segment once that's fully set up.</li>
|
||||
<li>Adding weather data from the DHT22 sensor to the LED matrix displays around the flat.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -72,3 +72,15 @@ sections:
|
||||
<p class="site-intro">The heart of the homelab. Home Assistant, MQTT sensors, dashboards, and automation projects that make everyday life a little more interesting.</p>
|
||||
|
||||
{% include "card-grid.njk" %}
|
||||
|
||||
<section class="about-expanded">
|
||||
<h2>The stack</h2>
|
||||
<p>Everything connects through MQTT. HomematicIP thermostats report room temperatures via Home Assistant automations, Tasmota smart plugs feed energy data, and various ESP32 and Raspberry Pi devices publish sensor readings. InfluxDB stores the time-series data, and Grafana dashboards visualize it all in real time.</p>
|
||||
<p>The home dashboard runs on multiple touch displays around the flat: an ESP32-S3 WT32-SC01 in the living room and an M5Stack in the study. Both show room temperatures, energy usage, and quick-action buttons for lighting and music control.</p>
|
||||
|
||||
<h2>Automation philosophy</h2>
|
||||
<p>The goal is subtle automation that improves daily life without being intrusive. Lights turn on when someone enters a room, music starts playing in the bathroom when the light switches on, and LED matrix displays show the time, weather, and laundry status. But nothing talks unless spoken to — no voice assistants, no always-on microphones, just simple sensor-driven automation that runs locally without cloud dependencies.</p>
|
||||
|
||||
<h2>Self-hosted services</h2>
|
||||
<p>Beyond hardware automation, several self-hosted services run on the Synology NAS: TubeArchivist for YouTube archiving, OctoPrint for remote 3D printer control, iCloud Contacts Sync for keeping the address book up to date, and a Google Calendar sync for dashboard widgets. Each service is containerized and backed up as part of the NAS backup strategy.</p>
|
||||
</section>
|
||||
|
||||
@@ -10,7 +10,9 @@ layout: base.njk
|
||||
|
||||
<p>A Raspberry Pi 3B runs OctoPrint for remote 3D-printer control, plus a
|
||||
live camera stream so print progress can be checked without walking over
|
||||
to the printer.</p>
|
||||
to the printer. This eliminates the need to stand next to the printer
|
||||
watching the first layer — a quality-of-life improvement that's hard to
|
||||
go back from once you've experienced it.</p>
|
||||
|
||||
<h2>Current setup</h2>
|
||||
<ul>
|
||||
@@ -19,6 +21,14 @@ to the printer.</p>
|
||||
<li><strong>Container management</strong> (Portainer, cAdvisor, a node exporter) runs alongside, giving the same monitoring pattern as the rest of the fleet.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Camera and streaming</h2>
|
||||
<p>The camera setup uses a standard USB webcam connected to the Pi. The
|
||||
camera-server project provides two streaming modes: MJPEG for the
|
||||
OctoPrint dashboard (low latency, works in any browser) and HLS for
|
||||
remote viewing over slower connections. The MJPEG stream is the primary
|
||||
way to check on prints — it loads quickly and updates in real time in the
|
||||
OctoPrint web interface.</p>
|
||||
|
||||
<h2>History</h2>
|
||||
<p>This Pi originally also had a small status display attached; the
|
||||
display was later moved to the backup Pi (which benefits more from local,
|
||||
@@ -30,6 +40,16 @@ that point to better reflect its now-singular focus on the printer.</p>
|
||||
<p>After moving this Pi to a newer OS release, boot configuration files
|
||||
moved to a new path — editing the old path silently does nothing, which
|
||||
is an easy trap when following older notes or tutorials for the same
|
||||
hardware.</p>
|
||||
hardware. The lesson: always verify that configuration changes actually
|
||||
take effect, especially after OS upgrades on embedded hardware.</p>
|
||||
|
||||
<h2>Why Docker on a Pi</h2>
|
||||
<p>Running OctoPrint in Docker on a Pi 3B might seem like overkill, but
|
||||
it provides consistency with the rest of the fleet. The same Portainer
|
||||
interface manages this container alongside the NAS services, the same
|
||||
monitoring stack collects its metrics, and the same backup strategy
|
||||
covers its configuration. The overhead of Docker on ARM is minimal for a
|
||||
single-container setup, and the operational benefits justify the small
|
||||
resource cost.</p>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -10,7 +10,9 @@ layout: base.njk
|
||||
|
||||
<p>TubeArchivist runs on the Synology NAS via Docker Compose, self-hosting
|
||||
a searchable archive of downloaded YouTube content (Elasticsearch +
|
||||
Redis + the TubeArchivist app itself).</p>
|
||||
Redis + the TubeArchivist app itself). It's used to archive channels
|
||||
worth rewatching — tutorials, long-form content, and anything that might
|
||||
disappear behind copyright strikes or channel deletions.</p>
|
||||
|
||||
<h2>Why this needed real troubleshooting</h2>
|
||||
<p>Running Elasticsearch on Synology's DSM kernel isn't fully
|
||||
@@ -23,8 +25,16 @@ without it, rather than fighting the kernel.</p>
|
||||
<ul>
|
||||
<li>Synology's Container Manager doesn't always auto-join containers to the same Docker network even when they're defined in one Compose file — an explicit named network avoids silent connectivity failures between the app, Elasticsearch, and Redis.</li>
|
||||
<li>A version upgrade of the app itself required a very specific step-by-step path (skipping versions breaks the database migration) rather than jumping straight to the latest release.</li>
|
||||
<li>Initial indexing of large channels takes significant time — Elasticsearch needs to build and optimize indices for full-text search across video titles, descriptions, and metadata.</li>
|
||||
</ul>
|
||||
|
||||
<h2>How it fits into the backup strategy</h2>
|
||||
<p>TubeArchivist data is split into two categories with different backup
|
||||
priorities. The downloaded media files and Elasticsearch metadata are
|
||||
backed up as part of the NAS backup volumes, since they take significant
|
||||
time to re-download and re-index. The Redis cache is excluded — it only
|
||||
holds session data and can be safely rebuilt on restart.</p>
|
||||
|
||||
<h2>What's backed up</h2>
|
||||
<table>
|
||||
<tr><th>Data</th><th>Included in NAS backup?</th></tr>
|
||||
@@ -33,4 +43,13 @@ without it, rather than fighting the kernel.</p>
|
||||
<tr><td>Redis cache</td><td>No — safe to delete/rebuild, only holds session data</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Day-to-day usage</h2>
|
||||
<p>Channels are added via the TubeArchivist web interface, which provides
|
||||
a YouTube-like browsing experience for the archived content. New videos
|
||||
from subscribed channels are automatically downloaded on a schedule. The
|
||||
search function indexes titles, descriptions, and metadata, making it
|
||||
easy to find specific videos in a large archive. The system runs headless
|
||||
on the NAS with no dedicated display — all interaction happens through the
|
||||
web interface or the companion mobile app.</p>
|
||||
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user