Community-Master

Community-Master ist das WordPress-Plugin, das genau diese Seite hier befeuert — es verwaltet und rendert die Community-Projekte als durchsuchbare, sortierbare Kachelliste. Jedes Projekt wird als Card mit Logo, Beschreibung (voller Gutenberg-Editor), GitHub-Link, optionalem One-Line-Installer, Tag-Badges (Proxmox, WordPress) und Verknüpfungen zu Blogartikeln angezeigt. Deep-Links wie /community-master/<slug>/ führen zu einer Einzelansicht des jeweiligen Projekts — du landest genau auf dieser Seite, wenn du im Grid auf den Titel oder das Logo einer Kachel klickst.

Das Plugin ist vollständig über die WordPress REST API steuerbar: Projekte lassen sich programmatisch anlegen, bearbeiten und löschen, alle Meta-Felder (GitHub URL, Installer, Tags, Blogpost-IDs, Menu Order) sind les- und schreibbar. Authentifizierung erfolgt über WordPress Application Passwords — ideal für Automatisierung mit KI-Assistenten wie Claude Code, der sich auf diese Weise selbst neue Projekte anlegen und Inhalte pflegen kann.

Einzigartig: Das Plugin kann sich selbst aktualisieren. Ein Aufruf von POST /community-master/v1/self-update lädt das neueste GitHub-Release-ZIP, installiert es über den WordPress-Core-Plugin_Upgrader (Maintenance-Mode, Rollback bei Fehler, saubere Reaktivierung) und flushed die Rewrite-Rules — kein manueller ZIP-Upload mehr nötig, sobald das Plugin einmal auf dem Server liegt. Ergänzend meldet GET /community-master/v1/update-check installed vs. latest ohne Seiteneffekte. Beide Endpoints sind gegen Nicht-GitHub-URLs abgesichert und durch einen Transient-Lock gegen parallele Upgrades geschützt.

Falls mal etwas schief geht: POST /community-master/v1/restore/community-projects liest UpdraftPlus-DB-Backups aus wp-content/updraft/, parst sie und stellt verlorene community_project-Einträge samt Meta wieder her (idempotent — existierende Slugs werden übersprungen; unterstützt dry_run zur Vorschau). Und die uninstall.php löscht standardmäßig keine Daten — nur wenn du explizit community_master_delete_data_on_uninstall auf '1' setzt, werden Projekte beim Plugin-Delete hart entfernt. Das schützt vor versehentlichem Datenverlust, falls mal ein Duplicate-Plugin-Ordner aufgeräumt werden muss.

Installation

Einmal manuell aufsetzen — ab dann läuft jedes weitere Update automatisch per Self-Update-Endpoint, ohne dass du nochmal Dateien hochladen musst.

1. ZIP vom neuesten GitHub-Release herunterladen (Datei community-master-X.Y.Z.zip).
2. In WordPress-Admin: Plugins → Installieren → Plugin hochladen → ZIP auswählen → Jetzt installieren → Aktivieren.
3. Neue Seite mit Slug community-master anlegen und den Shortcode [community-master] einfügen.
4. Fertig. Ab jetzt reicht für Updates ein einziger REST-Call:

curl -u "user:app-password" -X POST \
  https://deine-seite.de/wp-json/community-master/v1/self-update

Voraussetzungen: WordPress 6.6+, PHP 8.2+. Alternative zum ZIP-Upload: git clone git@github.com:meintechblog/meintechblog-community-master.git community-master direkt in wp-content/plugins/ und im Admin aktivieren.

Technisch: pures PHP 8.2+ ohne externe Dependencies (keine ACF, kein Meta Box, kein Elementor-Widget — nur WordPress-Core-APIs). Vanilla-CSS mit CSS-Grid fürs Frontend, Vanilla-JS für die Instant-Suche und den Copy-to-Clipboard-Button.

MQTT-Master ist ein selbstgehostetes Dashboard für deinen Mosquitto-Broker und gleichzeitig eine Smart-Home-Bridge, die Nicht-MQTT-Systeme (Loxone, Venus OS …) über eine Plugin-Architektur in MQTT einbindet. Die Echtzeit-Oberfläche zeigt Live-Metriken (Nachrichten-Durchsatz, verbundene Clients, Uptime) mit Sparkline-Charts und einer IN/OUT-Activity-Bar, aktualisiert sich alle 2 Sekunden. Im Bereich Live Messages kannst du Topics abonnieren und Nachrichten in Echtzeit verfolgen, der Topic-Browser zeigt eine automatisch erkannte Baumstruktur samt Live-Werten — und aus jedem Topic heraus lässt sich direkt ein Input Binding anlegen.

Die Loxone Miniserver Bridge verbindet bidirektional per Token-Auth (Firmware v16.x), entdeckt alle Controls automatisch aus der LoxAPP3.json und bildet sie als menschenlesbare MQTT-Topics ab: loxone/Wohnzimmer/Licht/state, mit korrektem Umlaut-Handling (ä→ae, ö→oe, ü→ue, ß→ss). Parallel dazu existieren UUID-basierte Stable-Topics (loxone/by-uuid/{uuid}/cmd), die Control-Umbenennungen in Loxone Config überleben — ideal für Automatisierungen, die nicht bei jeder kleinen Strukturänderung brechen sollen. Mehrere Miniserver parallel sind kein Problem: jeder bekommt ein eigenes Topic-Prefix, eigene Elements-Seite, eigene Input Bindings.

Die Elements-Seite listet alle Controls mit Live-Werten, Copy-to-Clipboard auf jedem Topic, Suche/Filter nach Kategorie und Raum — plus Inline-Command-Testing: ein Dropdown pro Control-Typ zeigt alle verfügbaren Befehle (Switch On/Off/Pulse, Dimmer ±, LightControllerV2 Stimmung +/− und changeTo/{name}, Jalousie Up/Down/Stop, dazu Gate, Alarm, IRoomController, Ventilation) — ein Klick triggert sofort. Home-Assistant-Auto-Detection via MQTT Discovery ist eingebaut. Für LightControllerV2 gibt's Mood Mapping: ein festes Grid aller 35 Mood-Slots zum Befüllen, changeTo/Studio wird automatisch in changeTo/31 übersetzt, der aktive Mood-Name liegt unter loxone/{room}/{control}/mood/state.

Die MQTT-Bridge verbindet externe Broker (z.B. Venus OS) mit deinem lokalen — Plugin-Presets richten das beim Anlegen vorkonfiguriert ein (Topic-Filter N/#, Local-Prefix venus, Keepalive, Portal-ID-Detection). Smart-Republishing reduziert den Traffic drastisch: nur geänderte Werte werden weitergegeben, für Unveränderte läuft alle 30 Sekunden ein Keepalive — in Summe ca. 92% weniger Last als naives Forwarding. Input Bindings führen dich dann über einen 4-Schritte-Wizard durch das Mapping: externe MQTT-Daten (z.B. Venus-OS-Netzleistung oder PV-Inverter-Leistung) werden in Loxone-Controls eingespeist, mit Auto-Suggest-Transforms (W → kW) und konfigurierbarem Throttling.

Installation in einem Rutsch: entweder Proxmox-LXC-One-Shot (ein Befehl auf dem Proxmox-Host, der Container wird automatisch erstellt — anpassbar über CTID, CT_HOSTNAME, CT_MEMORY, CT_DISK) oder direkt auf Debian 12+ / Ubuntu 22.04+ als systemd-Service. Beide Wege bringen Node.js 20 LTS und Mosquitto (Port 1883 + WebSocket 9001) mit. Plugins starten beim Reboot automatisch wieder, Passwörter werden AES-256-CBC verschlüsselt abgelegt, Updates sind idempotent über denselben Befehl — deine Config bleibt erhalten.

PV-Inverter-Master bündelt mehrere PV-Komponenten zu einem einzigen virtuellen Fronius-Wechselrichter, den Venus OS (Victron Energy) automatisch erkennt, überwacht und regelt. Aktuell unterstützt: SolarEdge (Modbus TCP), OpenDTU für Hoymiles-Microinverter (REST) und Shelly der Gen1/2/3 (HTTP + mDNS). DVCC/ESS-Leistungsbegrenzung läuft aus Venus OS heraus auf das gesamte Setup — der Proxy verteilt den Sollwert geräteweise weiter, ohne manuelle Treiber und ohne Venus-OS-Patches.

Die unterstützten Geräte sprechen unterschiedliche Protokolle, die intern auf einheitliches SunSpec übersetzt werden: SolarEdge liefert volle Leistungssteuerung inkl. 3-Phasen-AC und DC-Werten, OpenDTU bringt DC-Kanäle je Microinverter plus Power-Limit, Shelly liefert Polling + Relais-Steuerung. Alle Werte werden aggregiert und als ein Fronius über Modbus TCP Port 502 ausgeliefert. Bei Shelly gibt's zusätzlich mDNS-Autodiscovery — alle kompatiblen Shellys im LAN erscheinen beim Hinzufügen direkt als Vorschlagsliste.

Das Live-Dashboard im Dark Theme zeigt pro Gerät eine Power-Gauge, AC-/DC-Tabellen, Verbindungsstatus und gerätespezifische Controls. Eine globale 60-Minuten-Sparkline samt Peak-Statistiken läuft in Echtzeit via WebSocket — keine Page-Refreshes, keine Polling-Schleifen im Browser. Ein integrierter Register-Viewer zeigt die rohen SunSpec-Register je Gerät mit dekodierten Werten, falls man mal bis auf Protokoll-Ebene runter will.

Neue Geräte fügst du über einen geführten Add-Device-Flow hinzu: Typ-Picker (SolarEdge / OpenDTU / Shelly), Auto-Probe der eingegebenen IP, und bei Shelly direkt mDNS-Discovery aller im LAN erreichbaren Geräte. Die Config-Seite trackt ungesaved Änderungen (dirty state) mit Save/Cancel, zeigt Live-Connection-Status und eine Throttle-Order — das Power-Waterfall bestimmt, welches Gerät bei einer Gesamtbegrenzung zuerst heruntergeregelt wird (z.B. erst Hoymiles, dann SolarEdge, oder umgekehrt — ganz wie es zu deiner Anlage passt).

Venus OS kommuniziert über zwei Kanäle mit dem Proxy: Modbus TCP für die Messwerte + Leistungssollwert (die Fronius-Simulation selbst) und MQTT auf Port 1883 für ESS-Settings, Netzleistung und Limiter-State. Letzteres setzt das „MQTT on LAN"-Feature ab Venus OS 3.7 voraus. Sobald Venus OS den Proxy findet, erscheint im Dashboard ein Auto-Detect-Banner mit Schritt-für-Schritt-Setup-Anleitung. Smart-Notifications als Toast-Alerts informieren über Power-Overrides, Faults, Temperaturwarnungen und Nachtmodus.

Die Installation läuft mit einem Befehl auf einem Debian-12+- oder Ubuntu-22.04+-System (LXC, VM oder Bare Metal — Python 3.12+ wird automatisch installiert). Der Installer legt Python-Venv, systemd-Service und Default-Config an. Updates laufen über denselben Befehl — der Installer erkennt eine bestehende Installation und überschreibt nichts, was du in /etc/pv-inverter-proxy/config.yaml angepasst hast. Unter der Haube: Python 3.12, pymodbus 3.8+, aiohttp, paho-mqtt, strukturiertes Logging über structlog, Frontend ist Vanilla JS + CSS3 ohne Build-Step und ohne externe Runtime-Dependencies.

Du hast Mobotix-Kameras mit MJPEG-Stream (S15, S16, M16 & Co.), eine Loxone Intercom oder einen Bambu Lab 3D-Drucker (H2C / H2D) — und willst das Ganze in UniFi Protect als "3rd-party camera" einbinden? IP-Cam-Master macht genau das. Ein Klick, und die Kamera (oder der Drucker) ist drin.

Die App scannt dein Netzwerk automatisch, erkennt Mobotix-Kameras, Loxone Intercoms und Bambu-Drucker (SSDP auf UDP 2021) und führt dich durch einen 5-Schritte-Wizard: Gerät auswählen, Zugangsdaten matchen, Stream testen, LXC-Container auf Proxmox erstellen, fertig. Im Container läuft go2rtc — bei Mobotix/Loxone mit VAAPI-Hardware-Transcoding (MJPEG → H.264), bei Bambu im reinen H.264-Passthrough, damit der fragile Live555-Server des Druckers nicht unter Transcode-Last gerät. Ein ONVIF-Server wrappt alles für UniFi Protect — erkannt und adoptiert wird automatisch. Kameras mit nativem ONVIF (z.B. Mobotix S16B) werden direkt ohne Container registriert.

Das Live-Dashboard zeigt dir für jede Kamera alles auf einen Blick: Snapshot-Preview, die komplette Service-Pipeline (Kamera → go2rtc → ONVIF → Protect) mit Statusanzeige, LXC-Ressourcen, Kamera-Details wie Modell, Firmware und Live-FPS, aktive Streams und die Verbindung zu UniFi Protect. Container lassen sich direkt aus der Oberfläche starten, stoppen, neu starten und löschen — plus ein automatischer Health-Check alle 5 Minuten, der meldet, falls go2rtc oder ONVIF-Server aussteigen.

Für Setups mit mehreren Kameras gibt es Batch-Onboarding per „Alle hinzufügen"-Button: alle erkannten Geräte werden nacheinander automatisch eingerichtet, inklusive Live-Progress und Snapshot-Thumbnails. Nach der ersten Kamera wird ein wiederverwendbares LXC-Template erstellt — alle weiteren Container klonen von dort (~30 Sekunden statt 3-5 Minuten pro Kamera). Credential-Presets speichern Standard-Logins einmal und matchen sie automatisch beim Onboarding. Storage- und Bridge-Dropdowns werden live aus der Proxmox-API geladen, inklusive freiem Speicherplatz.

Der Bambu H2C / H2D bekommt einen eigenen Pre-Flight-Check vor der Einrichtung: TCP-Port 322, RTSPS-Handshake und MQTT (Port 8883) werden separat getestet, damit du vier klar unterscheidbare Fehlerzustände siehst statt „geht halt nicht" — LAN-Mode aus, falscher Access-Code, Drucker nicht erreichbar, Live555 hängt. Optional im Adaptive Mode: go2rtc läuft nur während aktiver Drucke (via MQTT-print.gcode_state), schont den Drucker so ~22 Stunden am Tag — oder alternativ always_live für lückenlose Protect-Aufzeichnung und always_snapshot für totale Schonung.

Jede Kamera liefert einen HQ-Stream (volle Auflösung + Audio) und einen LQ-Stream (halbe Auflösung, niedrigere Bitrate) — Protect nutzt LQ für Timeline und Thumbnails, HQ für Live-View. Und weil das bei einem Homelab-Tool nicht fehlen darf: du kannst zwischen Session-basiertem Login (mit Setup-Wizard beim ersten Start) und einem YOLO-Modus wählen, der die Auth komplett abschaltet — ganz wie es zu deinem Netz passt.

Die Loxone-Intercom ist damit auch mit wenigen Klicks komplett in der App integriert und damit in UniFi Protect als ONVIF-fähige Kamera verfügbar.