Spotify hat Daily Drive am 17. März 2026 beerdigt. Keine automatisch aktualisierte Mischung aus Nachrichten, Podcasts und Musik mehr. Einfach weg. [1]
Also: Alternative suchen. Gefunden: dailydrive von patdeg – ein kleines Node.js‑Tool, das genau das macht, was Spotify uns weggenommen hat: Deine eigene Daily‑Drive‑Playlist bauen. Voll automatisiert. [1]
Was dailydrive macht
Das Projekt rekreiert im Prinzip das alte „Your Daily Drive“:
zieht die neuesten Episoden deiner Lieblings‑Podcasts
mischt Musik dazu (Top‑Tracks, Genres, Playlists – frei konfigurierbar)
ordnet alles nach einem Muster (z.B. 1 Podcast, 4 Songs, wiederholen)
überschreibt eine definierte Spotify‑Playlist mit diesem Mix
läuft automatisiert per cron oder systemd auf einem Linux‑Kistchen (Raspberry Pi, Server, altes Notebook – egal) [1]
Oder kurz: Du stellst einmal alles ein, ab dann baut eine kleine JavaScript‑App jeden Tag deine persönliche „Drive“-Playlist. [1]
Voraussetzungen
Bevor du loslegst, brauchst du:
Spotify Premium (Pflicht für Dev‑Apps seit Feb 2026, plus Limit von 5 Usern pro App) [1]
einen Spotify Developer Account
irgendeine Linux‑Kiste (Raspberry Pi reicht völlig)
minimalen Komfort mit Terminal / SSH
Installation – in kurz
Repo klonen
git clone https://github.com/patdeg/dailydrive.git
cd dailydrive
Code-Sprache:PHP(php)
Installer ausführen
chmod +x install.sh
./install.sh
Der Installer:
installiert Node.js (falls nötig)
zieht die Dependencies
legt eine config.yaml an (bzw. Vorlage) [1]
Spotify‑App anlegen
Damit das Tool deine Playlists anfassen darf, braucht es eine eigene Spotify‑App. [1]
Das Skript analysiert deine Top‑Tracks und baut passende Genre‑Tags für deine config.yaml. [1]
Stabilität & Technik‑Nerdkram
Unter der Haube passiert:
Zugriff auf die Spotify Web API über spotify-web-api-node
OAuth 2.0 Authorization Code Flow
Tokens werden automatisch aktualisiert und lokal gespeichert
Podcast‑Episoden: GET /v1/shows/{id}/episodes
Musik:
GET /v1/me/top/tracks
GET /v1/search für Genres
GET /v1/playlists/{id}/tracks
Playlist‑Update über PUT /v1/playlists/{id}/items (neuer Endpunkt seit den API‑Änderungen 2026) [1]
Damit das Ding dir nicht während des Hörens ständig die Playlist umsortiert, gibt es ein State‑Caching in state.json. Wenn sich keine neuen Podcast‑Episoden ergeben, wird das Update einfach übersprungen. [1]
Typische Fehler & schnelle Fixes
„Not authenticated!“ → npm run setup noch mal ausführen. [1]
config.yaml not found → cp config.example.yaml config.yaml und bearbeiten. [1]
Token abgelaufen → ebenfalls npm run setup. [1]
403 Forbidden beim Playlist‑Update → deine eigene Mail im Spotify‑Dev‑Dashboard unter „User Management“ eintragen. [1]
Playlist bleibt leer → npm test checken: liefern die Podcasts / Playlists überhaupt Inhalte? IDs prüfen. [1]
Was besser ist als das alte Spotify Daily Drive
Spotify hat dir früher „irgendwas“ gemischt. Jetzt bestimmst du:
welche Podcasts drin sind (und wie viele Episoden)
wo sie im Mix landen (News zuerst, Long‑Form später)
welche Musikquellen genutzt werden
wie das Pattern aussieht
wann die Playlist aktualisiert wird [1]
Du bist nicht mehr von einem Launenschalter im Spotify‑Backend abhängig. Wenn Spotify wieder eine Funktion killt – egal. Du baust dir die halt selber.
Fazit
Wenn du Daily Drive vermisst und keine Lust hast, jeden Tag manuell News‑Podcasts und Musik zusammenzuklicken:
dailydrive ist leichtgewichtig
schnell eingerichtet
komplett unter deiner Kontrolle
und läuft auf praktisch jeder Linux‑Kiste im Hintergrund [1]
Du hast dir das Ding installiert, es „läuft genial“ – exakt dafür ist das Projekt gebaut. Einmal sauber konfigurieren, dann einfach ins Auto steigen, Play drücken und die Maschine machen lassen.
Die OM-1 Macro Focus Stacking Pipeline ist jetzt als native macOS App verfügbar! Statt Terminal-Befehlen gibt’s jetzt eine schicke Web-Oberfläche mit Live-Preview, Echtzeit-Progress und One-Click-Installation.
Im letzten Artikel hab ich gezeigt, wie man mit Python-Scripts automatisch Focus-Stacks aus OM-1 RAW-Serien erstellt. Das funktionierte, war aber… sagen wir mal „entwicklerfreundlich“. 😅
Das Problem:
Terminal-Befehle eintippen
Python-Environment aufsetzen
Kein visuelles Feedback
Für Nicht-Nerds eher abschreckend
Die Lösung: v4.0 🚀
Was ist neu?
🎨 Moderne Web-Oberfläche
Statt schwarzem Terminal-Fenster gibt’s jetzt eine responsive Web-UI mit:
Thumbnail-Vorschau aller erkannten Serien
Interaktive Auswahl per Checkbox
Live-Progress mit Echtzeit-Logs
Statistiken (Zeit, Erfolgsrate, etc.)
Screenshot:(hier würde ein Screenshot der Web-UI hin)
📦 Native macOS App
Die Pipeline ist jetzt eine echte .app:
# Früher:
cd ~/Projects/stacking
source venv/bin/activate
python3 macro_stacking.py --watch /Volumes/SD-CARD
# Jetzt:# Doppelklick auf "OM-1 Stacking Pipeline.app" → fertig!Code-Sprache:PHP(php)
Installation:
DMG herunterladen
App nach /Applications ziehen
Doppelklick → Browser öffnet sich automatisch
⚡ Performance-Optimierungen
Smart Image Handling:
Nutzt OOC JPEGs wenn vorhanden (keine Konvertierung!)
Die OM-1 Stacking Pipeline v4 macht Focus-Stacking endlich zugänglich und schnell:
✅ Keine Terminal-Kenntnisse mehr nötig ✅ Visuelles Feedback in Echtzeit ✅ Deutlich schneller durch Smart Processing ✅ Bessere Qualität mit Helicon Focus ✅ Native macOS App statt Script-Sammlung
Von der SD-Karte zum fertigen Stack in unter 1 Minute! 🚀
Wie ich meinen Makro-Fotografie-Workflow mit Python, LibRaw und focus-stack vollständig automatisiert habe
TL;DR
SD-Karte einstecken, Script starten, fertig. Automatisches Focus-Stacking für Makro-Fotografie mit der OM-1: Das System erkennt Bildserien, konvertiert RAW-Files, stackt sie und gibt perfekt scharfe Makro-Aufnahmen aus. Alles Open Source, läuft auf macOS.
Makro-Fotografie hat ein fundamentales Problem: Schärfentiefe. Bei extremen Vergrößerungen liegt nur ein winziger Bereich im Fokus. Die Lösung? Focus-Stacking – mehrere Bilder mit unterschiedlichen Fokusebenen zu einem komplett scharfen Bild kombinieren.
Das manuelle Ritual
📸 Fotos machen (10-50 Bilder pro Motiv)
💾 SD-Karte in den Rechner
📁 Bilder sortieren (welche gehören zusammen?)
🔄 RAW-Files konvertieren (ORF → TIFF)
🔬 In Stacking-Software laden
⏳ Warten…
💾 Ergebnis speichern
🔁 Für jede Serie wiederholen
Das nervt. Besonders wenn man 5-10 Serien pro Session hat.
Die Vision: Komplette Automation
Was wäre, wenn das alles automatisch passiert?
SD-Karte einstecken
↓
Script starten
↓
☕ Kaffee trinken
↓
Fertige Bilder im Output-Ordner
Genau das habe ich gebaut.
Das Setup
Hardware
Kamera: OM System OM-1 (funktioniert mit allen ORF-Kameras)
Computer: Mac (Intel oder Apple Silicon)
SD-Kartenleser: Beliebig
Software-Stack
Tool
Zweck
Warum?
Python 3.x
Orchestrierung
Flexibel, gut dokumentiert
LibRaw
RAW-Konvertierung
Unterstützt OM-1 (dcraw ist zu alt!)
focus-stack
Stacking-Engine
Open Source, gute Makro-Qualität
exiftool
EXIF-Daten
Serien-Erkennung via Timestamp
PyYAML
Config-Parsing
Lesbare Konfiguration mit Kommentaren
Optional:
GPS-Logger (iPhone) für GPS-Tagging
Architektur: Wie funktioniert’s?
1. SD-Karten-Erkennung
Das Script durchsucht /Volumes/ nach gemounteten Volumes mit DCIM-Ordner:
dcraw/LibRaw hat Probleme beim direkten Lesen von SD-Karten:
USB-Latenz
Dateisystem-Quirks (exFAT)
Timeouts bei langsamen Karten
Lösung: Bilder erst nach /tmp kopieren (schnell, lokal, zuverlässig).
Mögliche Erweiterungen
TODO-Liste:
Parallele Verarbeitung (mehrere Serien gleichzeitig)
Hazel-Integration (automatisch bei SD-Karte einstecken)
Web-UI (Flask-Dashboard mit Live-Progress)
Qualitäts-Check (verwackelte Bilder aussortieren via Sharpness-Analyse)
Cloud-Backup (gestackte Bilder automatisch auf NAS/Cloud)
Helicon Focus Support (bessere Qualität, aber kommerziell)
Linux/Windows Support (aktuell nur macOS)
Batch-Reprocessing (alte Serien mit neuen Parametern neu stacken)
Alternative Ansätze
Warum nicht…
…Lightroom/Photoshop?
❌ Nicht automatisierbar
❌ Teuer (Abo-Modell: 12€/Monat)
❌ Closed Source
❌ Erfordert manuelle Interaktion
…Helicon Focus?
✅ Beste Qualität
❌ Kommerziell (~$200)
❌ CLI eingeschränkt
❌ Für Hobby-Workflow overkill
…Zerene Stacker?
✅ Auch sehr gut
❌ Teuer (~$300)
❌ Ähnliche CLI-Probleme
❌ Keine gute Automation
…shinestacker?
✅ Kann RAW direkt
✅ Open Source
❌ Nur Python-API (keine CLI)
❌ Komplizierter zu integrieren
…Alles manuell?
✅ Funktioniert
❌ Zeitverschwendung
❌ Fehleranfällig
❌ Nicht reproduzierbar
❌ Nervt nach der dritten Serie
Fazit
Mit diesem Setup ist Makro-Stacking endlich schmerzfrei:
✅ Keine manuelle Sortierung mehr ✅ Keine RAW-Konvertierung mehr ✅ Kein Klicken durch GUIs mehr ✅ Reproduzierbar und konsistent ✅ Open Source und kostenlos
Automatisches Backup-System für Paperless-NGX mit täglichen Backups, wöchentlicher Rotation und optionalem Offsite-Transfer. Alles läuft via Cron-Job und einem simplen Bash-Script.
Warum überhaupt Backups?
Paperless-NGX ist großartig – alle Dokumente digitalisiert, durchsuchbar und ordentlich organisiert. Aber was passiert, wenn die Festplatte den Geist aufgibt, ein Update schiefgeht oder man sich aus Versehen die Datenbank zerschießt? Genau: Game Over.
Deshalb habe ich mir ein Backup-Konzept gebaut, das automatisch läuft und mich nachts ruhig schlafen lässt.
Das Konzept
Die Anforderungen
Automatisch: Kein manuelles Eingreifen nötig
Vollständig: Datenbank, Medien und Konfiguration
Versioniert: Mehrere Backup-Generationen
Offsite-fähig: Optional auf externen Speicher (NAS, Cloud, etc.)
Ressourcenschonend: Läuft nachts, wenn eh nichts los ist
Die Backup-Strategie
Ich setze auf ein 3-2-1-Prinzip (oder zumindest so nah wie möglich dran):
3 Kopien der Daten (Produktiv + 2 Backups)
2 verschiedene Medien (lokale Festplatte + NAS/Cloud)
1 Offsite-Kopie (außerhalb des Servers)
Backup-Rotation
Täglich: Die letzten 7 Tage
Wöchentlich: Die letzten 4 Wochen
Optional: Monatliche Backups für längere Aufbewahrung
Das Backup-Script
Das Script macht folgendes:
Stoppt Paperless-Container (optional, für konsistente Backups)
Exportiert die PostgreSQL-Datenbank
Packt alles zusammen: DB-Dump, Media-Files, Config
Erstellt ein komprimiertes Archiv mit Timestamp
Startet Paperless wieder
Löscht alte Backups nach Rotation-Schema
Optional: Sync zu externem Speicher
#!/bin/bash################################################################################ Paperless-NGX Backup Script# Erstellt vollständige Backups inkl. Datenbank, Medien und Konfiguration################################################################################ Konfiguration
PAPERLESS_DIR="/opt/paperless-ngx"
BACKUP_DIR="/mnt/backups/paperless"
COMPOSE_FILE="$PAPERLESS_DIR/docker-compose.yml"
RETENTION_DAYS=7
RETENTION_WEEKS=4# Optional: Offsite Backup (NAS, rsync, rclone, etc.)
OFFSITE_ENABLED=false
OFFSITE_DEST="/mnt/nas/backups/paperless"# Timestamp für Backup
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
BACKUP_NAME="paperless_backup_$TIMESTAMP"
TEMP_DIR="/tmp/$BACKUP_NAME"# Logging
LOG_FILE="$BACKUP_DIR/backup.log"
log() {
echo"[$(date +'%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}
# Backup-Verzeichnis erstellen
mkdir -p "$BACKUP_DIR"
mkdir -p "$TEMP_DIR"
log "=== Paperless-NGX Backup gestartet ==="# 1. Container stoppen (optional - für konsistente Backups)
log "Stoppe Paperless-Container..."
cd "$PAPERLESS_DIR" || exit1
docker compose -f "$COMPOSE_FILE" stop webserver
# 2. Datenbank exportieren
log "Exportiere PostgreSQL-Datenbank..."
docker compose -f "$COMPOSE_FILE" exec -T db pg_dump -U paperless paperless > "$TEMP_DIR/database.sql"if [ $? -eq 0 ]; then
log "Datenbank-Export erfolgreich"else
log "FEHLER: Datenbank-Export fehlgeschlagen!"
docker compose -f "$COMPOSE_FILE" start webserver
exit1
fi
# 3. Media-Files kopieren
log "Kopiere Media-Files..."
cp -r "$PAPERLESS_DIR/media""$TEMP_DIR/"
cp -r "$PAPERLESS_DIR/data""$TEMP_DIR/"# 4. Konfiguration sichern
log "Sichere Konfiguration..."
cp "$PAPERLESS_DIR/docker-compose.yml""$TEMP_DIR/"
cp "$PAPERLESS_DIR/.env""$TEMP_DIR/"2>/dev/null || log "Keine .env Datei gefunden"# 5. Container wieder starten
log "Starte Paperless-Container..."
docker compose -f "$COMPOSE_FILE" start webserver
# 6. Backup komprimieren
log "Komprimiere Backup..."
cd /tmp || exit1
tar -czf "$BACKUP_DIR/$BACKUP_NAME.tar.gz""$BACKUP_NAME"if [ $? -eq 0 ]; then
log "Backup erfolgreich erstellt: $BACKUP_NAME.tar.gz"
BACKUP_SIZE=$(du -h "$BACKUP_DIR/$BACKUP_NAME.tar.gz" | cut -f1)
log "Backup-Größe: $BACKUP_SIZE"else
log "FEHLER: Backup-Komprimierung fehlgeschlagen!"exit1
fi
# Temp-Verzeichnis aufräumen
rm -rf "$TEMP_DIR"# 7. Alte Backups löschen (Rotation)
log "Lösche alte Backups..."# Täglich: Behalte letzte 7 Tage
find "$BACKUP_DIR" -name "paperless_backup_*.tar.gz" -type f -mtime +$RETENTION_DAYS -delete
# Optional: Wöchentliche Backups behalten# Hier könnte man zusätzliche Logik einbauen für wöchentliche/monatliche Backups
log "Alte Backups bereinigt"# 8. Optional: Offsite-Backupif [ "$OFFSITE_ENABLED" = true ]; then
log "Starte Offsite-Backup..."
mkdir -p "$OFFSITE_DEST"# Beispiel mit rsync (anpassen je nach Setup)
rsync -avz --delete "$BACKUP_DIR/""$OFFSITE_DEST/"# Alternativ mit rclone (z.B. für Cloud-Storage):# rclone sync "$BACKUP_DIR" "remote:paperless-backups"if [ $? -eq 0 ]; then
log "Offsite-Backup erfolgreich"else
log "WARNUNG: Offsite-Backup fehlgeschlagen!"
fi
fi
# Backup-Statistik
BACKUP_COUNT=$(ls -1"$BACKUP_DIR"/paperless_backup_*.tar.gz 2>/dev/null | wc -l)
log "Anzahl vorhandener Backups: $BACKUP_COUNT"
log "=== Backup abgeschlossen ==="# Optional: Benachrichtigung senden (z.B. via ntfy, gotify, email, etc.)# curl -d "Paperless Backup erfolgreich: $BACKUP_SIZE" ntfy.sh/mein-paperless-backupCode-Sprache:PHP(php)
Der Cron-Job
Um das Backup automatisch laufen zu lassen, richte ich einen Cron-Job ein:
Papier ist selten das eigentliche Problem. Das Problem ist das Wiederfinden.
Rechnungen. Verträge. Bescheide. Sitzungsunterlagen. Alles wird heute zwar digital abgelegt, aber die klassische Dateisuche bleibt mühsam. Man erinnert sich selten an Dateinamen. Man erinnert sich an Inhalte.
Genau hier setzt mein Projekt an. Ein persönliches AI Office.
Die Basis bildet Paperless ngx. Darauf läuft eine zusätzliche KI Ebene, die Dokumente automatisch analysiert, zusammenfasst, verschlagwortet und für semantische Suche vorbereitet. Alles läuft auf eigener Infrastruktur.
Ziel Dokumente nicht mehr suchen. Dokumente fragen.
Architektur
Das System besteht aus wenigen klar getrennten Komponenten.
Scanner oder Upload → Paperless ngx → Dokumentexport über API → KI Verarbeitung → Vektor Datenbank → RAG API → Fragen und Antworten
Zusammenfassungen automatische Tags semantische Suche Fragen über Dokumente
Das Ergebnis ist ein Dokumentenarchiv, das nicht nur speichert, sondern Inhalte versteht.
Paperless als Grundlage
Paperless ngx ist ein Dokumentenmanagementsystem für selbstgehostete Umgebungen. Dokumente werden automatisch importiert, per OCR erkannt und archiviert.
Ein typisches Docker Setup sieht zum Beispiel so aus.
Der erste KI Schritt ist die Erstellung eines semantischen Indexes.
Dabei werden Dokumente in kleinere Textabschnitte zerlegt und für jeden Abschnitt sogenannte Embeddings erzeugt. Diese numerischen Vektoren repräsentieren die Bedeutung des Textes.
scripts/index_documents.py
from openai import OpenAI
import chromadb
from scripts.export_documents import get_documents
from config.settings import *
client = OpenAI(api_key=OPENAI_API_KEY)
chroma = chromadb.PersistentClient(path=CHROMA_PATH)
collection = chroma.get_or_create_collection("documents")
def split_text(text, size=500):
words = text.split()
for i in range(0, len(words), size):
yield" ".join(words[i:i+size])
def index_document(doc):
text = doc["content"]
chunks = list(split_text(text))
for i, chunk in enumerate(chunks):
emb = client.embeddings.create(
model=EMBEDDING_MODEL,
input=chunk
)
collection.add(
ids=[f"{doc['id']}_{i}"],
documents=[chunk],
embeddings=[emb.data[0].embedding]
)
Code-Sprache:JavaScript(javascript)
Die erzeugten Vektoren werden in einer lokalen Vektor Datenbank gespeichert.
Ein einfacher Ordner genügt.
mkdir vector_db
Automatische Zusammenfassungen
Beim Import eines neuen Dokuments kann automatisch eine Kurzfassung erzeugt werden.
scripts/summarize.py
from openai import OpenAI
from config.settings import *
client = OpenAI(api_key=OPENAI_API_KEY)
def summarize(text):
prompt = f"""
Fasse dieses Dokument in drei Sätzen zusammen.
{text}
"""
r = client.chat.completions.create(
model=CHAT_MODEL,
messages=[{"role":"user","content":prompt}]
)
return r.choices[0].message.content
Code-Sprache:PHP(php)
Die Zusammenfassung kann später direkt im Dokument angezeigt werden.
Automatisches Tagging
Neben der Zusammenfassung werden auch Tags automatisch generiert.
scripts/auto_tag.py
from openai import OpenAI
from config.settings import *
client = OpenAI(api_key=OPENAI_API_KEY)
def generate_tags(text):
prompt = f"""
Analysiere das Dokument und gib maximal fünf Tags zurück.
Nur einzelne Wörter.
{text}
"""
r = client.chat.completions.create(
model=CHAT_MODEL,
messages=[{"role":"user","content":prompt}]
)
tags = r.choices[0].message.content
return [t.strip() for t in tags.split("\n") if t.strip()]
Code-Sprache:PHP(php)
Diese Tags können anschließend automatisch über die Paperless API im Dokument gespeichert werden.
Damit entsteht mit der Zeit ein sauber strukturiertes Archiv.
Dokumente über Fragen durchsuchen
Der interessanteste Teil ist die RAG API.
RAG steht für Retrieval Augmented Generation.
Zuerst werden passende Dokumentabschnitte gefunden. Dann erzeugt das Sprachmodell daraus eine Antwort.
Oder: Wie ich $10 bei Grok verbrannte und lernte, dass AI-Agents nichts für arme Homelabber sind
TL;DR
✅ OpenClaw installiert auf Proxmox CT
❌ $10 bei Grok in wenigen Stunden verbrannt
⚠️ Gemini Free Tier (1.500 req/Tag) reicht nicht für autonome Agents
💡 Fazit: Für Homelab zu teuer, besser On-Demand nutzen
Die Idee: Ein autonomer AI-Agent für mein Homelab
Ich betreibe ein zweistufiges Proxmox-Cluster mit 15+ Services – von Paperless-NGX über OpenHAB bis hin zu einem kompletten AI Office Stack. Als ich von OpenClaw hörte (einem Open-Source autonomen AI-Agent), dachte ich: „Perfekt! Das könnte meine Infrastruktur noch smarter machen!“
Die Vision:
Automatische Log-Analysen
Smart Home Automationen via Natural Language
Dokumenten-Zusammenfassungen aus Paperless
Proaktive System-Überwachung
Klingt cool, oder? Spoiler: Ist es auch – aber teuer.
Die Installation: Überraschend einfach
OpenClaw lässt sich mit einem One-Liner installieren:
Ein Task: "Check my emails and summarize"Spawnt:
├─ Subagent 1: Email abrufen
├─ Subagent 2: Inhalte analysieren
├─ Subagent 3: Zusammenfassung erstellen
└─ Subagent 4: Formatierung
= 4-5 API Calls statt 1Code-Sprache:JavaScript(javascript)
2. Lange Context History
OpenClaw behält ALLES im Context:
- Alle bisherigen Messages
- Agent Memory
- Workspace Files
- System State
→ 36k tokens pro Request
→ Schnell teuer bei vielen Requests
Ich fragte mich: Sollte OpenClaw auf meiner Synology DS916+ laufen statt auf pve2?
DS916+ Specs:
CPU: Celeron N3060 (2 Cores @ 1.6 GHz)
RAM: 8 GB
Storage: 16.8 TB (!)
Pro:
✅ Unbegrenzter Storage (vs. 157 GB auf pve2)
✅ Läuft eh 24/7 (keine Extra-Stromkosten)
✅ Native Backup-Integration
Contra:
❌ CPU 2x schwächer als pve2
❌ Weniger RAM (8 vs. 31 GB)
❌ HDD statt NVMe (10-50x langsamer)
Fazit: Hybrid-Ansatz ist optimal:
Runtime auf pve2 (schnelle CPU/RAM)
Workspace/Logs auf DS916+ (viel Storage)
Mein Fazit nach 24 Stunden
Was ich gelernt habe:
1. Autonome AI-Agents sind (noch) zu teuer für Homelab
Für $10-30/Monat könnte ich:
Einen VPS mieten
Mehr Storage kaufen
Meine Stromrechnung bezahlen
10 Monate Netflix haben
2. Token-Verbrauch wird unterschätzt
36k tokens/Request klingt abstrakt, aber:
Bei 100 Requests/Tag = 3.6M tokens
Bei Gemini: $1/Tag = $30/Monat
Bei Grok: $18/Tag = $540/Monat 💀
3. Free Tiers sind für Testing, nicht Production
Gemini Free (1.5k/Tag) reicht für:
✅ Manuelle Queries
✅ Gelegentliche Automationen
❌ 24/7 autonome Agents
4. OpenClaw ist cool, aber…
…nicht für Homelab-Budgets optimiert:
Keine granularen Cost-Controls
Keine Token-Budgets pro Agent
Subagents spawnen unkontrolliert
Context-Compaction zu konservativ
Was ich jetzt mache
Option A: On-Demand statt 24/7
Statt OpenClaw kontinuierlich laufen zu lassen:
# Nur starten wenn ich es brauche:
openclaw gateway
# Spezifische Tasks:
openclaw agent --message "Fasse Paperless-Dokumente zusammen"
openclaw agent --message "Analysiere OpenHAB Logs"# Dann wieder stoppen:
pkill -f openclaw
Code-Sprache:PHP(php)
Aktuell: Tendiere zu Option B – installiert lassen, aber nicht aktiv nutzen.
Empfehlungen für andere Homelabber
OpenClaw macht Sinn wenn:
✅ Du ein Business-Budget hast ($50-100/Monat OK) ✅ Du wirklich 24/7 Automationen brauchst ✅ Du bereit bist, Paid Tiers zu nutzen ✅ Du die Kosten monitoren und kontrollieren kannst
Besser für Homelab:
✅ Paperless-NGX + RAG (nur bezahlen wenn du fragst) ✅ OpenHAB Automationen (keine Cloud-Kosten) ✅ Cron-Jobs + Scripts (kostenlos, zuverlässig) ✅ Gemini Free für manuelle Queries (1.5k/Tag reicht)
Alternativen zu OpenClaw
Wenn du AI im Homelab willst, aber nicht $30/Monat ausgeben:
