Reset and moving racks

There are two levels of reset.

	`reset_config`	Factory reset
How	`cmd reset_config`, or `reset_config` in serial	touch sequence, `reset_factory` in serial, or the System tab in the web
Configuration and sensor bindings	erased (`cfg_ver` becomes 0)	erased
Rules (and their rollback backup)	erased (unless `keep_rules`)	erased
Connection (`workspace`, `mqtt_*`, `ntp_server`)	kept (unless `connection: true`)	erased
Web password and language	untouched	back to default (`sentinel`, English)
Kept	assembly data (`hw`, `exp_addr`, `lcd_addr`) and the message sequence number `q`	same

`reset_config` (from the server)

Used mainly when a Sentinel is moved to another rack or data center.

{"action":"reset_config","connection":false,"keep_rules":false,"id":"req-9"}

Field	Default	Meaning
`connection`	`false`	`true` = connection keys also return to default. In direct mode the node can no longer connect until re-provisioned over USB
`keep_rules`	`false`	`true` = the rules set stays

The node replies ok with a summary in cmd/result, then reboots about 1 second later. Connected DS18B20 sensors are automatically bound to empty slots after boot (temp_autobind). In USB serial: reset_config or reset_config all (also resets the connection).

Moving a Sentinel to another rack

In Celestian: replace that device’s configuration with the new location’s settings (or empty it), and detach the old rules. Celestian re-sends the last configuration and rules to a node that reports an older cfg_ver, so without this step the old rack’s settings come back.
Send reset_config. Wait for cmd/result and the reboot.
Unplug, move, and plug in at the new rack. IP, broker, and NTP follow the gateway there. Make sure the device is in the channel followed by the new gateway (or move the device in Celestian).
After the DS18B20 is read, check discovered and tN_rom: automatic binding uses ROM order, so slot labels can be swapped. Bind manually if needed.
On the old gateway, clear that node’s retained messages after the node has been down for more than 90 seconds (the “offline” LWT has been sent):

docker compose exec mosquitto sh -c 'mosquitto_sub -t "sentinel/<mac>/#" --retained-only -W 3 -F "%t" | while read t; do mosquitto_pub -t "$t" -r -n; done'

Factory reset

Erases all settings (including connection, sensor bindings, rules) and returns the web password and language to default. Three routes, all local:

Touch sequence (needs no LCD, network, or password; not affected by buttons_locked).
USB serial: reset_factory.
Web: the System tab, requires the password and typing RESET.

The device reports a button = factory_reset event to the server before its connection is erased.

The touch sequence

A 5-step sequence, each 2 seconds. Step 1 is the trigger: touch OK and BACK (only those two) and keep holding for a full 2 seconds. During that time there is no sound or display, and if you let go or another button is touched nothing happens, so a brief accidental touch triggers nothing.

Once satisfied, the buzzer beeps 50 ms (the sequence starts) and steps 2 to 5 run, with a 50 ms beep at the start of each step. The sequence runs unconditionally: it does not stop even if you release the buttons. The combination that must be touched at the end of each step:

Step	Buttons
1 (trigger)	OK + BACK
2	OK + BACK + DOWN
3	OK + BACK
4	OK + BACK + UP
5	OK + BACK + UP + DOWN

The combination must be exact and held for 300 ms before the end of its step (you have ±1.7 seconds to move your fingers). The verdict comes after step 5 (the 10th second from the first touch): a 1-second beep = success (reset then reboot), 3 beeps of 100 ms = failure. The next attempt is only counted after OK and BACK are released and 3 seconds pass. Buttons already touched at boot must be released first. The LCD shows “Reset pabrik, Langkah n/5” only after the trigger is satisfied, not whether a step is right or wrong.