Skip to content

Сверка all-in-one-protocol.csv с каноном

Источники правды: docs/02-uart/02-binary-format.md, docs/02-uart/01-uart.md, docs/03-mqtt/01-mqtt.md, src/uart/uart_protocol.h, backend iDryer Portal для HTTP.

Общий реестр расхождений, незавершённых фич и вопросов вне узкой сверки CSV: protocol-gaps-and-followups.md.

CSV — сводная таблица «на одном листе»; при расхождении побеждают Markdown и заголовки в коде.


Критические ошибки (исправлены или отмечены в CSV)

Проблема Было в CSV Канон
Коды RFID data RfidReadData 0x15, RfidWriteData 0x16 0x1A, 0x1B (uart_protocol.h; 0x15–0x19 зарезервированы)
HTTP check-claim GET /check-claim/:token GET /devices/check-claim/:token (+ база /api на проде)
Топик RFID событий {serial}/rfid/events {serial}/rfid
Ссылка на claiming doc docs/uart-claiming-flow.md файла нет → docs/10-flows/01-basic-flows.md

Структуры UART vs CSV

Элемент CSV Канон (02-binary-format.md)
TelemetryEntry humidity как uint8 uint16 LE humidityPct10 (×10 %)
StatusEntry нет stagePhase / padding 32 байта, поля stagePhase, _pad
HeartbeatPayload 8 байт в описании 9 байт, последний байт cloudState (ESP→MCU)
ConfigPush payload «fragment[MAX…]» ConfigChunkPayload 200 B: transferId, totalSize, chunkIndex, data[194]
Hello → MQTT info Упрощённый JSON В спеке у Hello полный 86 B + units/mcuSerial; JSON info в MQTT богаче, см. код публикации
Log (0x60) Строки в CSV Норматив: LogPayload 164 B и таблица полей в 02-binary-format.md

MQTT / продуктовые расхождения

Тема CSV Канон
Телеметрия, период «Каждые 5 сек» UART: 1 с активный / 15 с idle; интервал MQTT задаёт приложение (см. 01-mqtt.md)
events + Log 0x60 Детальный JSON и Log→events UartBridge — только logHandler_. Референс LinkpublishEvent из IdryerDevice. LogPayload: 02-binary-format.md § Log (0x60). CSV сверять с Markdown
rfid/read, write по MQTT Полные цепочки с base64 ReadRfid на UART есть; write_rfid в обработчике не реализован; интеграция RfidReadData/WriteData — в доках помечена как неполная
read_rfid JSON readerId, tagId строками В 01-mqtt.md пример: {"unitId": "U1"}; readerId в rfid событии — число
Команды MQTT Есть drying, stop, get_config, set, invoke, ping, read/write_rfid Нет строк для storage, find, profile, clear_errors — они есть в 01-mqtt.md
drying JSON mode: DRYING в примере Часто достаточно params + unitId; см. 01-mqtt.md

HTTP claiming

Поле CSV Канон
register body только token опционально serialNumber (нужен, если Link ещё не создан)
provision response кратко для CLAIMED/BOUNDdeviceToken: null (см. 04-cloud/01-portal-http-claiming.md)

Рекомендации

  1. Поддерживать CSV только как обзор; правки вносить после обновления Markdown/кода.
  2. Либо генерировать CSV из структурированного источника, либо раз в релиз прогонять эту сверку.
  3. Строки про rfid/read, write_rfid помечать как «план / не полностью в проде», если оставляете в таблице. По events: в референсном Link поток есть при регистрации колбэков; отдельные поля (например errorsSinceBoot из heartbeat MCU) в MQTT не выведены — см. 01-mqtt.md.

Сверка с кодом библиотеки (краткий итог)

Согласовано с uart_protocol.h / idryer_topics.h / command_handler.cpp после правок CSV:

  • Коды RfidReadData / RfidWriteData, структуры TelemetryEntry, HeartbeatPayload (+cloudState), StatusEntry (+stagePhase), LogPayload, RfidDataPayload (163+…), ConfigChunkHeader + 194 байт данных.
  • Топик MQTT для событий RFID: суффикс rfid, не rfid/events.
  • handleWriteRfid — только лог «not implemented yet».
  • IDRYER_INTERVAL_TELEMETRY_MS = 5000 (ориентир MQTT); UART с MCU: TELEMETRY_ACTIVE_INTERVAL_MS = 1000, idle 15000.

По-прежнему не как в «идеальном» CSV или не подключено в Link:

Тема Код / прошивка
{serial}/rfid/read В idryer_topics.h нет отдельного суффикса; publishRfid() шлёт только в rfid. В IdryerDevice.cpp не зарегистрирован setRfidDataHandler — цепочка MCU→MQTT для read data может быть не собрана в референсной прошивке.
Log 0x60 → events В UartBridge только logHandler_(payload, len). В Link (IdryerDevice::handleLog) при онлайне вызывается publishEvent — см. уточнённый раздел в 01-mqtt.md. Своя прошивка без такого колбэка не шлёт events.
ClaimStatus по UART В Link отправляется из колбэков (onClaimPin, onUnclaimed), не по таймеру 2 с.

Итог: не «всё» документация и CSV = ровно то, что в рантайме; спека и CSV описывают контракт и часть будущих путей. Для гарантии смотреть файлы выше и src/.

Нюансы референсного Link (heartbeat DEBUG, строгая длина Log и т.д.) перенесены в таблицы protocol-gaps-and-followups.md.