content imprive

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>

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主板 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/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/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,30 @@ 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>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>