Using Sentinel in Celestian

Sentinel sends its data to Celestian. This page summarizes what must be prepared on the Celestian side; detailed steps for each menu are in the Celestian documentation.

Order

1. Workspace and channel. Create a workspace and one channel for location data (the route is used in MQTT topics and cannot be changed later).
2. Gateway device. Create a device for the DC Gateway with Gateway mode, save its device key (shown only once), and connect it to the channel with the publish and subscribe types.
3. Fill in the gateway. Enter that ID and key in the gateway (Bridge to Celestian).
4. Sentinel appears in the Roster. Nodes connected to the gateway are registered automatically in the gateway’s Roster tab, recognized by MAC.
5. Register as a device with Serial = MAC (lowercase, no separators).
6. Storage rule. On the channel, add a rule Channel Subscriber → Bypass → Internal DB (SenML); without a rule, messages are received but not stored.
7. Dashboards and alarms. Build dashboards from metrics (rack_top, voltage, …) and Alarm rules in Celestian if you want e-mail or Telegram notifications. Alarms on the node (alarm_*) are still sent as events.

For direct mode (no gateway), the Sentinel device itself is connected to the channel with publish and subscribe types, then its credentials are filled in on the node (Network and connection modes).

Managing configuration from Celestian

The Device Settings menu (device detail) and Settings Templates send a retained config message with an automatically rising cfg_ver, and show the in sync / pending / partially rejected status from config/reported. A few notes:

• Connection keys (workspace, channel, mqtt_*, ntp_server) cannot be changed from Celestian; set them through the web or serial.
• Celestian only accepts keys present in the Sentinel model’s catalog; keys not yet in the catalog are rejected when saving.
• For many similar Sentinels, save the shared settings (without label, hw, tN_rom, maintenance_until, fw_*) as a Settings Template, then apply it to devices with a preview first.
• Celestian re-sends the last configuration and rules to a node that reports an older cfg_ver. Remember this when moving a Sentinel.

An example of creating a template through the API with a Personal Access Token (permission device.configure):

export CELESTIAN=https://<domain>  WS=<workspace>  TOKEN=tpat_<token>
curl -s -X POST "$CELESTIAN/api/v1/workspaces/$WS/device-config-templates" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  --data @sentinel-template.json

# save a device's settings draft then push it to the node
curl -s -X PUT  "$CELESTIAN/api/v1/workspaces/$WS/devices/{id}/device-config" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" --data @sentinel-device-config.json
curl -s -X POST "$CELESTIAN/api/v1/workspaces/$WS/devices/{id}/device-config/push" \
  -H "Authorization: Bearer $TOKEN"

The sample files Tools/konfigurasi/sentinel-device-config.json and sentinel-template.json were exported from firmware 0.6.0; adjust the keys to your firmware version and Celestian catalog.

Rules, sources, and firmware

• On-device rules, Modbus sources, and telemetry groups are sent over their own topics; make sure the gateway bridge forwards them (Bridge to Celestian).
• Staged OTA firmware from Celestian is forwarded through the gateway’s OTA server (OTA on the gateway). After a rollback, the node reports fw_rolled_back and does not install the same version again (Firmware and OTA).

Note

The Celestian documentation covers device, SenFlat payload, and Sentinel dashboard pages from the platform’s point of view. This documentation covers the device and gateway side.