🪞 Device Shadow & Rules Engine

Jembatan dua arah antara cloud dan device, plus otomasi berbasis aturan.

Konsep device shadow reported dan desired

Shadow: reported (dari device) vs desired (perintah dari cloud)

📌 1. Device Shadow: "Kembar Digital" Device

Device IoT sering offline (baterai, sinyal). Shadow adalah JSON di cloud yang menyimpan status terakhir device, dengan dua bagian:

Bagian	Arah	Isi
`reported`	Device → Cloud	Status aktual terakhir: `{"suhu": 27.5, "baterai": 80}`
`desired`	Cloud → Device	Perintah yang harus dijalankan: `{"ac": "ON"}`

Alur kerja: aplikasi HP menulis desired → device (saat online) membaca desired → menjalankannya → melaporkan ke reported. Jika device offline saat perintah dikirim, perintah menunggu di shadow sampai device kembali online.

📌 2. Rules Engine: Otomasi di Cloud

Rules engine = "jika … maka …" yang berjalan di platform. Contoh: jika suhu > 28 maka set AC desired = ON. Kelebihannya: logika terpusat, device tetap bodoh & hemat daya.

cloud = CloudPlatform("IoTCloud")
cloud.register_device("ac-01")

def auto_ac(state):
    """RULE: suhu > 28 → perintah AC ON, selain itu OFF."""
    target = "ON" if state["suhu"] > 28 else "OFF"
    cloud.set_desired("ac-01", {"ac": target})
    print("  🔔 RULE auto-ac: suhu %.1f°C → AC desired=%s" % (state["suhu"], target))

# Daftarkan aturan: aktif untuk semua data device ac-01
cloud.add_rule("auto-ac", "devices/ac-01/data", auto_ac)

print("=== RULES ENGINE: AC OTOMATIS ===")
for i in range(6):
    state = {"suhu": read_sensor("dht22_temp")}
    cloud.update_shadow("ac-01", state)   # setiap laporan memicu rules
    delay(10)

print()
print("Shadow akhir:", cloud.get_shadow("ac-01"))

Output:

📌 3. Sisi Device: Menjalankan Perintah (Desired)

Sekarang dari sisi device: device polling shadow-nya, menjalankan perintah desired, lalu melaporkan ke reported.

cloud = CloudPlatform("IoTCloud")
cloud.register_device("lampu-01")
# Aplikasi HP mengirim perintah:
cloud.set_desired("lampu-01", {"nyala": True})

print("=== DEVICE POLLING PERINTIHAN (DESIRED) ===")
for i in range(4):
    sh = cloud.get_shadow("lampu-01")
    if sh["desired"]:
        perintah = sh["desired"]
        print("t=%3.0fs  perintah diterima: %s → LAMPU DINYALAKAN 💡"
              % (now(), perintah))
        # Device "melakukan" perintah, lalu laporkan ke reported
        cloud.update_shadow("lampu-01", {"nyala": True})
        # Perintah sudah dieksekusi → bersihkan desired
        cloud.shadow["lampu-01"]["desired"] = {}
    else:
        print("t=%3.0fs  tidak ada perintah baru" % now())
    delay(10)

print()
print("Shadow akhir:", cloud.get_shadow("lampu-01"))

Output:

Di platform nyata (AWS IoT), device tidak perlu polling — shadow di-push ke device via MQTT saat berubah. Polling dipakai di sini agar alurnya terlihat jelas.

📌 4. OTA Update: Memperbarui Firmware dari Jauh

Ribuan device tersebar? Tidak mungkin buka sekrup satu-satu. Over-The-Air (OTA) update mengirim firmware baru via jaringan:

Platform menyimpan versi firmware + checksum.
Device mengecek versi: desired: {"firmware": "v2.1.0"}.
Device mengunduh (biasanya HTTP), memverifikasi checksum, menulis ke flash.
Device reboot → melaporkan versi baru ke reported.

⚠️ OTA yang gagal di tengah proses bisa "membrick" device. Mitigasi: dual partition (A/B) — jika versi baru gagal boot, otomatis kembali ke versi lama.

🧠 Latihan

Tambah rule kedua di editor 1: jika RTH > 75 → set_desired("ac-01", {"dehumidifier": "ON"}). (Tambahkan kunci "rth" di state.)
Ubah editor 2: device menerima perintah {"nyala": False} — pastikan lampu benar-benar mati (reported = {"nyala": False}).
Buat skenario "device offline": set desired, lalu (simulasikan) device baru online 30 detik kemudian — perintah tetap dijalankan. Jelaskan kenapa shadow membuat ini mungkin.
Rancang alur OTA untuk 500 sensor: apa yang terjadi jika 30% gagal update? Bagaimana rollback-nya?