Config and reports

This page is for integrators who send configuration to Sentinel. The key list is in Configuration keys.

Sending

From where	Publish topic
Celestian / a client on the central side	m/<workspace>/c/<channel>/<mac>/config
A client on the rack LAN (the gateway’s local broker)	sentinel/<mac>/config

Payload	a JSON object; only the keys present are changed, other keys stay
QoS / retain	1 / yes
Empty payload	ignored
Unknown key	not applied; goes into rejected with the reason key tidak dikenal
Wrong type or out of range	that key is not applied, goes into rejected with its reason; other keys in the same message are still applied
Persistence	stored in flash; survives reboot
cfg_ver	an integer 0 … 4294967295 from the server; recorded and reported back. The node does not reject a smaller version

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

Three things to watch for

1. Send only the keys you actually want to set. Connection keys (workspace, channel, mqtt_host, mqtt_port, mqtt_user, mqtt_pass, ntp_server) as well as sht41 and lcd trigger a reboot if their value changes. Do not resend the contents of config/reported verbatim.
2. Send the whole set of managed keys in a single message. The broker keeps only one retained message per topic.
3. Increase cfg_ver whenever the content changes.

Connection keys are not allowed to be changed from Celestian (excluded in Celestian’s catalog); change them through the web or USB serial.

Verifying: config/reported

Every time the node receives config, and every time it connects to the broker, it sends …/<mac>/config/reported (JSON, retained, QoS 1). The report is also resent when a temperature sensor binding changes, without a cfg_ver change.

{
  "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	Meaning
cfg_ver, rejected	the effective version and the rejected keys with reasons. rejected is always present; an empty object = all keys in the last message were accepted. Only the result of the last message
configuration keys	all keys with their effective values. mqtt_pass is never reported; mqtt_ca is represented only by mqtt_ca_set, mqtt_ca_subject, mqtt_ca_sha256, mqtt_ca_not_after, mqtt_ca_expired
discovered	DS18B20 ROMs on the bus that are not yet bound to a slot
fw, model, fw_status, fw_pending_verify, fw_rolled_back	firmware status (Firmware and OTA)
mqtt_endpoint_effective, ntp_server_effective	the MQTT destination and NTP list currently in use
web_pw_default	true while the web password is still the default
features	firmware capabilities (e.g. tgroups); show a form only for firmware that supports it

Status on the server

Condition	Status
cfg_ver in the report equals the one sent and rejected is empty	in sync
cfg_ver equal but rejected non-empty	partially rejected (show the reason per key)
cfg_ver different	pending

Other messages with the same pattern

rules, sources, profiles, and tgroups use the same pattern: a version from the server (rules_ver, …), replacing the whole set, a */reported report containing hash (the CRC-32 IEEE of the effective message bytes, 8 hex), bytes, previous_hash, and rejected. The server computes the CRC-32 from the bytes it sent (Go: crc32.ChecksumIEEE; Python: zlib.crc32) and compares, without downloading the content. Applying with confirmation (confirm_s) is described in Rules.

Behavior on reconnect

Retained messages are received again every time the node reconnects. Resending the same message changes nothing. A freshly reset node has cfg_ver 0, so retained configuration is applied again; to truly clean up, empty the source (Reset and moving racks).