Config dan laporan

Halaman ini untuk integrator yang mengirim konfigurasi ke Sentinel. Daftar key ada di Key konfigurasi.

Mengirim

Dari mana	Topik publish
Celestian / klien di sisi pusat	m/<workspace>/c/<channel>/<mac>/config
Klien di LAN rak (broker lokal gateway)	sentinel/<mac>/config

Payload	objek JSON; hanya key yang ada yang diubah, key lain tetap
QoS / retain	1 / ya
Payload kosong	diabaikan
Key tidak dikenal	tidak diterapkan; masuk rejected dengan alasan key tidak dikenal
Tipe salah atau di luar rentang	key itu tidak diterapkan, masuk rejected dengan alasan; key lain di pesan yang sama tetap diterapkan
Persisten	disimpan di flash; bertahan setelah reboot
cfg_ver	bilangan bulat 0 … 4294967295 dari server; dicatat dan dilaporkan balik. Node tidak menolak versi yang lebih kecil

{"cfg_ver": 12, "temp_warn_c": 28, "temp_alarm_c": 32, "temp_alarm_hyst_c": 1, "alarm_delay_s": 30, "alarm_buzzer": true}

Tiga hal yang harus diperhatikan

1. Kirim hanya key yang memang ingin diatur. Key koneksi (workspace, channel, mqtt_host, mqtt_port, mqtt_user, mqtt_pass, ntp_server) serta sht41 dan lcd memicu reboot bila nilainya berubah. Jangan mengirim ulang isi config/reported mentah-mentah.
2. Kirim seluruh set key yang dikelola dalam satu pesan. Broker hanya menyimpan satu pesan retained per topik.
3. Naikkan cfg_ver setiap kali isi berubah.

Key koneksi dilarang diubah dari Celestian (dikecualikan di katalog Celestian); ubah lewat web atau USB serial.

Memverifikasi: config/reported

Setiap kali node menerima config, dan setiap kali tersambung ke broker, node mengirim …/<mac>/config/reported (JSON, retained, QoS 1). Laporan juga dikirim ulang saat pengikatan sensor suhu berubah, tanpa perubahan cfg_ver.

{
  "cfg_ver": 12,
  "rejected": {"alarm_delay_s": "di luar rentang 0..3600"},
  "fw": "0.21.1", "model": "SNT-G1", "hw": "A", "fw_status": "current", "device": "001a2b3c4d5e", "ts": 1790000000,
  "telemetry_interval_ms": 10000, "temp_warn_c": 28, "temp_alarm_c": 32,
  "t1_rom": "28a54dca18253061",
  "discovered": [],
  "features": ["tgroups"]
}

Field	Arti
cfg_ver, rejected	versi yang berlaku dan key yang ditolak beserta alasannya. rejected selalu ada; objek kosong = semua key di pesan terakhir diterima. Hanya hasil pesan terakhir
key konfigurasi	semua key dengan nilai yang berlaku. mqtt_pass tidak pernah dilaporkan; mqtt_ca hanya diwakili mqtt_ca_set, mqtt_ca_subject, mqtt_ca_sha256, mqtt_ca_not_after, mqtt_ca_expired
discovered	ROM DS18B20 di bus yang belum terikat ke slot
fw, model, fw_status, fw_pending_verify, fw_rolled_back	status firmware (Firmware dan OTA)
mqtt_endpoint_effective, ntp_server_effective	tujuan MQTT dan daftar NTP yang sedang dipakai
web_pw_default	true selama password web masih bawaan
features	kemampuan firmware (mis. tgroups); tampilkan formulir hanya untuk firmware yang mendukung

Status di server

Kondisi	Status
cfg_ver di laporan sama dengan yang dikirim dan rejected kosong	tersinkron
cfg_ver sama tetapi rejected berisi	ditolak sebagian (tampilkan alasan per key)
cfg_ver berbeda	menunggu

Pesan lain dengan pola yang sama

rules, sources, profiles, dan tgroups memakai pola yang sama: versi dari server (rules_ver, …), mengganti seluruh set, laporan */reported berisi hash (CRC-32 IEEE byte pesan yang berlaku, 8 heksadesimal), bytes, previous_hash, dan rejected. Server menghitung CRC-32 dari byte yang ia kirim (Go: crc32.ChecksumIEEE; Python: zlib.crc32) dan membandingkannya, tanpa mengunduh isinya. Penerapan dengan konfirmasi (confirm_s) dijelaskan di Rules.

Perilaku saat tersambung ulang

Pesan retained diterima lagi setiap node tersambung ulang. Mengirim ulang pesan yang sama tidak mengubah apa pun. Node yang baru di-reset ber-cfg_ver 0, jadi konfigurasi retained diterapkan lagi; untuk benar-benar membersihkan, kosongkan sumbernya (Reset dan pindah rak).