WHIP Hub: Das intelligente Rückgrat des Smart Homes

Die Brücke zwischen Welten

In unserem Artikel über WHIP Nodes haben wir die "Nervenzellen" des WHIP-Systems vorgestellt - kleine, spezialisierte Mikrocontroller, die Sensoren und Aktoren in Echtzeit steuern und untereinander kommunizieren. Doch wie kommunizieren diese Nodes mit der Außenwelt? Wie werden ihre Daten gesammelt, analysiert und mit anderen Systemen verknüpft?

Die Antwort: WHIP Hubs.

Ein WHIP Hub ist ein Raspberry Pi-basierter Minicomputer, der als intelligente Middleware zwischen den hardwarenahen Nodes und dem übergeordneten Server fungiert. Er übersetzt zwischen der Echtzeitwelt der CAN-Bus-Kommunikation und der vernetzten Welt des Internets.

Dabei gilt ein fundamentales Designprinzip: Höhere Intelligenz ist immer ein Zusatz, nie eine Voraussetzung. Die Basisebene - Nodes, die Sensoren auslesen und Aktoren steuern - funktioniert völlig autonom. Der Hub fügt Komfort, Analyse und Vernetzung hinzu, ist aber für den Grundbetrieb nicht erforderlich.

Hardware-Fundament

Basisplattform

Der aktuelle Standard für WHIP Hubs ist ein Raspberry Pi 4B mit 8 GB RAM. Für anspruchsvollere Aufgaben wie Multiroom-Audio oder lokale KI-Verarbeitung setzen wir auch den Raspberry Pi 5 mit 16 GB RAM ein.

Die kompakte Bauform mit passiver Kühlung (wir verwenden Geekworm-Kühlkörper für den Pi 4 und EDATEC-Gehäuse für den Pi 5) ermöglicht den Einbau in Schaltschränke oder dezente Platzierung im Wohnbereich. Ein Hub verbraucht typisch 5-10 Watt - weniger als eine LED-Lampe.

Warum Raspberry Pi?

Die Wahl des Raspberry Pi als Hub-Plattform ist eine wirtschaftliche Entscheidung. Für Aufgaben, die TCP/IP-Netzwerke, komplexe Protokollstacks oder mehrere Gigabyte Arbeitsspeicher erfordern, ist ein vollwertiger Linux-Computer die bessere Wahl:

Der Raspberry Pi bringt ein komplettes Ökosystem mit: Python, Perl, Node.js, Docker, Datenbanken - was immer Sie brauchen. Die Entwicklung ist schneller, die Fehlersuche einfacher, und es gibt eine riesige Community mit Lösungen für fast jedes Problem.

Für zeitkritische Aufgaben im Mikrosekundenbereich sind STM32-Nodes die richtige Wahl. Für alles andere ist der Pi nicht nur ausreichend, sondern überlegen.

Erweiterungen durch HATs

Die eigentliche Magie entsteht durch spezialisierte Erweiterungsplatinen (HATs - Hardware Attached on Top):

Waveshare Dual-CAN HAT

Das Herzstück der Node-Kommunikation. Dieser HAT bietet zwei galvanisch getrennte CAN-Bus-Kanäle mit je 120Ω Abschlusswiderständen (per Jumper schaltbar). Die technischen Daten:

• 2 unabhängige CAN-Kanäle (can0, can1)
• 1 Mbit/s Übertragungsrate
• MCP2515 CAN-Controller mit SPI-Anbindung
• Galvanische Trennung für Störsicherheit
• Je Kanal bis zu 20m Buslänge, 30 Teilnehmer

Ein einzelner Hub kann somit bis zu 60 WHIP Nodes über eine Gesamtdistanz von 40 Metern verwalten. Die flexible Topologie erlaubt verschiedene Konfigurationen:

Hub am Ende:           Hub in der Mitte:

|---20m---Hub          |--10m--Hub--10m--|
|---20m---|            |--10m--|  |--10m--|

ATX LED DALI HAT

Für professionelle Lichtsteuerung nach dem DALI-Standard (Digital Addressable Lighting Interface). Ein DALI-Bus kann bis zu 64 Teilnehmer adressieren, mit einem 4-Kanal-HAT erreichen wir 256 individuell steuerbare Leuchten.

Wichtig: DALI ist ein eigenständiges System. Die Leuchten funktionieren auch ohne Hub - der Hub fügt lediglich intelligente Steuerungsfunktionen hinzu (dazu später mehr).

Waveshare 8-Relay HAT

Acht potentialfreie Schaltausgänge für direkte Steuerungsaufgaben. Jedes Relais kann bis zu 5A bei 250V AC oder 30V DC schalten. Typische Anwendungen:

• Bewässerungsventile
• Garagentore
• Heizkreisverteiler
• Pumpen und Lüfter

HiFiBerry ADC8x / DAC8x (nur Pi 5)

Für Multiroom-Audio-Anwendungen: 8-Kanal Audio-Ein- oder Ausgang in Studioqualität. Der Pi 5 hat genug Rechenleistung für Echtzeit-Audioverarbeitung, Raumkorrektur und Streaming.

Die CAN-Bus-Brücke

Das WHIP CAN-Protokoll

WHIP Nodes kommunizieren über CAN-Bus mit einem eigenen Protokoll. Die 29-Bit Extended CAN-IDs werden wie folgt genutzt:

Bit [28:19]  Reserved (10 Bit)
Bit [18:7]   Kommando (12 Bit) = Modul (8 Bit) + Subkommando (4 Bit)
Bit [6:0]    Node-ID (7 Bit)

Diese Struktur ermöglicht:

• 256 Module (Sensortypen, Aktortypen, Systemfunktionen)
• 16 Subkommandos pro Modul (Abfragen, Setzen, Konfigurieren...)
• 128 Nodes pro Bus (theoretisch, praktisch ~30 wegen elektrischer Limits)

Die 8 Byte Nutzdaten pro CAN-Frame enthalten die eigentlichen Parameter - Messwerte, Sollwerte, Konfigurationseinstellungen. Für größere Datenmengen existiert ein Multi-Frame-Protokoll.

Die Identifikationszeremonie

Beim Start führt der Hub eine "Identifikationszeremonie" durch:

1. Broadcast "Alle melden!" - Der Hub sendet einen Aufruf an alle Nodes
2. Nodes antworten - Jeder aktive Node meldet seine ID (abgeleitet aus der eindeutigen Hardware-UUID des STM32)
3. Individuelle Abfrage - Der Hub fragt jeden gemeldeten Node nach seinen Fähigkeiten
4. Teilnehmerliste verteilen - Der Hub sendet die vollständige Liste aller Nodes an alle Teilnehmer

Diese Zeremonie wird beim Hub-Start durchgeführt und wiederholt, wenn Nodes hinzugefügt oder entfernt werden. Die Nodes speichern die Teilnehmerliste - entweder im internen Flash des STM32 oder auf externem FRAM/EEPROM.

Warum speichern Nodes die Liste ihrer Peers? Wegen GANGLION - der Fähigkeit der Nodes, auch ohne Hub untereinander zu kommunizieren (ausführlich beschrieben im Artikel über WHIP Nodes).

Der Hub lädt GANGLION-Skripte auf die Nodes hoch und fügt höhere Intelligenz hinzu: Komplexere Logik, Zeitpläne, Wetterabhängigkeit, Benachrichtigungen. Aber er ist nicht notwendig für den Grundbetrieb.

Protokoll-Brücken: Die Sprachen der Haustechnik

Moderne Haustechnik spricht viele Protokolle. WHIP Hubs übersetzen zwischen diesen Welten.

Modbus: Profilbasierte Geräteintegration

Modbus ist das Esperanto der Industrieautomation - ein Protokoll aus den 1970ern, das immer noch in praktisch jedem professionellen Gerät implementiert ist. Der Hub beherrscht beide Varianten:

• Modbus TCP - Über Ethernet, für netzwerkfähige Geräte
• Modbus RTU - Über serielle Schnittstelle (RS-485), für ältere Geräte

Die WHIP-Implementierung unterstützt 17 der 21 Modbus-Funktionscodes und wurde mit über 800 Tests validiert.

Das Besondere: Es gibt keinen hart kodierten Support für bestimmte Hersteller. Stattdessen verwendet WHIP ein profilbasiertes System.

Das Profil-Konzept

Jedes Modbus-Gerät wird durch eine YAML-Datei beschrieben - sein "Profil". Diese Profile definieren:

• Welche Register existieren
• Welchen Datentyp sie haben (uint16, int32, float32...)
• Wie die Rohwerte zu interpretieren sind (Skalierung, Einheiten)
• In welchen Intervallen sie abgefragt werden sollen

Die generische WhipHub::Model::Device::Modbus-Klasse interpretiert diese Profile zur Laufzeit. Sie weiß nichts über Victron, nichts über Lüftungsanlagen, nichts über Batteriemanagementsysteme - sie liest YAML und spricht Modbus.

# Beispiel: vendor/victron/multiplus_ii.yaml
modbus:
  type: tcp
  default_port: 502
  registers:
    ac_input_voltage:
      address: 3
      type: uint16
      scale: 0.1
      unit: V
    ac_input_power:
      address: 12
      type: int16
      unit: W
    battery_soc:
      address: 843
      type: uint16
      unit: "%"

Vorteile des profilbasierten Ansatzes

1. Kein Programmieren für neue Geräte
Sie haben ein neues Modbus-Gerät? Erstellen Sie eine YAML-Datei mit der Register-Map aus dem Datenblatt. Fertig. Keine Perl-Klasse, keine Kompilierung, kein Code-Review.

2. Sofortige Aktivierung
Profile werden zur Laufzeit geladen. Änderungen sind nach einem Konfigurations-Reload wirksam - ohne Neustart des Systems.

3. OEM-Geräte trivial handhaben
Derselbe Wechselrichter wird unter fünf verschiedenen Markennamen verkauft? Eine Zeile pro Alias:

# vendor/noname_solar/hybrid_5000.yaml
isa: vendor/victron/multiplus_ii   # Dasselbe Gerät, anderer Name

4. Community-Beiträge
Profile sind einfacher zu erstellen als Code. Ein Endanwender kann sein Gerät selbst einbinden und das Profil mit anderen teilen.

Existierende Geräteprofile

Die mitgelieferte Profilbibliothek umfasst unter anderem:

Diese Liste ist nicht abschließend - sie zeigt nur, welche Profile bereits existieren. Das System ist für Geräte konzipiert, von denen wir heute noch nichts wissen.

DALI: Licht mit Intelligenz

DALI (Digital Addressable Lighting Interface) ist der Standard für professionelle Lichtsteuerung. Ein zweiadriger Bus, über den bis zu 64 Leuchten individuell angesteuert werden.

Wichtig zu verstehen: DALI-Leuchten funktionieren eigenständig. Jede Leuchte hat ihre eigene Adresse und reagiert direkt auf DALI-Befehle. Der Hub ist für den Grundbetrieb nicht erforderlich.

Was der Hub hinzufügt, ist höhere Intelligenz:

• Anwesenheitssimulation - Während Urlaub oder Abwesenheit schaltet der Hub Lichter nach realistischen Mustern ein und aus, um Anwesenheit vorzutäuschen
• Nutzungsprotokollierung - Welche Lichter brennen wie lange? Wo wird Energie verschwendet?
• Dashboard-Integration - Übersicht aller Leuchten, Fernsteuerung über App
• Vergesslichkeits-Assistent - Benachrichtigung wenn Lichter unnötig brennen, Möglichkeit zum Remote-Ausschalten
• Szenensteuerung - Komplexe Lichtstimmungen mit einem Befehl
• Zeitpläne - Automatisches Dimmen zur Schlafenszeit, Aufwachlicht am Morgen

In unserer Flaggschiff-Installation gehen wir noch weiter: Dort sind die Leuchten DC-basiert und direkt an den Batteriespeicher angeschlossen. Selbst bei komplettem Netzausfall funktioniert die Beleuchtung - aber das ist Material für eine eigene Fallstudie.

MQTT: Die Lingua Franca des IoT

MQTT (Message Queuing Telemetry Transport) ist das Standardprotokoll für IoT-Kommunikation. Der Hub kann sowohl als MQTT-Client als auch als Broker fungieren.

Typische Integrationen:

• Home Assistant - Der Hub publisht Sensordaten, Home Assistant reagiert darauf
• Node-RED - Visuelle Programmierung von Automatisierungsflüssen
• InfluxDB + Grafana - Langzeit-Datenerfassung und Visualisierung
• Eigene Anwendungen - Jede Software, die MQTT spricht

SNMP: Netzwerküberwachung

Simple Network Management Protocol - der Standard für die Überwachung von Netzwerkgeräten. Der Hub kann:

• Router und Switches überwachen (Bandbreite, Fehler, Temperatur)
• USV-Status abfragen (Batterieladung, Last, Autonomiezeit)
• Drucker und andere Netzwerkgeräte einbinden

Die Kanal-Architektur: Das Tor zur Welt

Philosophie: Generisch für das Unvorhergesehene

WHIP wurde mit einer besonderen Philosophie entwickelt: Das System soll Aufgaben erfüllen können, die wir als Entwickler nie vorhergesehen haben.

Ein Smart Home ist kein isoliertes System. Es existiert in einer vernetzten Welt voller Dienste, APIs und Plattformen. Die "Kanal-Architektur" des Hubs ermöglicht die Integration mit über 30 externen Diensten - und die Liste wächst.

Übersicht der verfügbaren Kanäle

Künstliche Intelligenz

• Anthropic Claude - Für natürlichsprachliche Interfaces und intelligente Auswertungen
• Ollama - Lokale LLM-Modelle ohne Cloud-Abhängigkeit
• OpenWebUI - Webinterface für lokale KI

Cloud-Plattformen

• AWS - Amazon Web Services für Skalierung und Backup
• Azure - Microsoft Cloud Services

Kommunikation & Social Media

• Discord - Benachrichtigungen und Steuerung über Chat
• X/Twitter - Status-Updates posten (ja, wirklich!)
• Reddit - Automatisierte Posts
• IRC - Klassisches Chat-Protokoll
• Gmail - E-Mail-Benachrichtigungen

Heimnetzwerk

• FritzBox - Anwesenheitserkennung über WLAN-Geräte, Anrufprotokoll
• UniFi - Netzwerküberwachung für Ubiquiti-Infrastruktur
• OpenMediaVault - NAS-Überwachung

Energie & Solar

• Victron VRM - Cloud-Anbindung für Victron-Systeme
• PVGIS - Solarertragsprognose basierend auf Wetterdaten

Medien & Überwachung

• Kodi - Mediacenter-Steuerung
• ZoneMinder - Videoüberwachung

Speicher & Datenbanken

• Nextcloud - Dateisynchronisation und Kalender
• ownCloud - Alternative Cloud-Speicherlösung
• InfluxDB - Zeitreihendatenbank für Sensordaten

Infrastruktur

• Proxmox - Virtualisierungsplattform überwachen
• Teltonika - Mobilfunk-Router (LTE/5G Backup)

Kryptowährungen

• Bitcoin/Altcoins - Wallet-Überwachung, Preisabfragen

Entwicklung & Dokumentation

• GitLab - CI/CD-Integration, Issue-Tracking
• MediaWiki - Automatische Dokumentation
• TicketSystem - Support-Workflows

Beispiele für Kanal-Nutzung

Die Kanäle ermöglichen Szenarien, die auf den ersten Blick absurd erscheinen - aber für irgendjemanden genau das Richtige sind:

"Poste meinen Solarertrag auf Twitter"

trigger: daily_at_sunset
action:
  channel: x
  message: "Heute erzeugt: {{ pv_daily_yield }} kWh ☀️"

"Benachrichtige mich auf Discord wenn die Waschmaschine fertig ist"

trigger: power_drop
  device: waschmaschine
  below: 5W
  for: 2min
action:
  channel: discord
  message: "@hier Wäsche ist fertig! 🧺"

"Schalte das Licht ein wenn mein Handy ins WLAN kommt"

trigger: fritzbox_device_connected
  mac: "AA:BB:CC:DD:EE:FF"
action:
  dali: flur_decke
  brightness: 80%

"Speichere alle Sensordaten in InfluxDB für Grafana-Dashboards"

trigger: sensor_update
  interval: 60s
action:
  channel: influxdb
  measurement: "{{ sensor.type }}"
  tags:
    location: "{{ sensor.room }}"
  fields:
    value: "{{ sensor.value }}"

Software-Architektur

Mojolicious: Das Fundament

Die Hub-Software basiert auf dem Mojolicious Web-Framework:

Event-driven Architecture
Mojolicious nutzt eine ereignisgesteuerte Architektur mit non-blocking I/O. Das bedeutet: Ein einzelner Prozess kann tausende gleichzeitige Verbindungen verwalten, ohne für jede einen eigenen Thread zu benötigen.

Eingebauter WebSocket-Support
Echtzeit-Updates ohne Polling. Die Web-Oberfläche zeigt Sensorwerte in dem Moment an, in dem sie sich ändern.

Vollständige REST-API
Jede Funktion des Hubs ist über HTTP-Endpunkte erreichbar:

GET  /modbus/devices              - Liste aller Modbus-Geräte
GET  /modbus/devices/{id}/data    - Aktuelle Daten eines Geräts
POST /modbus/devices/{id}/write   - Wert schreiben
GET  /modbus/health               - Systemstatus

OpenAPI/Swagger-Dokumentation
Die API dokumentiert sich selbst. Unter /api/v1 finden Sie eine interaktive Swagger-Oberfläche zum Testen aller Endpunkte.

Datengetriebene Philosophie

WHIP folgt einem strikt datengetriebenen Ansatz: Das Verhalten wird durch Konfigurationsdateien bestimmt, nicht durch Programmcode.

Ein neues Modbus-Gerät einbinden? Keine neue Perl-Klasse schreiben, sondern eine YAML-Datei anlegen. Die generische WhipHub::Model::Device::Modbus-Klasse interpretiert diese Konfiguration zur Laufzeit.

Dieser Ansatz hat mehrere Vorteile:

• Schnelle Anpassung - Konfiguration ändern, Hub neu laden, fertig
• Keine Kompilierung - Änderungen sind sofort wirksam
• OEM-Geräte - Gleiches Gerät, anderer Markenname? Eine Zeile in der Config
• Versionierung - YAML-Dateien lassen sich einfach in Git verwalten

Daemon-Architektur

Der Hub läuft als Sammlung von Daemons, die jeweils für einen Aufgabenbereich zuständig sind:

Modbus-Daemon

• Verwaltet alle konfigurierten Modbus-Geräte
• Pollt Register in konfigurierbaren Intervallen
• Cacht Werte für schnellen API-Zugriff
• Überwacht Verbindungsgesundheit

CAN-Daemon (in Entwicklung)

• Kommunikation mit WHIP Nodes
• Identifikationszeremonie
• GANGLION-Script-Upload
• Message-Routing

DALI-Daemon

• Lichtersteuerung
• Gruppenverwaltung
• Szenen-Management

Jeder Daemon läuft unabhängig. Fällt einer aus, arbeiten die anderen weiter.

Skalierung und Redundanz

Horizontale Skalierung

Ein WHIP-System kann mit den Anforderungen wachsen. Die typische Architektur:

                         ┌─── Hub 1 ─── 60 Nodes (Erdgeschoss)
                         │     └─── DALI (Beleuchtung EG)
                         │
Server ─── Ethernet ─────├─── Hub 2 ─── 60 Nodes (Obergeschoss)
                         │     └─── DALI (Beleuchtung OG)
                         │
                         ├─── Hub 3 ─── 60 Nodes (Keller/Technik)
                         │     └─── Modbus (Wechselrichter, BMS)
                         │
                         └─── Hub 4 ─── Außenbereich
                               └─── Relay (Bewässerung, Tor)

Hubs kommunizieren untereinander und mit dem Server über Ethernet. Es gibt keine harten Grenzen - fügen Sie Hubs hinzu, wenn Sie mehr Kapazität brauchen.

Flexible Rollen

Ein Hub kann verschiedene Rollen übernehmen:

• Reiner Node-Aggregator - CAN-Ethernet-Brücke
• Protokoll-Gateway - Modbus, DALI, MQTT
• Standalone-Controller - Kleines System ohne separaten Server
• Backup-Server - Übernimmt bei Server-Ausfall

Ausfallsicherheit durch Schichtung

Die dreistufige Architektur bietet natürliche Redundanz:

Ebene 3: Server fällt aus
→ Hubs arbeiten autonom weiter
→ Lokale Automatisierungen funktionieren
→ Keine Cloud-Anbindung, aber volle lokale Kontrolle

Ebene 2: Hub fällt aus
→ Nodes nutzen GANGLION für Basisfunktionen
→ Peer-to-Peer-Kommunikation über CAN
→ Einfache Regeln werden weiter ausgeführt

Ebene 1: Nur Nodes aktiv
→ Grundfunktionen bleiben erhalten
→ Licht, Heizung, kritische Systeme funktionieren
→ Keine zentrale Steuerung, aber auch kein Totalausfall

Ebene 0: Stromausfall
→ Nodes mit Batterie-Backup halten kritische Funktionen
→ DC-basierte Beleuchtung (in speziellen Installationen)
→ USV für Hub und Server (wo nötig)

Entwicklung und Konfiguration

Verzeichnisstruktur

Die Hub-Software ist klar strukturiert:

hub/
├── exe/WhipHub              # Hauptprogramm
├── lib/                     # Perl-Module
│   ├── WhipHub.pm          # Mojolicious-App
│   └── Perl/WhipHub/       # Implementierung
│       ├── Controller/     # API-Endpunkte
│       ├── Model/          # Geschäftslogik
│       └── Protocol/       # Protokoll-Handler
├── etc/                     # Konfiguration
├── public/                  # Statische Dateien, OpenAPI-Spec
├── templates/               # HTML-Templates
└── t/                       # Tests

Entwicklungsmodus

Für die Entwicklung bietet der Hub verschiedene Modi:

# Entwicklung (automatischer Reload bei Änderungen)
./WhipHub_start -m dev

# Staging (Produktions-ähnlich, aber mit Debug-Logging)
./WhipHub_start -m stag

# Produktion (optimiert, minimales Logging)
./WhipHub_start -m prod

Im Entwicklungsmodus läuft der Hub unter morbo mit Live-Reload. Ändern Sie eine Perl-Datei, und der Server startet automatisch neu.

Konfiguration eines neuen Geräts

Das Hinzufügen eines neuen Modbus-Geräts ist ein dreistufiger Prozess:

1. Vendor-Spezifikation erstellen (einmalig pro Gerätetyp)

# cfg/lib/vendor/mein_hersteller/mein_geraet.yaml
modbus:
  type: tcp
  default_port: 502
  registers:
    temperatur:
      address: 0x0100
      type: int16
      scale: 0.1
      unit: "°C"
    luftfeuchte:
      address: 0x0101
      type: uint16
      unit: "%"

2. Gerät in Site-Konfiguration referenzieren

# cfg/site/mein_haus.yaml
keller:
  heizraum:
    mein_sensor:
      isa: vendor/mein_hersteller/mein_geraet
      modbus:
        host: 192.168.1.50
        enabled: true
        poll_interval: 30

3. Hub-Konfiguration neu laden

curl -X POST http://hub:6363/modbus/reload

Keine Kompilierung, kein Deployment, keine Downtime.

Zusammenfassung

WHIP Hubs sind das intelligente Bindeglied zwischen der Echtzeitwelt der Sensoren und Aktoren und der vernetzten Welt moderner IT-Systeme:

• CAN-Ethernet-Brücke für bis zu 60 Nodes pro Hub
• Node-Management mit Identifikationszeremonie und GANGLION-Upload
• Protokoll-Übersetzer für Modbus, DALI, MQTT, SNMP
• Integrations-Gateway zu 30+ externen Diensten
• Datengetrieben - Konfiguration statt Programmierung
• Ausfallsicher durch hierarchische Redundanz

Dabei gilt immer: Der Hub fügt Intelligenz hinzu, ist aber nie Voraussetzung für den Grundbetrieb. Ein WHIP-System funktioniert auch dann, wenn alles außer den Nodes ausfällt.

In den folgenden Artikeln der Serie werden wir konkrete Anwendungsfälle vorstellen - von der Photovoltaik-Überwachung über intelligente Lüftungssteuerung bis hin zur ausfallsicheren DC-Beleuchtung.

Dieser Artikel ist Teil unserer Serie über das WHIP Smart-Home-System. Weitere Artikel: [WHIP Nodes: Die intelligentesten Knoten im Smart Home]