Firmware startup¶

The project skeleton completely repeats the chapter from the cabinet example: PlatformIO, secrets.h, idryer-core in lib/, same platformio.ini (replace only the environment name with filter). Here — only what's different.

Config: non-standard device type¶

The filter has neither a heater nor a climate sensor from the ecosystem vocabulary. From "vocabulary" skills it has only a fan. In src/main.cpp:

#include <iDryer.h>

static const iDryer::Config CFG = {
    .deviceType        = iDryer::DeviceType::Unknown, // non-standard device
    .unitsCount        = 1,
    // Periphery: from the ecosystem vocabulary we have only a fan.
    .hasFan            = true,
    // Auto-publication periods:
    .telemetryPeriodMs = 5000,
    .statusPeriodMs    = 10000,
    // Identification on the portal:
    .hardwareVersion   = "1.0",
    .firmwareVersion   = "0.1.0",
    .model             = "DIY Air Filter",
};

static iDryer::Link s_link(CFG);

void setup() {
    Serial.begin(115200);
    s_link.begin();
}

void loop() {
    s_link.loop();
}

DeviceType::Unknown is normal

The Unknown type means "the portal doesn't know of such a product." Previously this was a problem: the portal had no card for an unknown type. Now this is the standard path: the device interface will be fully described by the card manifest (chapter 6), and the portal will build the card from it. The type is needed only for "native" iDryer devices that have branded cards.

The hasFan = true flag gives us for free: the fanStatus field in telemetry, the "Fan" cell on the card, and an entity in the manifest — all from the ecosystem vocabulary.

VOC sensor is not in Config — and should not be¶

Note: there is no "hasVoc" flag in Config. The vocabulary has* describes periphery that the ecosystem knows about. You will add your own sensor not through the vocabulary, but through two other mechanisms: write its readings into telemetry as your own field, and declare it in the card manifest — these are the next two chapters. This is the whole point of the approach: the vocabulary does not need to be extended for every new device.

First startup and linking¶

The procedure is no different from the cabinet example:

Flash the board, open Serial Monitor.
The device will raise Wi-Fi (data from secrets.h), register, and print the PIN:
```
[CLOUD] PIN: 1234567 (expires in 600s)
```
On the portal — "Add device" → enter the PIN.
After linking, Device claimed! will appear in the log, the device will go Online.

Detailed breakdown of linking, Wi-Fi errors, and re-linking — in the chapter of the cabinet example.

The device is already visible on the portal, but the card is still almost empty — there's no data yet. Let's connect the sensor.