Skip to main content

Configuration

Configuration allows modules to expose persistent settings that can be viewed and modified through the ArmorLink App.

Configuration always belongs to the module that owns it.

The Gateway does not store configuration data for other modules.

For more information about Modules, see Modules.

Why Configuration?

Many ESP32 projects require values that should be adjustable without modifying firmware.

Examples include:

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

ArmorLink provides a unified configuration system that makes these values available through the ArmorLink App.

Configuration Ownership

Configuration values are stored locally on the module and persist automatically across reboots.

No additional persistence configuration is required.

tip

Configuration changes take effect immediately.

When a value is changed through the ArmorLink App, the updated value becomes instantly available on the module and optional change callbacks are executed automatically.

No reboot is required.

The Gateway acts only as a communication bridge between the App and the target module.

Supported Types

ArmorLink currently provides the following configuration field types:

TypeDescription
IntInteger value
FloatFloating-point value
BoolBoolean value
ReadonlyRead-only information field

Creating Configuration Fields

Example:

module.config()
.addInt("volume", &volume, 20);

This creates a persistent integer configuration value named volume.

Configuration values are automatically exposed to the ArmorLink App.

Configuration Metadata

Configuration fields define both the value itself and how the value should be presented inside the ArmorLink App.

Example:

module.config()
.addInt("volume", &volume, 20)
.label("Volume")
.section("Audio")
.description("DFPlayer volume")
.range(0, 30)
.step(1);

The ArmorLink App uses this metadata to automatically generate an appropriate user interface.

Available metadata includes:

  • label(...)
  • description(...)
  • section(...)
  • unit(...)
  • range(...)
  • step(...)
  • advanced(...)

Validation

Configuration fields can define validation rules.

Example:

.range(0, 30)
.step(1)

These values are used by the ArmorLink App when presenting and editing configuration values.

This helps prevent invalid input before it reaches the module.

Change Callbacks

Configuration values may react immediately when changed.

Example:

module.config()
.addInt("volume", &volume, 20)
.onIntChange([](int value)
{
dfplayer.volume(value);
});

When the user changes the value in the ArmorLink App:

User changes value
|
v
Configuration update sent
|
v
Module receives new value
|
v
onIntChange() executes
|
v
Application reacts immediately

No reboot is required.

Available callbacks include:

  • onIntChange(...)
  • onFloatChange(...)
  • onBoolChange(...)

The ArmorLink App automatically discovers configuration fields exposed by modules.

The App does not need to know anything about the module implementation.

The module describes its configuration fields and the App generates the user interface automatically.

This allows developers to expose configuration values without creating custom user interfaces.

Readonly Fields

Readonly fields provide information to the ArmorLink App without allowing modification.

Examples include:

  • Firmware version
  • Hardware revision
  • Device information
  • Calibration status

Readonly fields can be displayed alongside editable configuration values.

Summary

Configuration provides a simple way to expose persistent module settings.

Configuration values:

  • Belong to the module that owns them
  • Persist automatically
  • Are automatically exposed to the ArmorLink App
  • Support validation rules
  • Can trigger change callbacks
  • Become available immediately when changed

No reboot is required when configuration values are updated.