Architektur

Schichtarchitektur

WomoNET folgt einem sauberen Schichtarchitektur-Muster:

Kommunikationsfluss

Physische Geräte  →  Treiber  →  MQTT Broker  →  Flutter App
                                      ↓
                                  Services
                           (Persistierung, Updater)

Datenfluss-Details

Wichtige Design-Muster

Komponenten-Modell

Standardisierte Schnittstellen für verschiedene Gerätetypen:

• Sensoren: Nur-Lese-Daten (Temperatur, Batterie SOC)
• Schalter: Binäre Ein/Aus-Steuerungen (Lichter, Pumpen)
• Schieberegler: Variable Steuerungen (Dimmer, Lüftergeschwindigkeit)
• Aktoren: Bidirektionale Motorsteuerungen (Markisen, Hubbetten, Trittstufen) mit Vorwärts/Rückwärts/Stopp-Zuständen

Auto-Erkennung

Automatische Geräteerkennung ohne manuelle Konfiguration. Geräte kündigen sich über MQTT an, wenn sie verbunden werden.

Ereignisgetriebene Architektur

Alle Kommunikation erfolgt über MQTT Pub/Sub-Muster und ermöglicht:

• Lose Kopplung zwischen Komponenten
• Echtzeit-Updates
• Skalierbarkeit
• Fehlertoleranz

Dynamische Komponenten

Laufzeit-Geräteregistrierung und -abmeldung für Bus-basierte Geräte (LIN, CAN).

Plattform-Abstraktion

Saubere Trennung zwischen hardwarespezifischem Code und Geschäftslogik, ermöglicht:

• Plattformübergreifende Kompatibilität
• Einfaches Testen
• Hardware-Unabhängigkeit

MQTT-Protokoll-Struktur

WomoNET verwendet eine standardisierte MQTT-Topic-Struktur für zuverlässige Kommunikation:

Topic-Muster

Zustands-Topics (Gerät → App):

• Muster: s/<client-id>/<device>/<component>/state
• Beispiel: s/womonet-core/vedirect-battery-2/battery_soc/state

Befehls-Topics (App → Gerät):

• Muster: s/<client-id>/<device>/<component>/set/state
• Beispiel: s/womonet-core/vebus-d929/inverter-enabled/set/state

Geräteerkennung-Topics:

• Muster: c/dev/[client_id]/[device_name]/[component]/[component_name]
• Beispiel: c/dev/womonet-core/alde_1b/sensor/zone1_temp
• Beispiel: c/dev/womonet-power-a3f2/battery_monitor/sensor/soc

Konfigurations-Topics:

• Muster: c/conf/ui/[layout_id] - UI-Layout-Konfigurationen
• Beispiel: c/conf/ui/1 - Standard UI-Layout-Konfiguration

Client-ID-Konvention

Client-IDs müssen innerhalb des WomoNET-Ökosystems global eindeutig sein:

• WomoNET-Module: Verwenden “womonet-” Präfix + letzte 4 Zeichen der Seriennummer
  • Beispiele: womonet-core, womonet-power-a3f2, womonet-climate-b7e1
• Drittanbieter: Müssen ihr eigenes herstellerspezifisches Präfix verwenden
  • Beispiele: acmetech-solar-x8k9, smartrv-water-d5n6

Das “womonet-” Präfix ist ausschließlich für WomoNET-hergestellte Module reserviert.

Technische Implementierung

Eingebettetes OS

• Basis: Yocto-basierte Linux-Distribution
• Hardware: STM32MP135F ARM-basierter Prozessor
• Konnektivität: Integrierter WiFi-Access-Point für lokale Netzwerke
• Speicher: Persistente Konfigurations- und Datenspeicherung

Plattformübergreifende App

• Framework: Flutter für mobil, Desktop und Web
• Kommunikation: MQTT-Client mit automatischer Wiederverbindung
• UI: Responsives Design für verschiedene Bildschirmgrößen
• Offline: Zwischengespeicherter Zustand für Betrieb bei Netzwerkproblemen

Kern-Services (Rust)

• Gerätetreiber: Hardware-Abstraktion in womonet-drivers
• Framework: Kern-Abstraktionen in womonet-framework
• Plattform: Hardware-Plattform-Support in womonet-core-platform
• Services: Hintergrundprozesse für Persistierung, Updates und Setup

Netzwerk-Architektur

• Local-First: Kein Internet für Grundfunktionen erforderlich
• MQTT Broker: Läuft lokal auf WomoNET.core-Gerät
• Erkennung: Automatische Geräteerkennung und -registrierung über MQTT-Topics
• Sicherheit: Lokale Netzwerktrennung mit optionalem externem Zugang
• T1S-Unterstützung: MQTT über T1S (10Base-T1S Single Pair Ethernet) für effizientes Netzwerken
• Drittanbieter-Integration: Offenes Protokoll ermöglicht es jedem Anbieter, kompatible Geräte zu erstellen

Ökosystem-Integration

Für Hardware-Hersteller

WomoNET bietet ein umfassendes Framework, das Hardware-Hersteller nutzen können:

• Standardisiertes Protokoll: Einfaches MQTT-basiertes Kommunikationsprotokoll
• Komponenten-Modell: Vordefinierte Schnittstellen für Sensoren, Schalter, Schieberegler und bidirektionale Aktoren
• Auto-Erkennung: Geräte kündigen sich automatisch an, wenn sie verbunden werden
• Client-ID-Konvention: Eindeutiges Namensschema verhindert Konflikte zwischen Anbietern
• Entwicklungsunterstützung: Open-Source-Treiber und Dokumentation als Referenzimplementierungen

Unterstützte Gerätetypen

Das Framework unterstützt verschiedene Gerätekategorien durch standardisierte Komponentenschnittstellen:

• Umweltsensoren: Temperatur-, Feuchtigkeits-, Drucküberwachung
• Batterie-Management: SOC-Überwachung, Spannungs-/Strommessung
• Stromsysteme: Wechselrichtersteuerung, Solar-Laderegler
• Heizsysteme: Klimasteuerung, Wasserheizung
• Beleuchtung: Dimmbare Lichter, Schalter, Anzeigen
• Wassersysteme: Tanküberwachung, Pumpensteuerung
• Motorsteuerungen: Markisen, Hubbetten, Trittstufen mit Richtungssteuerung (Vorwärts/Rückwärts/Stopp)
• Benutzerdefinierte Geräte: Erweiterbares Framework für neue Gerätetypen