Add a peripheral

When to use

If the device needs to control hardware on a command from the cloud or LAN — relay, heater, LED strip, motor — use this recipe.

Ready-to-use code

// main.cpp
#include <iDryer.h>
#include <runtime/idryer_runtime.h>

static const iDryer::Config CFG = {
    .deviceType      = iDryer::DeviceType::StorageLink,
    .unitsCount      = 1,
    .hardwareVersion = "1.0",
    .firmwareVersion = "1.0.0",
};

static iDryer::Link s_link(CFG);

static void handleCommand(const char* cmd, JsonObjectConst data) {
    if (!cmd) return;

    if (strcmp(cmd, "invoke") == 0) {
        const char* action = data["action"] | "";

        if (strcmp(action, "fan.on") == 0) {
            myFan.on();
            s_link.publishStatusNow();  // reflect new state immediately
            return;
        }
        if (strcmp(action, "fan.off") == 0) {
            myFan.off();
            s_link.publishStatusNow();
            return;
        }
    }

    if (strcmp(cmd, "drying") == 0) {
        float targetTempC  = data["targetTempC"]  | 45.0f;
        uint32_t durationS = data["durationS"]    | 0;
        myHeater.start(targetTempC, durationS);
        s_link.status.mode[0]        = iDryer::UnitMode::Drying;
        s_link.status.targetTempC[0] = targetTempC;
        s_link.status.durationS[0]   = durationS;
        s_link.publishStatusNow();
        return;
    }

    if (strcmp(cmd, "stop") == 0) {
        myHeater.stop();
        s_link.status.mode[0] = iDryer::UnitMode::Idle;
        s_link.publishStatusNow();
        return;
    }
}

void setup() {
    myFan.begin();
    myHeater.begin();
    s_link.begin();
    // IMPORTANT: setCommandHandler — strictly AFTER begin().
    // begin() installs its own dispatcher; our handleCommand must overwrite it.
    s_link.runtime()->setCommandHandler(handleCommand);
}

void loop() {
    s_link.loop();
    myFan.tick();
    myHeater.tick();
}

Explanation

s_link.runtime()->setCommandHandler(handleCommand) is the single connection point for the command handler. After this call all incoming MQTT commands (invoke, set, drying, stop, ping, get_config, etc.) reach handleCommand directly.

s_link.publishStatusNow() — call after every change to s_link.status.*. This immediately sends the new state to the portal and LAN clients without waiting for the statusPeriodMs timer.

Never call delay() inside handleCommand — the call is synchronous from an MQTT callback; blocking it breaks the session. Place timers in the loop() of the product object.

Alternative: link.onCommand()

If you don't need to parse the whole command stream, hang a handler on a command name — one per command:

s_link.onCommand("drying", [](JsonObjectConst data) {
    myHeater.start(data["targetTempC"] | 0, data["durationS"] | 0);
});
s_link.onCommand("stop", [](JsonObjectConst) {
    myHeater.stop();
});

The name is arbitrary, no more than twelve commands. link_integration, bambu_apply and ping are handled by the library itself — your handler under the same name runs after the library's own.

It does not work alongside setCommandHandler: the full dispatcher intercepts everything, and handlers from onCommand() are not called via the MQTT path. See 03-public-api/01-link-api-reference.md for details.

Full example in the repo

Reference implementation: handleCommand handling drying / stop in iHeater-link/src/main.cpp.