Skip to content

Основные потоки данных

Разработчик продукта: 00-for-product-developers.md.

Device Configuration Flow

Сценарий A: MCU первый 

MCU → Hello (role=1, units, caps) → LINK
LINK → HelloAck (IP, SSID) → MCU
LINK → info → Backend

Сценарий B: LINK первый 

LINK → Hello (role=0xFF) → MCU (триггер)
MCU → Hello (role=1, units, caps) → LINK
LINK → HelloAck (IP, SSID) → MCU
LINK → info → Backend

Payload info: 

{
  "firmwareVersion": "1.2.3",
  "unitsCount": 2,
  "units": [
    {"unitId": 0, "scales": [0,1], "rfid": [0], "capabilities": {...}}
  ],
  "mcuSerial": "36B955AB4350"
}

Remote Config Flow

MCU — источник истины для настроек. LINK собирает полный JSON из vals + menu_meta.h.

Backend → Device (set / invoke): 1. MQTT commands/set или commands/invoke → LINK 2. LINK → UART ConfigPush (JSON с cmd) → MCU 3. MCU применяет, инкрементирует rev, сохраняет 4. MCU → UART delta → LINK → MQTT config/delta

Device → Backend (get_config): 1. MQTT commands/get_config → LINK 2. LINK → UART Command{GetConfig} → MCU 3. MCU → UART vals → LINK 4. LINK собирает полный JSON → MQTT config

Config revision: MCU инкрементирует rev при каждом изменении. Гарантирует консистентность.

Claiming Flow

  1. MCU → UART ClaimStart → LINK (по действию пользователя)
  2. LINK → POST …/devices/provision с { "serialNumber": "<id моста>" } → сохраняет deviceToken в NVS (если deviceToken: null и isClaimed: true — устройство уже привязано на портале; token не выдаётся, нужен сценарий recovery через UI портала)
  3. LINK → POST …/devices/register с { "token", "serialNumber"? } → PIN или { alreadyClaimed, deviceId } (без PIN)
  4. LINK → UART ClaimStatus{pin, timer} → MCU (показ PIN), периодически обновляя статус по мере ответов backend
  5. Пользователь вводит PIN в портал → POST …/devices/claim (Bearer пользовательский JWT, не device token)
  6. LINK опрашивает GET …/devices/check-claim/:token (token = deviceToken) → 404 пока не привязано, 200 + deviceId после успешного claim
  7. LINK → UART ClaimComplete{success, deviceId} → MCU
  8. LINK сохраняет при необходимости deviceId в NVS; MQTT использует serialNumber + deviceToken как описано в MQTT API

Полные пути, коды ответов и форматы тел: HTTP API портала. Поведение Link UNCLAIMED / CLAIMED / BOUND и матрица unlink/remove — в репозитории портала docs/development/LINK_CLAIM_SCENARIOS.md.

Events Flow

Device → Backend (активные топики): - telemetry — с UART (1с активный, 15с idle на стороне MCU); публикация в MQTT задаётся приложением - status — при изменении режима (retained) - weights — по интервалу / событию - rfid — tag_detected/tag_removed (retained)

Топик events: MqttClient::publishEvent() не вызывается из UartBridge и не из «облачного» модуля библиотеки автоматически. Референсный Link вызывает его из IdryerDevice (UART Log и ошибки протокола). Своя прошивка без соответствующих колбэков не сформирует поток. Подробнее: MQTT API.

Для публикуемых JSON (info, телеметрия и т.д.) при формировании в коде добавляется timestamp (ISO 8601, UTC) там, где это реализовано в MqttClient / TelemetryPublisher.