First configuration

This page lays out the work in order. The reference for each key (type, range, default) is in Configuration keys.

Overview

#	Step	How	Done when
1	Check boot and sensors	LCD or USB serial `status`	DS18B20 detected and bound to `t1`
2	Connect to the network	PoE cable; gateway or direct mode	LCD `ONLINE`, green LED
3	Change the web password, set location	web interface	`label` shows on the LCD
4	Set up temperature sensors	`config`	names, labels, and limits are right
5	Set up digital inputs	`config`	each connected input reads correctly
6	Set up power	`config`	PZEM values are plausible
7	Set up alarms	`config`	a test alarm sounds and is sent
8	Final verification	`config/reported`	`cfg_ver` matches and `rejected` is empty

All digital inputs and outputs are off on a new Sentinel; that is normal, you configure them in step 5.

Three ways to send configuration

The content is the same: JSON with keys from the reference.

Route	When
Web interface (Configuration tab)	on-site settings, or fixing a connection that cannot be changed from the server because the node is not connected
USB serial	first time at the bench, or when there is no network yet
Retained message to `…/<mac>/config` (from Celestian, or `celestianctl.py` to the gateway’s local broker)	day-to-day settings from the server

Example with celestianctl.py (gateway local broker; --host = gateway IP):

python3 Tools/celestianctl.py --host 10.10.0.1 config a2cb8ff8768d cfg_ver=1 label=DC-A/R07 tz_offset_min=420

key=value is read as JSON when possible (true, 30000, -0.5), otherwise as text. Names and ROMs that could be read as numbers need JSON quotes: t1_rom='"28a54dca18253061"'.

Rules for consistent configuration

Include cfg_ver and increase it whenever the content changes. It is the only proof on the server that that message was applied.
Rejected keys do not cancel other keys. The node applies the valid ones and reports the rest in rejected.
Changes are stored on the node and survive restart.
From the server, send the whole set of managed keys in one retained message. The broker keeps only one retained message per topic.
Do not copy config/reported verbatim into config: the report contains fields that are not configuration keys (device, model, discovered, rejected, …).
Keys marked reboot in the reference make Sentinel restart about 1 second after being applied.
Do not include tN_rom unless you mean to change the sensor binding: a retained message carrying "t2_rom":"" unbinds it every time the node receives it again.

Verifying

Every time the node receives config and every time it connects to the broker, it sends config/reported (retained):

{
  "cfg_ver": 12,
  "rejected": {"alarm_delay_s": "di luar rentang 0..3600"},
  "fw": "0.21.1", "model": "SNT-G1", "fw_status": "current", "device": "001a2b3c4d5e",
  "telemetry_interval_ms": 10000,
  "t1_rom": "28a54dca18253061",
  "discovered": []
}

Status on the server:

Condition	Meaning
`cfg_ver` equal and `rejected` empty	in sync
`cfg_ver` equal but `rejected` non-empty	partially rejected (see the reason per key)
`cfg_ver` different	pending

rejected holds the result of the last config message only. mqtt_pass is never reported. Rejection reasons are generated by the firmware and are in Indonesian.

Complete example

A location with two temperature sensors, one door, a water-leak sensor that triggers an alarm, and 220 V ±10% power limits:

{
  "cfg_ver": 3,
  "label": "DC-A/R07",
  "t1_name": "rack_top",    "t1_label": "Atas",
  "t2_name": "rack_bottom", "t2_label": "Bawah", "t2_alarm_c": 30,
  "d1_name": "front_door", "d1_type": "door", "d1_label": "Pintu Depan",
  "d1_text_true": "Terbuka", "d1_text_false": "Tertutup", "d1_alarm": true, "d1_alarm_delay_s": 20,
  "d2_name": "leak", "d2_type": "water", "d2_label": "Bocor", "d2_alarm": true, "d2_alarm_delay_s": 0,
  "temp_warn_c": 28, "temp_alarm_c": 32,
  "volt_min_v": 198, "volt_max_v": 242, "current_max_a": 16
}