content improve 6

hub/index.njk

@@ -59,3 +59,20 @@ sections:
 </div>
 
 {% include "card-grid.njk" %}
+
+<section class="about-expanded">
+  <h2>What this site is about</h2>
+  <p>moonweb is a collection of personal projects that have grown over the past 25 years. What started as a single 486 running a BBS in the mid-90s has turned into a full homelab with Proxmox, Docker, smart home automation, and a growing collection of retro hardware. The name "moonweb" comes from the original domain moonweb.org, which has been online since 2000.</p>
+  <p>Each section of this site documents a different part of the setup. The <a href="https://infra.moonweb.org">infrastructure section</a> covers the Proxmox cluster, Synology NAS, Docker containers, networking, and backup strategies. The <a href="https://smarthome.moonweb.org">smart home section</a> shows what automation projects are running, from Tasmota energy monitoring to MQTT sensors and AirPlay audio. The <a href="https://code.moonweb.org">code section</a> lists the public GitHub projects that power these setups, and the <a href="https://retro.moonweb.org">retro section</a> documents the hardware collection.</p>
+
+  <h2>What I do professionally</h2>
+  <p>I work as a Senior Software Developer &amp; Architect at TENHIL GmbH (formerly stellenanzeigen.de), where I build and maintain microservices on .NET Core and Kubernetes. My day job involves designing cloud-native architectures, building APIs, and migrating legacy applications to modern stacks. I've been working with .NET since the early 2000s and have used everything from ASP Classic to the latest .NET 8 features.</p>
+  <p>Since early 2025, I've fully embraced AI-assisted development. I use Claude Code for most of my private projects and at work for Jira story implementation. The productivity gains are massive, and it's changed how I approach software development entirely. I also use OpenCode with OpenRouter for Python-based home lab projects.</p>
+
+  <h2>The homelab</h2>
+  <p>The homelab has been evolving since the mid-90s. Today it runs on a Proxmox cluster with a Synology DS918+ NAS, multiple Docker hosts, and an OpenWrt router for multi-WAN failover. The setup includes Prometheus and Grafana for monitoring, InfluxDB for time-series data from smart home sensors, and a full backup strategy covering NAS snapshots, offsite copies, and cloud storage.</p>
+  <p>The smart home side includes HomematicIP thermostats bridged to MQTT, Tasmota smart plugs for energy monitoring, AirPlay multi-room audio on Raspberry Pi devices, and various ESP32-based dashboards and LED matrix displays. Everything is documented in the respective sections of this site.</p>
+
+  <h2>Retro computing</h2>
+  <p>Outside of work, I collect and maintain retro hardware. The collection includes Atari ST machines (a Mega ST 4 fleet and a Mega ST 2), Amiga systems, a 486 DX2-66 tower, and various MiSTer and MiST FPGA setups for preservation. I also run Batocera in the living room for casual retro gaming. The retro section documents the hardware, the maintenance, and the occasional deep-dive into compatibility issues like the 15kHz monitor problem on the Atari ST.</p>
+</section>

infra/docker/index.njk

@@ -53,11 +53,12 @@ layout: base.njk
 
 <h2>Application containers</h2>
 <ul>
-<li><strong>SearXNG</strong> — self-hosted, privacy-respecting metasearch engine.</li>
+<li><strong>SearXNG</strong> — self-hosted, privacy-respecting metasearch engine that aggregates results from multiple search providers without leaking queries to any of them. Used as the default search backend for local browsing and AI tools.</li>
 <li><strong>Open WebUI</strong> — chat interface for locally hosted LLMs.</li>
-<li><strong>Stirling PDF</strong> — self-hosted PDF toolkit for merging, converting and editing documents.</li>
+<li><strong>Stirling PDF</strong> — self-hosted PDF toolkit for merging, splitting, converting, compressing, and editing documents without uploading them to external services.</li>
 <li><strong>ArchiveBox</strong> — personal web archiving of bookmarked pages.</li>
 <li><strong>TubeSync / TubeArchivist [NAS]</strong> — download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
+<li><strong>Music Stretto</strong> — music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</li>
 </ul>
 
 <h2>Development tools</h2>

infra/index.njk

@@ -36,3 +36,15 @@ sections:
 <p class="site-intro">A peek under the hood of my homelab. Proxmox, Synology, Docker, and how everything is wired together.</p>
 
 {% include "card-grid.njk" %}
+
+<section class="about-expanded">
+  <h2>The setup at a glance</h2>
+  <p>The infrastructure runs on three main machines: a Proxmox VE host (Intel NUC, 64GB RAM) as the primary compute node, a Synology DS918+ NAS for storage and Docker services, and a Xubuntu VM on Proxmox for development. An OpenWrt router handles multi-WAN failover with WiFi and Powerline backhaul, and four Zyxel GS1200-8HP managed switches distribute the network across the flat.</p>
+  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a 3-2-1 strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
+
+  <h2>Why Proxmox</h2>
+  <p>Proxmox VE was chosen over alternatives like ESXi or plain Docker for several reasons. The open-source model means no licensing headaches. LXC containers provide near-native performance for lightweight services without the overhead of full VMs. The web UI makes it easy to manage snapshots, backups, and migrations. And the ZFS support on the underlying Debian system gives us reliable snapshots and send/receive for the backup chain.</p>
+
+  <h2>How services are organized</h2>
+  <p>The general rule: stateful services (databases, media archives, monitoring data) run on the Synology NAS where they benefit from the integrated backup and snapshot system. Stateless services and compute-heavy workloads run on the Proxmox Docker VM. LXC containers handle lightweight always-on services like Pi-hole and MariaDB. This separation makes it easy to tear down and recreate Docker containers without worrying about data loss.</p>
+</section>

infra/monitoring/index.njk

@@ -9,7 +9,9 @@ layout: base.njk
 <div class="detail-content">
 
 <p>Prometheus and Grafana form the central monitoring stack for the whole
-homelab, running as Docker containers on the NAS.</p>
+homelab, running as Docker containers on the NAS. Every machine in the
+flat — Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices —
+feeds metrics into this central instance.</p>
 
 <h2>What's monitored</h2>
 <ul>
@@ -27,6 +29,23 @@ homelab, running as Docker containers on the NAS.</p>
 <tr><td>Network printer</td><td>Toner level, page count, online/offline status via SNMP</td></tr>
 </table>
 
+<h2>How it's deployed</h2>
+<p>Prometheus runs as a Docker container on the Synology NAS with a
+bind-mounted data directory for persistence. Grafana is deployed as a
+sibling container, connected to Prometheus as its primary datasource.
+Both containers are defined in a single Docker Compose file and managed
+via Portainer. The Prometheus configuration file defines scrape targets,
+scrape intervals (15 seconds for hosts, 60 seconds for network devices),
+and retention policies.</p>
+
+<h2>Alerting</h2>
+<p>Basic alerting is configured through Prometheus Alertmanager, which
+sends notifications to a dedicated Telegram channel for critical events
+like host-down or disk-full conditions. The dead-man's-switch pattern
+ensures that if Prometheus itself stops scraping, an alert fires within
+minutes. More sophisticated alerting rules (disk space prediction,
+temperature thresholds) are planned but not yet implemented.</p>
+
 <h2>Open items</h2>
 <ul>
 <li>Alerting rules are not yet configured for most services.</li>

retro/amiga-hardware-landscape/index.njk

@@ -8,7 +8,7 @@ parent: "/"
 <h1>Running AmigaOS in 2026: MiSTer FPGA vs Amiberry on Pi</h1>
 <div class="detail-content">
 
-<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards — the question is which trade-offs you're willing to accept.</p>
+<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards — the question is which trade-offs you're willing to accept. Both approaches have their place, and the choice often comes down to what you're trying to do: run demos at perfect timing, or tinker with software at higher resolutions.</p>
 
 <h2>Two Roads to the Same Workbench</h2>
 <ul>
@@ -18,5 +18,29 @@ parent: "/"
 <li><strong>Picking a monitor</strong> — a 4:3 panel at native 1280×1024 (like an older NEC MultiSync) gives the most period-accurate Workbench experience; anything widescreen needs scaling compromises.</li>
 </ul>
 
+<h2>When to choose MiSTer</h2>
+<p>The MiSTer shines when timing accuracy matters. Demos that rely on
+cycle-exact raster effects, games that use custom hardware tricks, and
+software that depends on precise interrupt timing all benefit from the
+FPGA's hardware-level reproduction. The Minimig-AGA core also provides
+a more authentic floppy drive experience, including the characteristic
+drive sounds and seek times that software sometimes depends on for
+loading screens and copy protection.</p>
+
+<h2>When to choose Amiberry on Pi</h2>
+<p>The Pi is better for productivity and development work. Higher RTG
+resolutions make Workbench usable on modern monitors. The ability to
+easily swap between AmigaOS versions and hard disk images makes it
+ideal for testing software. And the lower cost means you can dedicate
+a Pi to Amiga development without tying up expensive FPGA hardware.</p>
+
+<h2>The compatibility question</h2>
+<p>Most Amiga software works on both platforms, but there are edge cases.
+Some demos use raster tricks that only work on real AGA hardware or the
+MiSTer's FPGA core. Some productivity software depends on specific
+accelerator card features that neither platform emulates perfectly.
+And the perennial question of Kickstart ROM versions — 3.1 for
+compatibility, 3.2 for features — applies equally to both setups.</p>
+
 <p class="redacted-note">Both setups now run side by side without any real winner — MiSTer for authenticity and demos, the Pi for tinkering and RTG resolutions.</p>
 </div>

retro/atari-networking-bbs/index.njk

@@ -18,5 +18,34 @@ parent: "/"
 <li><strong>File transfer the easy way</strong> — a plain FTP client on the Atari talking to a NAS on the local network sidesteps most of the internet-connectivity headaches entirely, especially for moving disk images and software archives back and forth.</li>
 </ul>
 
+<h2>Why connect a 40-year-old computer to the internet</h2>
+<p>The obvious question is "why bother?" — the Atari ST was never designed
+for the internet, and the experience of using it online is objectively
+worse than any modern device. But that's not the point. The real
+satisfaction comes from making old hardware do things it was never
+designed to do, understanding the networking stack at a level that modern
+abstractions hide, and experiencing the dial-up era's BBS culture on
+original hardware.</p>
+
+<h2>The BBS experience</h2>
+<p>Bulletin board systems from the dial-up era are still running today,
+maintained by enthusiasts who keep the old software alive. Connecting to
+one from an original Atari ST — via a Wi-Fi modem emulation — is a
+genuinely nostalgic experience. The ANSI art login screens, the message
+boards, the file sections, the door games — it's all exactly as it was
+in the early 1990s. The main difference: instead of tying up a phone
+line, the connection goes over Wi-Fi to a BBS that's accessible from
+anywhere in the world.</p>
+
+<h2>Lessons learned</h2>
+<p>The biggest lesson: networking on retro hardware is 90% patience and
+10% actual configuration. The STinG stack is well-documented but
+fragile — wrong TCP/IP settings silently break connections without
+useful error messages. The ESP32 Wi-Fi modules are cheap and flexible
+but require careful firmware selection for the specific use case. And
+terminal emulation is a rabbit hole of character sets, escape sequences,
+and display quirks that haven't been relevant for decades but still
+matter when connecting to a BBS that renders ANSI art.</p>
+
 <p class="redacted-note">If you're chasing BBS nostalgia on real hardware: budget far more patience for the networking layer than for the actual computer. The 1980s hardware is the easy part; convincing 2020s Wi-Fi and modern BBS ANSI dialects to cooperate is the real challenge.</p>
 </div>

retro/dos-486-tower/index.njk

@@ -1,20 +1,37 @@
 ---
-title: "The 486 DX2-66 Tower: An Original PC Living Alongside Its FPGA Twin"
+title: "The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA"
 section: "retro"
-description: "Keeping an original Colani-design 486 tower running while a MiSTer core covers the same era digitally."
+description: "Recreating a Vobis-Highscreen 486 DX2-66 setup on MiSTer FPGA, down to the original DOS configuration."
 layout: base.njk
 parent: "/"
 ---
-<h1>The 486 DX2-66 Tower: An Original PC Living Alongside Its FPGA Twin</h1>
+<h1>The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA</h1>
 <div class="detail-content">
 
-<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. Decades later, it's kept around as both a museum piece and a genuine gaming machine, running alongside a MiSTer FPGA equivalent.</p>
+<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. The original hardware is long gone, but the entire setup has been recreated 1:1 on MiSTer FPGA — same DOS version, same drivers, same AUTOEXEC.BAT and CONFIG.SYS, same directory structure.</p>
 
-<h2>Original Hardware vs FPGA Twin</h2>
+<h2>The original hardware</h2>
+<p>The Vobis-Highscreen was a premium PC in its day — the Colani design gave it a distinctive curved case that still looks futuristic. Inside it ran an Intel 486 DX2 at 66MHz with 8MB of RAM, a Sound Blaster 16, and a Tseng ET4000 graphics card. A 200MB hard drive and a 3.5" floppy drive completed the setup. The machine was the go-to system for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</p>
+
+<h2>The MiSTer recreation</h2>
+<p>The AO486 core on MiSTer FPGA reproduces the original hardware with near-perfect accuracy. The key was not just getting the hardware emulation right, but rebuilding the exact software environment: the same MS-DOS version, the same memory managers (HIMEM.SYS, EMM386), the same Sound Blaster drivers, and the same AUTOEXEC.BAT and CONFIG.SYS tuning that made the original machine run smoothly. Even the directory structure and file names match the original setup.</p>
+
+<h2>Context: DOSMENU</h2>
+<p>A key part of the preserved environment is <strong>DOSMENU</strong>, a boot configuration utility written in Turbo Pascal 6.0 in 1994 — originally developed specifically for this Colani 486 machine. DOSMENU let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load — a critical feature in the DOS era, where memory management was manual and games often required different driver configurations. Features included saveable presets, a built-in MOD player, PCX picture display, and a DoubleSpace memory unloader. The original source: ~50k of Turbo Pascal, roughly 1900 lines plus some inline assembler.</p>
+
+<h2>Why a 1:1 recreation</h2>
+<p>The point isn't just to play DOS games — it's to preserve the exact computing experience from that era. The way DOS memory management worked, the way sound drivers had to be configured manually, the way batch files chained together to create a usable environment. This level of detail is lost when you just launch a DOS game from a modern frontend. The MiSTer setup recreates the entire boot process, from BIOS POST to the C:\> prompt, just as it was in the mid-90s.</p>
+
+<h2>What's preserved</h2>
 <ul>
-<li><strong>The original tower</strong> — an Intel 486 DX2 @ 66MHz in its iconic Colani case, the go-to machine for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</li>
-<li><strong>MiSTer's AO486 core</strong> — a full FPGA-based 486 emulation, configurable across variants from 386SX all the way to 486DX4, using swappable virtual hard disk (VHD) images instead of a physical drive.</li>
-<li><strong>Open project</strong> — DOS-era BBS access is next on the list, likely tackled via the MiSTer core first since its networking path is simpler than wrangling period-correct ISA network cards.</li>
+<li><strong>DOS boot environment</strong> — the exact AUTOEXEC.BAT and CONFIG.SYS from the original machine, including memory manager configuration and Sound Blaster IRQ settings.</li>
+<li><strong>Game installations</strong> — original game installations with their setup utilities, configuration files, and saved games, all in the same directory paths as the original.</li>
+<li><strong>System utilities</strong> — Norton Commander, PKZIP, the usual toolkit of the era, all configured the way they were used daily.</li>
+<li><strong>DOSMENU</strong> — a custom boot configuration utility written specifically for this Colani 486 in 1994. Built in Turbo Pascal, it let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load — essential for managing DOS memory across different games and applications.</li>
+<li><strong>The quirks</strong> — the specific workarounds and tweaks that were needed to get everything running together, the kind of institutional knowledge that only exists on a well-used personal machine.</li>
 </ul>
 
+<h2>AO486 vs real hardware</h2>
+<p>The MiSTer AO486 core handles the emulation convincingly. Timing accuracy is good enough for games that rely on cycle-sensitive behavior. Sound Blaster emulation covers the standard OPL3 FM synthesis and digital audio. The main trade-off is that some hardware-specific quirks — like the exact timing of the ET4000 graphics card or the behavior of specific ISA bus peripherals — aren't perfectly replicated. But for the purpose of preserving a working DOS environment, it's more than sufficient.</p>
+
 </div>

retro/index.njk

@@ -45,8 +45,8 @@ sections:
         href: "/mini-arcade-handheld-roundup/"
   - heading: "DOS & PC"
     cards:
-      - title: "💻 The 486 DX2-66 Tower"
-        summary: "An original Colani-design 486 tower kept running alongside its MiSTer AO486 FPGA equivalent."
+      - title: "💻 The 486 DX2-66"
+        summary: "A complete DOS environment rebuilt 1:1 on MiSTer FPGA, down to the original AUTOEXEC.BAT."
         href: "/dos-486-tower/"
   - heading: "Overview"
     cards:
@@ -55,6 +55,6 @@ sections:
         href: "/retro-corner-snapshot/"
 
 ---
-<p class="site-intro">Hardware I've collected and kept running over the years. From Atari ST and Amiga to MiSTer FPGA and DOS towers.</p>
+<p class="site-intro">Hardware I've collected and kept running over the years. From Atari ST and Amiga to MiSTer FPGA and DOS environments.</p>
 
 {% include "card-grid.njk" %}

retro/retro-corner-snapshot/index.njk

@@ -18,5 +18,14 @@ parent: "/"
 <li><strong>The focus, unmistakably</strong> — Amiga and Atari ST are the heart of the collection; everything else (DOS, arcade, handhelds) exists to fill in the gaps around those two platforms.</li>
 </ul>
 
+<h2>The office setup in detail</h2>
+<p>The office houses the main retro computing workstation. The three Mega ST 4 machines each have a defined role: one runs GEM-based productivity software, one is set up for MIDI music production with a connected synthesizer, and one serves as the development machine for ST software. The Mega ST 2 is the backup and testing machine. The MiSTer FPGA handles Amiga and DOS emulation with near-perfect timing accuracy, while the MiST provides a dedicated Atari ST experience without the overhead of the MiSTer's larger feature set.</p>
+
+<h2>The living room setup</h2>
+<p>The Batocera box in the living room takes a completely different approach — it's not about hardware authenticity, it's about convenience. A compact PC boots directly into the Batocera frontend, providing a console-like experience for casual retro gaming on the TV. Controllers are wireless, the interface is controller-friendly, and the focus is on games that work well from a couch rather than demos or productivity software that needs a keyboard and mouse.</p>
+
+<h2>How it all connects</h2>
+<p>All machines share the same network infrastructure, with FTP access to the NAS for file transfers. Disk images and software archives are stored centrally and served to individual machines as needed. The MiSTer and MiST both use SD cards for storage, while the original hardware uses CompactFlash adapters or SCSI-to-IDE bridges depending on the machine. The Raspberry Pi 400 accesses the same NFS shares as the other Pis in the flat.</p>
+
 <p class="redacted-note">The honest status update: several open items remain — documenting the exact handheld models, and waiting on the A1200 Mini pre-order. Retro computing, it turns out, is never really "done."</p>
 </div>

retro/the-a1200/index.njk

@@ -18,6 +18,36 @@ parent: "/"
 <li><strong>Expected internals</strong> — likely an Allwinner ARM SoC running Amiberry underneath (following the pattern of the earlier A500 Mini), rather than genuine 68EC020 silicon.</li>
 </ul>
 
+<h2>Context: where this fits in the retro landscape</h2>
+<p>The A1200 sits in a growing market of mini-consoles and FPGA recreations.
+Unlike MiSTer FPGA, which aims for cycle-accurate hardware reproduction,
+the A1200 is a software emulation box — similar to the A500 Mini that
+Retro Games Ltd. released in 2022. The A500 Mini was well-received but
+had its quirks: limited game selection, no keyboard support, and an
+emulation layer that didn't quite match the original hardware in all
+cases. The A1200 appears to address some of these criticisms, particularly
+with the keyboard and expanded I/O.</p>
+
+<h2>How it compares to alternatives</h2>
+<p>For someone who wants to run Amiga software today, there are several
+options. A real A1200 with a compact flash adapter and a modern LCD
+monitor is the purist approach, but requires maintenance and debugging.
+MiSTer FPGA offers near-perfect hardware reproduction but costs
+significantly more. Amiberry on a Raspberry Pi is the budget option,
+with good compatibility but occasional timing issues. The A1200
+positions itself as a plug-and-play alternative — set it up in minutes,
+no configuration required, at the cost of some flexibility.</p>
+
+<h2>What this means for the Amiga community</h2>
+<p>If the A1200 ships on time and delivers on the promised feature set,
+it could become the default entry point for people curious about the
+Amiga. The original hardware is getting harder to find in good condition,
+and the capacitor-bomb motherboard issue means that even working units need
+recapping. A modern, reliable reproduction — even if it's software
+emulation — lowers the barrier significantly. The 25 pre-installed games
+give newcomers a curated starting point, and the USB sideloading support
+means the library can be expanded without hardware modifications.</p>
+
 <p class="redacted-note">Worth a heads-up if you're pre-ordering: not every regional shop went live on launch day, and lesser-known international retailers sometimes get product photos and details before the official site does. With a seven-month wait to delivery, there's no rush to jump on the very first listing you find.</p>
 </div>
 

shared/base.css

@@ -214,3 +214,30 @@ main { max-width: 1100px; margin: 0 auto; padding: 2rem; }
   color: #666;
   margin: 0 0 2rem;
 }
+
+.about-expanded {
+  margin-top: 3rem;
+  max-width: 800px;
+}
+.about-expanded h2 {
+  font-size: 1.1rem;
+  color: var(--accent);
+  margin: 2rem 0 0.75rem;
+  padding-bottom: 0.4rem;
+  border-bottom: 1px solid var(--card-border);
+}
+.about-expanded h2:first-child {
+  margin-top: 0;
+}
+.about-expanded p {
+  font-size: 0.95rem;
+  color: #444;
+  line-height: 1.7;
+  margin: 0 0 1rem;
+}
+.about-expanded a {
+  color: var(--accent);
+  text-decoration: underline;
+  text-underline-offset: 2px;
+}
+.about-expanded a:hover { color: var(--text); }

smarthome/air-quality/index.njk

@@ -0,0 +1,38 @@
+---
+title: "Air Quality Dashboard"
+section: "smarthome"
+parent: "/"
+description: "Real-time temperature and humidity monitoring across all rooms, powered by InfluxDB and Chart.js."
+layout: base.njk
+---
+<h1>Air Quality Dashboard</h1>
+<div class="detail-content">
+
+<p>A custom HTML5 dashboard that displays real-time temperature and humidity readings from sensors across the apartment. It consumes data from InfluxDB via the Flux query API and visualizes it with Chart.js, auto-refreshing every 30 seconds.</p>
+
+<h2>Architecture</h2>
+<p>The dashboard sits at the end of a sensor data pipeline that starts at physical devices scattered around the flat:</p>
+<ul>
+<li><strong>Sensors</strong> HomematicIP room sensors and ESP32 devices with DHT22 sensors publish temperature and humidity readings via MQTT.</li>
+<li><strong>MQTT broker</strong> Mosquitto receives the per-device topics and makes them available for subscription.</li>
+<li><strong>Write layer</strong> A small subscription service picks up the MQTT messages and writes them into InfluxDB 2.x, tagged by room, device, and measurement type.</li>
+<li><strong>InfluxDB</strong> Stores the time-series data in a <code>sensoren</code> bucket, organized by org <code>Heimnetzwerk</code>.</li>
+<li><strong>Dashboard</strong> A static HTML page queries InfluxDB via Flux every 30 seconds, rendering current values and 24-hour historical charts per room.</li>
+</ul>
+
+<h2>Rooms covered</h2>
+<p>The dashboard monitors 10 rooms across the apartment: server room, balcony, living room (desk and iMac areas), kitchen, bathroom, hallway, study, children's room, and bedroom. Each room shows current temperature and humidity, with optional pressure and light-level readings where sensors support it.</p>
+
+<h2>Dashboard features</h2>
+<ul>
+<li><strong>Current values grid</strong> at-a-glance temperature and humidity for every room.</li>
+<li><strong>Historical charts</strong> 24-hour temperature and humidity graphs per room with min/max stats.</li>
+<li><strong>Auto-refresh</strong> Data updates every 30 seconds without page reload.</li>
+<li><strong>Error handling</strong> Graceful fallback when InfluxDB is unreachable, with loading indicators during initial fetch.</li>
+<li><strong>Responsive design</strong> Works on phones, tablets, and desktop browsers.</li>
+</ul>
+
+<h2>Relationship to other dashboards</h2>
+<p>The air quality dashboard is a standalone page, separate from the main home dashboard and the Tasmota energy monitoring setup. It shares the same InfluxDB instance and MQTT infrastructure but queries different measurement types (temperature/humidity vs. power/energy). The home dashboard shows a summary of room temperatures alongside energy data, while this dashboard provides the detailed view with historical charts for climate monitoring specifically.</p>
+
+</div>

smarthome/balkonpi/index.njk

@@ -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>

smarthome/home-dashboard-controls/index.njk

@@ -29,14 +29,21 @@ parent: "/"
 <li><strong>Single sockets (SP112)</strong> — four individually switchable outlets covering hallway, kitchen, dryer and washing machine circuits, each also powering an associated LED matrix or small Pi.</li>
 <li><strong>Other plug families</strong> — additional Nous, Eightree (ESP32-based), Athom and IDS smart plugs cover spare capacity, living-room seating/desk outlets, storage room, kitchen appliances, and a few legacy TV/PC outlets (several currently marked defective).</li>
 </ul>
+<p>The plug collection has grown over time as different brands became available at different price points. Gosund P1 multi-socket strips handle areas with multiple devices, while the SP112 single sockets cover dedicated appliances. Eightree plugs are ESP32-based and flashable to Tasmota, while the Athom and IDS models round out the remaining circuits. A Tasmota RF Bridge extends the ecosystem to RF-only devices like the 3D printer plug in the study.</p>
 
-<h2>Special devices & status</h2>
+<h2>Special devices &amp; status</h2>
 <ul>
 <li><strong>Tasmota RF Bridge / Delock</strong> — bridges RF-only devices (like the home-office 3D printer plug) into the Tasmota/MQTT ecosystem.</li>
-<li><strong>LED Matrix restarts</strong> — one-click restart buttons for each room's LED matrix display, avoiding a manual power-cycle.</li>
-<li><strong>Healthchecks & version info</strong> — direct links into the Healthchecks dashboard and a version/status overview for the connected devices.</li>
+<li><strong>LED Matrix restarts</strong> — one-click restart buttons for each of the six room LED matrix displays (living room, study, bathroom, kitchen, hallway, Nepomuk room), avoiding a manual power-cycle.</li>
+<li><strong>Healthchecks &amp; version info</strong> — direct links into the Healthchecks dashboard and a version/status overview for the connected devices.</li>
 </ul>
 
+<h2>Calendar &amp; weather</h2>
+<p>The home dashboard also includes two additional views beyond the button controls: a calendar page showing the next 10 upcoming appointments (powered by the <a href="https://github.com/skoelle/calender_sync">Google Calendar Sync</a> service), and a weather page displaying hourly forecasts for the local area. Both are accessed from the same landing page as the button controls.</p>
+
+<h2>Music library</h2>
+<p>A Music Stretto instance running on the Synology provides access to the local MP3 library. It's reachable from the same home dashboard landing page and used for quick playback without needing to open a dedicated music app.</p>
+
 <h2>Network shortcuts</h2>
 <ul>
 <li><strong>Routers & mesh</strong> — quick links to the main Fritzbox and its mesh repeaters covering different floors and the kitchen/IoT band.</li>

smarthome/homematic-mqtt/index.njk

@@ -29,11 +29,39 @@ sensor state changes to MQTT.</p>
 <li>Grafana reads from InfluxDB for the temperature/humidity dashboards.</li>
 </ol>
 
+<h2>The Home Assistant automations</h2>
+<p>Each room has its own automation in Home Assistant that listens for
+state changes on the corresponding HomematicIP thermostat entity. When
+the temperature or humidity changes, the automation publishes the new
+values to MQTT topics like <code>homematic/livingroom/temperature</code>
+and <code>homematic/livingroom/humidity</code>. The automations are
+simple YAML configurations, not custom code, which makes them easy to
+maintain and debug.</p>
+
+<h2>The InfluxDB writer</h2>
+<p>A small .NET background service runs as a Docker container and
+subscribes to all <code>homematic/+/+</code> MQTT topics. When a
+message arrives, it parses the room name and measurement type from the
+topic, converts the value to a float, and writes it into InfluxDB with
+appropriate tags. The service handles connection drops and reconnection
+automatically, and logs all write operations for debugging.</p>
+
+<h2>Dashboard integration</h2>
+<p>Grafana queries InfluxDB using Flux to display real-time temperature
+and humidity charts for each room. The dashboards show current values,
+24-hour trends, and historical averages. This data is also used in the
+home dashboard to display room temperatures alongside other sensor data
+like air quality and power consumption.</p>
+
 <h2>Why this is worth documenting</h2>
 <ul>
 <li>No extra Docker container or unmaintained library dependency.</li>
 <li>Cloud-API changes are absorbed by Home Assistant's own maintainers, not by custom code.</li>
 <li>The MQTT bridge is just configuration (automations), not a service that needs its own uptime monitoring.</li>
+<li>The entire chain is observable: MQTT topics can be monitored with any MQTT client, InfluxDB has its own explorer, and Grafana dashboards show the data flow end-to-end.</li>
 </ul>
 
+<h2>Lessons learned</h2>
+<p>The original approach of running a dedicated exporter was more "architecturally pure" but fragile in practice. When the Python library stopped working, the entire sensor pipeline broke. The Home Assistant approach is more robust because it leverages a well-maintained integration and uses MQTT as a simple, well-understood transport layer. The lesson: for home automation, prefer integrations that are actively maintained over custom code that needs constant attention.</p>
+
 </div>

smarthome/index.njk

@@ -36,6 +36,10 @@ sections:
         summary: "ESP32 dashboard showing weather, calendar, and MVG departures."
         href: "https://github.com/skoelle/m5stack-dashboard"
         emoji: "🖥️"
+      - title: "Air quality dashboard"
+        summary: "Real-time temperature and humidity monitoring across all rooms with historical charts."
+        href: "/air-quality/"
+        emoji: "🌡️"
   - heading: "Personal services"
     cards:
       - title: "iCloud Contacts Sync"
@@ -64,11 +68,23 @@ sections:
         summary: "Remote 3D printer control and camera streaming."
         href: "/octoprint/"
         emoji: "🖨️"
-      - title: "TubeArchivist"
-        summary: "Self-hosted YouTube archiving running on the Synology."
+      - title: "YouTube archiving"
+        summary: "TubeArchivist and TubeSync for self-hosted YouTube downloading on the Synology."
         href: "/tubearchivist/"
         emoji: "📺"
 ---
 <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 and TubeSync 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>

smarthome/octoprint/index.njk

@@ -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>

smarthome/tasmota-energy/index.njk

@@ -10,7 +10,9 @@ layout: base.njk
 
 <p>Power monitoring across the flat runs on a mix of Tasmota-flashed smart
 plugs, tracking accumulated kWh per device and feeding daily usage
-figures into the home dashboard.</p>
+figures into the home dashboard. The setup uses 8 Tasmota-enabled devices
+covering kitchen appliances, office equipment, entertainment systems,
+and LED matrix displays.</p>
 
 <h2>What's metered</h2>
 <table>
@@ -35,11 +37,33 @@ well-documented community process. It occasionally fails on the first
 attempt due to a transient Wi-Fi handshake issue — retrying resolves it
 without any special handling.</p>
 
+<h2>How the data flows</h2>
+<p>Each Tasmota plug publishes its power readings to MQTT via the
+ Mosquitto broker running on the Docker host. A small subscription
+service picks up the per-device topics and writes the values into
+InfluxDB 2.x, tagged by device name, room, and measurement type
+(power, energy, voltage). The home dashboard then queries InfluxDB
+via Flux to display real-time and historical usage charts.</p>
+
 <h2>What this data is used for</h2>
 <ul>
 <li>Spotting appliances with unexpectedly high standby draw.</li>
 <li>Sanity-checking that "turned off" devices are actually drawing near-zero power.</li>
 <li>Feeding the home dashboard's live power figures alongside the climate sensors.</li>
+<li>Tracking long-term energy trends to identify efficiency improvements.</li>
+<li>Alerting when a device draws significantly more than its baseline (e.g., a failing appliance).</li>
 </ul>
 
+<h2>Air quality and climate data</h2>
+<p>The same InfluxDB instance also stores temperature and humidity readings from HomematicIP room sensors and ESP32 DHT22 devices. These feed the <a href="/air-quality/">air quality dashboard</a>, which visualizes 24-hour climate history across 10 rooms. The energy and climate data share the MQTT-to-InfluxDB pipeline but live in separate measurement categories, keeping power monitoring and environmental sensing cleanly separated.</p>
+
+<h2>Why Tasmota over alternatives</h2>
+<p>Tasmota was chosen over alternatives like ESPHome or Tuya firmware for
+several reasons. The local-only control means no cloud dependency — the
+plugs work even if the internet is down. The MQTT integration is mature
+and well-documented. The energy monitoring sensors are accurate enough
+for home use (typically within 5% of a dedicated energy meter). And the
+firmware supports a wide range of hardware, making it easy to find
+compatible plugs at reasonable prices.</p>
+
 </div>

smarthome/tubearchivist/index.njk

@@ -1,36 +1,43 @@
 ---
-title: "TubeArchivist"
+title: "YouTube Archiving: TubeArchivist & TubeSync"
 section: "smarthome"
 parent: "/"
-description: "Self-hosted YouTube archiving and media management running on the Synology NAS."
+description: "Self-hosted YouTube archiving and media management running on the Synology NAS, comparing TubeArchivist and TubeSync."
 layout: base.njk
 ---
-<h1>TubeArchivist</h1>
+<h1>YouTube Archiving: TubeArchivist &amp; TubeSync</h1>
 <div class="detail-content">
 
-<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>
+<p>Two self-hosted YouTube tools run on the Synology NAS via Docker Compose, each taking a different approach to the same goal: keeping offline copies of channels worth rewatching. TubeArchivist provides a full archive with search and metadata, while TubeSync focuses on automatic synchronization of playlists into a media server library.</p>
 
-<h2>Why this needed real troubleshooting</h2>
-<p>Running Elasticsearch on Synology's DSM kernel isn't fully
-straightforward: newer Elasticsearch releases require a Linux kernel
-feature (SECCOMP) that Synology's kernel doesn't compile in. The fix is
-version-pinning Elasticsearch to the last release that still works
-without it, rather than fighting the kernel.</p>
+<h2>TubeArchivist</h2>
+<p>TubeArchivist self-hosts a searchable archive of downloaded YouTube content (Elasticsearch, Redis, and the TubeArchivist app itself). It's used to archive channels worth rewatching, including tutorials, long-form content, and anything that might disappear behind copyright strikes or channel deletions.</p>
 
-<h2>Other Synology-specific quirks</h2>
+<h3>Synology-specific troubleshooting</h3>
+<p>Running Elasticsearch on Synology's DSM kernel isn't fully straightforward: newer Elasticsearch releases require a Linux kernel feature (SECCOMP) that Synology's kernel doesn't compile in. The fix is version-pinning Elasticsearch to the last release that still works 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>Synology's Container Manager doesn't always auto-join containers to the same Docker network even when they're defined in one Compose file, so 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>What's backed up</h2>
+<h3>Playlist detection problems</h3>
+<p>The main frustration with TubeArchivist is automatic playlist detection. New playlists added to subscribed channels are not always recognized by the app, meaning videos in those playlists get skipped during automatic downloads. The workaround is manually submitting individual videos or playlists through the TubeArchivist web interface using the built-in submission tool, which works but defeats the purpose of automated archiving. This issue remains unresolved.</p>
+
+<h2>TubeSync</h2>
+<p>TubeSync takes a simpler approach: it syncs YouTube playlists directly into a media server library (like Jellyfin or Plex) without the full archive UI. Everything is manual: playlists must be added by URL, and there's no automatic discovery of new content from subscribed channels. It's a pure download-and-organize tool rather than a searchable archive.</p>
+
+<h2>Current state</h2>
+<p>Both tools run in parallel on docker-host-nas, each with different strengths. TubeArchivist provides the better archive and search experience but has the playlist detection gap. TubeSync is more reliable for syncing specific playlists but requires manual curation. Neither has fully replaced the other yet, and the ideal solution of shutting one down hasn't been found.</p>
+
+<h2>How it fits into the backup strategy</h2>
+<p>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, as it only holds session data and can be safely rebuilt on restart.</p>
+
 <table>
 <tr><th>Data</th><th>Included in NAS backup?</th></tr>
 <tr><td>Downloaded media files</td><td>Yes, via the NAS's own backup volumes</td></tr>
 <tr><td>Elasticsearch metadata/index</td><td>Yes, via the NAS's own backup volumes</td></tr>
-<tr><td>Redis cache</td><td>No — safe to delete/rebuild, only holds session data</td></tr>
+<tr><td>Redis cache</td><td>No, safe to delete/rebuild, only holds session data</td></tr>
 </table>
 
 </div>

stefankoelle/index.njk

@@ -22,12 +22,22 @@ layout: stefankoelle.njk
 <div id="personalprojectscontent">
   <h2>Personal Projects</h2>
 
+  <h3>moonweb.org (since 2020)</h3>
+  <p>My personal corner on the internet, documenting the homelab, smart home setups, infrastructure experiments, retro hardware, and the code that ties it all together. Everything runs on a homelab that has been evolving since the mid-90s.</p>
+  <ul>
+    <li><b><a href="https://hub.moonweb.org">hub.moonweb.org</a></b>: Overview of all sites and projects.</li>
+    <li><b><a href="https://infra.moonweb.org">infra.moonweb.org</a></b>: Proxmox cluster, Synology NAS, Docker containers, networking, and backup strategies.</li>
+    <li><b><a href="https://smarthome.moonweb.org">smarthome.moonweb.org</a></b>: Home Assistant, MQTT sensors, AirPlay audio, energy monitoring, and ESP32 dashboards.</li>
+    <li><b><a href="https://code.moonweb.org">code.moonweb.org</a></b>: Curated catalog of public GitHub projects, sorted by topic.</li>
+    <li><b><a href="https://retro.moonweb.org">retro.moonweb.org</a></b>: Atari ST, Amiga, DOS, MiSTer FPGA, and the retro computing corner.</li>
+  </ul>
+
   <h3>Home Network Projects (2025-2026)</h3>
   <ul>
     <li><b>Docker Host (Proxmox PVE)</b><br>Virtualized Docker host with Debian 12.2 running containerized services including Portainer, Prometheus, Grafana, Gitea, monitoring exporters, and more. Full architecture documented on <a href="https://infra.moonweb.org/docker/">infra.moonweb.org</a>.</li>
     <li><b>InfluxDB Time-Series Integration</b><br>Deployed InfluxDB 2.x for sensor data collection from Tasmota smart plugs and HomematicIP thermostats, replacing older MySQL-based storage with modern time-series architecture.</li>
     <li><b>LED Matrix ESP32 InfluxDB Integration</b><br>Data persistence layer for <a href="/ledmatrix/">LED Matrix ESP32</a> sensor systems (DHT22 temperature/humidity) with InfluxDB 2.x backend. Automated collection at 60-second intervals for historical trend analysis.</li>
-    <li><b>Air Quality Dashboard</b><br>Dynamic HTML5 dashboard consuming real-time sensor data from InfluxDB via Flux query API. Displays temperature and humidity across all network locations, accessible via nginx reverse proxy.</li>
+    <li><b>Air Quality Dashboard</b><br>Dynamic HTML5 dashboard consuming real-time sensor data from InfluxDB via Flux query API. Displays temperature and humidity across all network locations, accessible via nginx reverse proxy. See also <a href="https://smarthome.moonweb.org/air-quality/">smarthome.moonweb.org</a>.</li>
     <li><b>Tasmota Energy Monitoring</b><br>Smart plug energy tracking with 8 Tasmota-enabled devices, integrating MQTT data collection and visualization. See also <a href="https://smarthome.moonweb.org/tasmota-energy/">smarthome.moonweb.org</a>.</li>
     <li><b>Network Hardware & Monitoring</b><br>Four Zyxel GS1200-8HP managed switches in the server room, living room, and study, plus a <a href="https://infra.moonweb.org/openwrt/">Multi-WAN OpenWrt router</a> for failover and VLAN segmentation. All switches feed into <a href="https://infra.moonweb.org/monitoring/">Prometheus monitoring</a> via SNMP exporters, and IoT devices are isolated in VLAN 189.</li>
   </ul>
@@ -35,7 +45,7 @@ layout: stefankoelle.njk
   <h3>Retro Computing (2022/2023)</h3>
   <ul>
     <li>MiSTer and MiST FPGA Systems for preservation (see also <a href="https://retro.moonweb.org/mist-mister-fpga/">retro.moonweb.org</a>).</li>
-    <li>DOS System, Amiga System, and Atari ST System with the environment from the early 90s.</li>
+    <li><a href="https://retro.moonweb.org/dos-486-tower/">DOS System</a>, <a href="https://retro.moonweb.org/the-a1200/">Amiga System</a>, and <a href="https://retro.moonweb.org/atari-mega-st-fleet/">Atari ST System</a> with the environment from the early 90s.</li>
   </ul>
 
   <h3>Upgrade of old <a href="https://retro.moonweb.org/atari-mega-st-fleet/">Atari Mega 4</a> (2021)</h3>
@@ -57,10 +67,10 @@ layout: stefankoelle.njk
 
   <h3>Various Docker Systems (since 2016)</h3>
   <ul>
-    <li><b>Monitoring:</b> Prometheus, Grafana, InfluxDB, cAdvisor, Node Exporter, SNMP exporters</li>
-    <li><b>Smart Home:</b> Mosquitto MQTT broker, Home Assistant</li>
+    <li><b>Monitoring:</b> <a href="https://infra.moonweb.org/monitoring/">Prometheus, Grafana, InfluxDB</a>, cAdvisor, Node Exporter, SNMP exporters</li>
+    <li><b>Smart Home:</b> Mosquitto MQTT broker, <a href="https://smarthome.moonweb.org/homematic-mqtt/">Home Assistant</a></li>
     <li><b>Infrastructure:</b> Portainer, Nginx Proxy Manager, Authelia (SSO), Watchtower, Healthchecks</li>
-    <li><b>Applications:</b> Gitea (GitHub mirror), Stirling PDF, TubeArchivist, TubeSync, SearXNG</li>
+    <li><b>Applications:</b> Gitea (GitHub mirror), <a href="https://infra.moonweb.org/docker/">Stirling PDF</a>, <a href="https://smarthome.moonweb.org/tubearchivist/">TubeArchivist</a>, <a href="https://smarthome.moonweb.org/tubearchivist/">TubeSync</a>, <a href="https://infra.moonweb.org/docker/">SearXNG</a></li>
   </ul>
 
   <h3>Walk-on Song (2019)</h3>
@@ -105,7 +115,7 @@ layout: stefankoelle.njk
 
   <h3>Mailbox/Fidonet (1994 - 2000)</h3>
   <ul>
-    <li>Operated a BBS and Fidonet Node (see also <a href="https://retro.moonweb.org/atari-networking-bbs/">Networking &amp; BBS</a> on retro.moonweb.org).</li>
+    <li>Operated a BBS and Fidonet Node (see also <a href="https://28k8.moonweb.org/bbs/fido/nodelist/">FidoNet Nodelist</a> on 28k8.moonweb.org).</li>
     <li>Managed a node in Augsburg with an uplink directly to the NC in Munich.</li>
     <li>Software was running on an OS/2 computer.</li>
     <li>Utilized 2x ISDN and 1x MODEM connections.</li>