Module Design

Due to the highly variable number of inputs/outputs that might be connected to a single ESP32, the software should reflect this variability and be able to adapt to changes in the setup. Additionally, the communication protocol must allow for the exchange of data and instructions in a flexible way.

This is achieved by organizing every function in modules, that can be dynamically added to the system. Each module encapsulates a single specific function or task, offering methodes to control and reflect the current state of that function. Each module is independent and assumes as little prior information as possible about the outside world, the functioning of other modules or the state of itself and other modules.

graph TB
    hardware((hardware))

    subgraph ESP32[ESP32]
        direction LR
        manager(module manager)
        module[module]
        settings((settings))

        manager --- module --- settings
    end
    
    module -.- hardware

Loading

All module interactions are organized by a module manager that keeps track of modules and distributes events depending on their type. There are 2 types of events, internal events with limited content only intended for the modules on the same ESP32, and potentially external events that address other modules or the socket server.

graph TB
    subgraph ESP32
        manager(module manager)

        subgraph modules
            direction LR
            wifi(WiFi module)
            socket(socket.io module)
            input(input module)
            output(output module)
        end

        manager --> |distributes events| modules --> |issue events| manager
    end

Loading

The socket module plays a special role in this process as it is the endpoint for every outgoing or incoming communication with the server. For incoming messages it analyzes the event for valid status or command events before forwarding it to the module manager, which offers it to all other modules.

graph RL
    subgraph ESP32
        direction LR
        manager(module manager)

        subgraph modules
            direction TB
            wifi(WiFi module)
            socket(socket.io module)
            input(input module)
            output(output module)
        end
    end

    server[server]

    server --> |command/status| socket --> |forwards| manager --> |distributes| modules

Loading

For outgoing messages the sending module first hands the message to the module manager, which first checks if the target module is located on the same hardware. If that is the case, the message only gets forwarded to that module. If not, it instead is handed to the socket module, which forwards it to the server.

graph LR
    subgraph ESP32
        direction LR
        manager(module manager)

        subgraph modules
            direction TB
            wifi(WiFi module)
            socket(socket.io module)
            input(input module)
            output(output module)
        end
    end

    server[server]

    input --> |event| manager --> |forward| socket --> |send| server

Loading

For example the following diagram shows the communication pathways of an ESP32 holding an input and an output module; socket.io and wifi modules as well as the module manager omitted for clarity.

graph TB
    subgraph hardware
    direction TB
        voltage((voltage))
        relay((relay))
    end 

    subgraph ESP32
    direction LR
        module1(input module)
        module2(output module)

        module1 <--> |internal events| module2
    end

    module1 .-> |reads| voltage
    module2 .-> |controls| relay

    subgraph serverGraph [server]
        server[socket.io]
    end

    module1 & module2 <-- command/status --> server

Loading