Skip to main content

Modules

Modules are the building blocks of an ArmorLink network.

A module represents an ESP32-based subsystem that participates in the ArmorLink ecosystem.

Examples include:

  • Helmets
  • Arms
  • Arc Reactors
  • Lighting Controllers
  • Audio Controllers
  • Sensor Modules
  • Any other ESP32-based device

A module combines application logic with ArmorLink functionality.

Creating a Module​

Every module starts with an ArmorLinkModule instance.

ArmorLinkModule module(
    "Helmet",
    ArmorLinkModuleType::Helmet
);

The module name identifies the module within the ArmorLink network.

The module type provides additional descriptive information.

Module Names​

Each module has a name.

Example names:

  • Helmet
  • Back
  • Left Arm
  • Right Arm
  • Arc Reactor

Module names should be unique within an ArmorLink network.

Commands are routed using the target module name, making unique names strongly recommended.

Module Types​

ArmorLink provides predefined module types.

Example:

ArmorLinkModule module(
    "Helmet",
    ArmorLinkModuleType::Helmet
);

ArmorLink provides several predefined module types such as Helmet, Arm, Hand, Leg, Back and Generic.

Module types are descriptive only and do not affect communication, routing or behavior.

Their primary purpose is to help identify and organize modules within the ArmorLink App.

Joining a Network​

A module initially exists independently.

Before it can participate in an ArmorLink network, it must be paired with a Gateway.

Once paired, the module becomes part of the network and can communicate with other modules through the Gateway.

For more information, see the Pairing section.

A Module is More Than a Device​

A module is not simply a communication endpoint.

A typical ArmorLink module consists of:

Module
?? Hardware
?? Application Logic
?? Actions
?? Configuration
?? Telemetry
?? Communication

ArmorLink handles communication and management.

Your firmware defines the actual behavior of the module.

Actions​

Modules expose functionality through Actions.

Examples:

  • Open Helmet
  • Toggle Faceplate
  • Fire Missile
  • Play Sound

Actions define functionality that can be executed through the ArmorLink network.

The ArmorLink App automatically discovers and displays available Actions.

Configuration​

Modules can expose configuration values.

Configuration values:

  • Are stored locally on the module
  • Persist across reboots
  • Can be modified through the ArmorLink App
  • May trigger callbacks when changed

Examples:

  • Audio volume
  • Servo positions
  • LED brightness
  • Animation timings

Telemetry​

Modules can provide live telemetry data.

Examples:

  • Battery voltage
  • Temperature
  • Sensor values
  • System status

Telemetry remains the responsibility of the module that produces it.

The Gateway does not permanently store telemetry data.

Sending Commands​

Modules are not limited to receiving commands.

Any module can initiate communication and send commands to other modules.

Example:

void btn1_handleClick()
{
    ArmorLink.sendCommand(
        "Helmet",
        "Facemask",
        "toggle"
    );
}

In this example, a local button press sends a command to the Helmet module.

The command is routed through the Gateway and delivered to the target module.

Buttons, sensors, timers and effects remain part of your application logic.

Example:

void btn1_handleClick()
{
    ledOn();

    ArmorLink.sendCommand(
        "Helmet",
        "Facemask",
        "toggle"
    );
}

The button press triggers local functionality and also sends a command through the ArmorLink network.

ArmorLink handles communication.

Your firmware defines behavior.

Summary​

Modules are the core building blocks of an ArmorLink network.

A module can:

  • Expose Actions
  • Provide Configuration
  • Publish Telemetry
  • Send Commands
  • Receive Commands

Modules remain responsible for their own functionality, data and behavior while ArmorLink provides communication and management infrastructure.