Yang's Notes

A daily LLM-powered health check flagged that 8 out of 10 cameras had crash counts in the hundreds. The root cause turned out to be two baby monitor cameras, a go2rtc reconnect window, and a vaapi cascade failure — none of which were directly obvious. Here’s how we found it and fixed it. How the Issue Was Found # I’ve been building a daily home health agent — a scheduled script that queries all home services (Frigate, Home Assistant, Paperless, the arr stack) and passes the data to a local LLM for analysis. The idea: instead of manually checking dashboards, get a morning summary that flags anything unusual.

When running Claude Code inside WSL, it’s easy to miss when it’s waiting for your input — especially if you’ve switched to another window while it works. This post documents the notification system I set up: Windows toast notifications that fire when Claude stops and when it needs permission, with click-to-focus on the exact WezTerm pane. How It Works # Claude Code has a hooks system in ~/.claude/settings.json. Two events are useful here:

Replacing Frigate’s default SSD MobileNet detector with YOLOv9t (tiny) running on the Intel N97’s integrated GPU via OpenVINO. Covers model export, correct Frigate config, and a critical gotcha that causes 100% false positives if you get it wrong. Setup # Server: Intel N97 (Debian 13), 8 camera streams Frigate: 0.17, running in Docker Detector: OpenVINO GPU (/dev/dri/renderD128) Previous model: SSD MobileNet v2 (built-in, 300×300) New model: YOLOv9t ONNX (320×320, 8.3 MB) Why YOLOv9t? # The default SSD MobileNet v2 bundled with Frigate’s OpenVINO image is fast and lightweight, but accuracy suffers on partially occluded objects and objects at the edges of the frame. YOLOv9t (tiny) offers meaningfully better detection quality with a similar computational footprint — at 320×320 input and ~18ms inference on the N97 iGPU, it handles 8 concurrent camera streams comfortably.

Setting up Frigate NVR on a dedicated Debian server (Intel N97) to replace a traditional NVR. Covers Docker compose, go2rtc stream config, hardware acceleration, HA integration, push notifications, and zone-based alerting. Traffic between VLANs goes through the main router (UCG Ultra). Hardware & Context # Server: Intel N97 mini PC (debian.lan, 10.0.10.11), Debian 13 Cameras: 8 Reolink PoE cameras on camera VLAN (10.0.40.0/24), 2 Nanit monitors on IoT VLAN (10.0.20.0/24) Existing NVR: kept running for continuous recording; Frigate handles detection and event clips only Home Assistant: on IoT VLAN (10.0.20.10), MQTT broker already running Storage Design # Frigate recordings go to a dedicated NAS share — no local NVMe waste for surveillance video.

How to structure local lecture/course videos (without an official TMDB/TVDB entry) in Plex as a proper TV Show with seasons, episode titles, and custom descriptions set via the Plex API. The example here is Jonathan Biss’s Exploring Beethoven’s Piano Sonatas — a 5-part Coursera course from the Curtis Institute of Music, stored on a Synology NAS. The Problem # Plex’s default scrapers rely on TMDB or TVDB. Local lecture videos with no database entry either show up as a mess of unmatched files, or get incorrectly matched to something unrelated.

This post is a complete runbook for integrating AI-powered auto-tagging and classification into paperless-ngx using paperless-ai and a locally-running Ollama instance. The setup uses a local LLM to read document text and automatically populate metadata fields — title, document type, tags, correspondent, date, and custom fields. Hardware and Architecture # NAS (Synology DS1621+, 10.0.10.10): runs paperless-ngx on port 5656 Desktop PC: Windows with WSL2, Docker Desktop, RTX 4090 Goal: AI auto-tagging/classification using a local LLM, zero cloud dependency The key architecture decision is a pull model: paperless-ai runs in WSL2 Docker, polls the paperless-ngx API for documents tagged ai-pending, processes them with Ollama, and writes metadata back. This is the correct approach for a desktop that is not on 24/7 — the NAS holds the queue and the desktop drains it when available.

Runbook and design journal for migrating ~400 personal documents from a folder-based Google Drive system into Paperless-ngx on a Synology NAS. Covers taxonomy design, bulk import from Google Takeout, ML classifier setup, and ongoing intake workflow. Problem Statement # For years my “document management” was a manually maintained folder tree on Google Drive: 1 2 3 4 5 6 7 8 9 10 10 - 文书材料/ 10 - 证件材料/身份证件/ 30 - 移民文档/ 30 - Tax Filing/ 40 - Finance/ 50 - 车辆注册/ 60 - 住房买房/ 80 - Medical/ 20 - 家装住房信息/ 80 - 旅行计划/ This worked well enough for filing but poorly for retrieval. Finding “what insurance forms did I have in 2022?” meant navigating six folders and guessing what I named things. Paperless-ngx offers full-text search, OCR, and an ML classifier that learns from your own labeling — a meaningfully better system for a document archive that spans immigration paperwork, tax filings, mortgage docs, and medical records across 10+ years.

Runbook for setting up AirPrint on a Synology NAS so iOS/macOS devices can print to a USB or network printer over the local network. Uses a Docker CUPS container and Synology’s built-in avahi (mDNS) daemon for service discovery. Architecture # 1 2 3 4 5 6 7 8 9 10 11 iPhone │ mDNS discovery (_ipp._tcp) ▼ Synology avahi-daemon (eth4, port 5353) │ reads service files from /etc/avahi/services/ │ CUPS Docker container (host network, port 631) │ generates /etc/avahi/services/AirPrint-*.service │ proxies print jobs to printer ▼ Printer (e.g. socket://10.0.20.50:9100) Key design decisions:

Personal runbook for migrating a family photo library from Synology Photos to a self-hosted Immich instance. Covers bulk upload, Google Takeout import, and album reconstruction via the Synology PostgreSQL database. Setup # Source: Synology NAS running Synology Photos (multiple users) Destination: Immich self-hosted on the same NAS Upload tool: immich-go v0.31+ Client: WSL2 on Windows, SSH access to NAS Album script: custom Python (migrate_albums.py) using Immich REST API Phase 1: Photo Uploads # Strategy # Two sources per user:

Four Month Sleep Regression # New sleep cycle with 5 different stages REM: Dreaming sleep Stage 1: very light/drowsy sleep Stage 2: Light sleep Stage 3/4: Deep restorative sleep Light sleep almost every hour or two throughout the night. They need to learn how to go back to sleep after the light/wake stage. The 7-step guide Fill the tank Check the engine Set the cruise control Top off the tank Hit the brakes Plan your rest stops Unload the baggage 1. Fill the tank # Maintaining adequate feedings during the day.