ADR-009: Raw vs Parsed Template Mimarisi
| Durum | Kabul Edildi |
| Tarih | 2026-02 |
| Karar Veren | Güçlü Ceyhan |
Baglam
Zeus 2.0, farkli marka ve model Modbus cihazlarini destekler: inverterler (Huawei, Sofar, Sungrow vb.), enerji analorleri, meteoroloji istasyonlari. Her cihaz modeli farkli Modbus register haritasina sahiptir.
Sorunlar:
- Yeni cihaz modeli deestegi: Her yeni marka/model icin ESP32 firmware degisikligi mi gerekecek?
- Register haritasi farkliliklari: Ayni bilgi (ornegin anlik guc) farkli modellerde farkli register adreslerinde
- Veri donusumu: Bazi register'lar olcekleme (scale factor), byte sirasi (endianness), birlestirme (32-bit = 2x16-bit) gerektirir
- Saha guncellemesi: Firmware OTA ile gonderiliyor — her cihaz modeli icin firmware degistirmek operasyonel yuk
Karar
Iki mod desteklenir — gateway tipi (Standard veya Raw) belirler:
Standard Gateway (Template ESP32'de islenir)
ESP32 firmware template JSON'u icerir
→ Register haritasina gore Modbus okur
→ Veriyi isler (olcekleme, birlestirme)
→ Islenmis veriyi MQTT ile publish eder
→ Backend dogrudan kaydeder
Raw Gateway (Template backend'de islenir)
ESP32 ham register degerlerini okur
→ Raw byte verilerini MQTT ile publish eder
→ Backend template JSON'a gore parse eder
→ Islenmis veriyi kaydeder
Template Dosya Formati (JSON)
{
"model": "sofar-ktl-x",
"manufacturer": "Sofar Solar",
"device_type": "inverter",
"registers": [
{
"name": "active_power",
"address": 0x0485,
"length": 2,
"data_type": "uint32",
"scale": 0.01,
"unit": "kW",
"group": "power"
}
]
}
Alternatifler
Sadece ESP32'de parsing (Standard only)
- Artilari: Dusuk MQTT trafigi (sadece islenmis veri), backend basit
- Eksileri: Her yeni cihaz modeli icin firmware guncelleme gerekir, template degisikligi OTA gerektirir
- Red nedeni: Yeni cihaz modeli eklemek icin tum gateway'lere OTA gondermek operasyonel olarak agir
Sadece backend'de parsing (Raw only)
- Artilari: ESP32 firmware'i jenerik — hic degistirmeden yeni cihaz destegi, tum logic backend'de
- Eksileri: MQTT trafigi yuksek (ham register verileri), backend CPU yuku artar, agi daha yogun kullanir
- Red nedeni: Yuzlerce cihazdan ham veri gonderilmesi MQTT ve backend uzerinde gereksiz yuk olusturur
Scripting (Lua/MicroPython) ESP32 uzerinde
- Artilari: Esnek, firmware degistirmeden script guncellenebilir
- Eksileri: ESP32'de bellek/performans kisitlamalari, interpreter overhead, guvenlik riski (kod enjeksiyonu)
- Red nedeni: ESP32 kaynaklarinda interpreter calistirmak performans ve guvenlik riski
Gerekce
Iki modlu mimari su avantajlari sundu:
- Standard mod — performans: Bilinen ve stabil cihaz modelleri icin template ESP32'de islenir, dusuk MQTT trafigi, backend yuku minimum
- Raw mod — esneklik: Yeni veya legacy cihaz modelleri icin ESP32 firmware guncellemesi gerekmez — backend'e yeni template JSON eklemek yeterli
- Template dosyalari JSON: Kolay olusturulur, versiyonlanir, dosya sistemi uzerinden yonetilir
- Gecis esnekligi: Bir cihaz modeli Raw mod ile hizla desteklenir, template olgunlasinca Standard moda gecirilebilir
- Firmware bagimsizligi: Raw mod'daki gateway'ler jenerik firmware calistirir — marka/model farketmez
Sonuclar
Olumlu
- Yeni cihaz modeli destegi saatler icinde eklenebilir (Raw mod ile)
- Mevcut stabil modeller icin optimize performans (Standard mod)
- Template JSON dosyalari versiyon kontrolunde — degisiklik takibi kolay
- ESP32 firmware'i iki modda da calisabilir — deployment esnekligi
- Backend template parse edici yeniden kullanilabilir — birkac satir kod ile yeni model
Olumsuz
- Iki ayri pipeline bakimi: Standard ve Raw mod icin farkli veri isleme akislari — kod tekrari riski (ortak katman ile minimize edilmis)
- Raw mod MQTT trafigi: Ham register verileri islenmis veriye gore daha buyuk — bant genisligi maliyeti
- Template senkronizasyonu: Standard mod'da ESP32'deki template ile backend'deki template uyumlu olmali — versiyon uyusmazligi hatalara yol acar
- Test karmasikligi: Her iki mod icin ayri test senaryolari gerekir