Architecture

Layered Architecture

WomoNET follows a clean layered architecture pattern:

Communication Flow

Physical Devices  →  Drivers  →  MQTT Broker  →  Flutter App
                                      ↓
                                  Services
                             (Persistence, Updater)

Data Flow Details

Key Design Patterns

Component Model

Standardized interfaces for different device types:

• Sensors: Read-only data (temperature, battery SOC)
• Toggles: Binary on/off controls (lights, pumps)
• Sliders: Variable controls (dimmer, fan speed)
• Actuators: Bidirectional motor controls (awnings, lift beds, steps) with forward/reverse/stop states

Auto-discovery

Automatic device detection without manual configuration. Devices announce themselves via MQTT when connected.

Event-driven Architecture

All communication happens through MQTT pub/sub pattern, enabling:

• Loose coupling between components
• Real-time updates
• Scalability
• Fault tolerance

Dynamic Components

Runtime device registration and deregistration for bus-based devices (LIN, CAN).

Platform Abstraction

Clean separation between hardware-specific code and business logic, enabling:

• Cross-platform compatibility
• Easy testing
• Hardware independence

MQTT Protocol Structure

WomoNET uses a standardized MQTT topic structure for reliable communication:

Topic Patterns

State Topics (Device → App):

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

Command Topics (App → Device):

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

Device Discovery Topics:

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

Configuration Topics:

• Pattern: c/conf/ui/[layout_id] - UI layout configurations
• Example: c/conf/ui/1 - Default UI layout configuration

Client ID Convention

Client IDs must be globally unique within the WomoNET ecosystem:

• WomoNET Modules: Use “womonet-” prefix + last 4 characters of serial number
  • Examples: womonet-core, womonet-power-a3f2, womonet-climate-b7e1
• Third-party Vendors: Must use their own vendor-specific prefix
  • Examples: acmetech-solar-x8k9, smartrv-water-d5n6

The “womonet-” prefix is reserved exclusively for WomoNET manufactured modules.

Technical Implementation

Embedded OS

• Base: Yocto-based Linux distribution
• Hardware: STM32MP135F ARM-based processor
• Connectivity: Built-in WiFi access point for local networking
• Storage: Persistent configuration and data storage

Cross-Platform App

• Framework: Flutter for mobile, desktop, and web
• Communication: MQTT client with automatic reconnection
• UI: Responsive design adapting to different screen sizes
• Offline: Cached state for continued operation during network issues

Core Services (Rust)

• Device Drivers: Hardware abstraction in womonet-drivers
• Framework: Core abstractions in womonet-framework
• Platform: Hardware platform support in womonet-core-platform
• Services: Background processes for persistence, updates, and setup

Network Architecture

• Local-First: No internet required for basic operation
• MQTT Broker: Runs locally on WomoNET.core device
• Discovery: Automatic device detection and registration via MQTT topics
• Security: Local network isolation with optional external access
• T1S Support: MQTT over T1S (10Base-T1S Single Pair Ethernet) for efficient networking
• Third-Party Integration: Open protocol allows any vendor to create compatible devices

Ecosystem Integration

For Hardware Manufacturers

WomoNET provides a comprehensive framework that hardware manufacturers can leverage:

• Standardized Protocol: Simple MQTT-based communication protocol
• Component Model: Pre-defined interfaces for sensors, toggles, sliders, and bidirectional actuators
• Auto-Discovery: Devices automatically announce themselves when connected
• Client ID Convention: Unique naming scheme prevents conflicts between vendors
• Development Support: Open-source drivers and documentation for reference implementations

Supported Device Types

The framework supports various device categories through standardized component interfaces:

• Environmental Sensors: Temperature, humidity, pressure monitoring
• Battery Management: SOC monitoring, voltage/current measurement
• Power Systems: Inverter control, solar charge controllers
• Heating Systems: Climate control, water heating
• Lighting: Dimmable lights, switches, indicators
• Water Systems: Tank monitoring, pump control
• Motor Controls: Awnings, lift beds, steps with directional control (forward/reverse/stop)
• Custom Devices: Extensible framework for new device types