Network and connection modes
Gateway mode (default)
Section titled “Gateway mode (default)”No setup needed. Sentinel takes an IP from the DC Gateway’s DHCP, then uses that gateway IP as MQTT broker, NTP server, and OTA server. Only the gateway logs in to Celestian. The local topic is sentinel/<mac>/….
Make sure that on the gateway side Mosquitto is running and the bridge to Celestian is configured (Bridge to Celestian).
If the router on the LAN is not the DC Gateway, the gateway IP from DHCP is not the broker. Set the broker address on the node: {"mqtt_host":"<broker address>"}.
Direct mode (no gateway)
Section titled “Direct mode (no gateway)”Sentinel logs in to Celestian’s FluxMQ itself. Send this over USB serial (one line) or the web interface, Configuration tab:
{"workspace":"<workspace>","channel":"<channel>","mqtt_host":"<broker>","mqtt_user":"<device ID>","mqtt_pass":"<device key>"}To return to gateway mode, empty workspace and channel and set mqtt_host to auto. Changing the connection makes Sentinel restart by itself. mqtt_pass never appears in show or in the configuration report.
How to connect to the broker: mqtt_mode
Section titled “How to connect to the broker: mqtt_mode”The Celestian broker has three ports: MQTT 3.1.1 (11883), MQTT 5 (11884), and MQTTS (18883, one port for MQTT 3.1.1 and 5). The gateway broker (Mosquitto) accepts MQTT 3.1.1 and 5 on ports 11883 / 11884, without TLS.
mqtt_mode |
What happens |
|---|---|
auto (default) |
Direct mode: try MQTTS 5 on mqtts_port; after 2 consecutive failures (or 20 seconds without an answer) switch to MQTT 5 without TLS on mqtt_port. When connected through the fallback, the node tries MQTTS again every hour. Local gateway mode goes straight to MQTT 5 without TLS |
mqtt3, mqtt5 |
a single destination, no TLS, no fallback |
mqtts3, mqtts5 |
a single destination with TLS, no fallback |
mqtt_port and mqtts_port are 0 for the default of their type (11883 / 11884, and 18883). config/reported contains mqtt_endpoint_effective (e.g. mqtts5:18883).
TLS and a private CA
Section titled “TLS and a private CA”TLS checks the server certificate, including that the name matches mqtt_host, so mqtt_host must be a name that appears in the certificate, not an IP. Trusted are the public CA bundle (Let’s Encrypt and others), or a private CA if mqtt_ca is filled in.
For a server whose certificate comes from an internal CA, fill mqtt_ca with the CA certificate (a .crt or .pem file; only the certificate is needed, the private key is never required). While set, only that CA is trusted. Three ways: the Configuration tab of the device web interface (pick a file or paste text), a config message, or a single JSON line over USB serial. Clearing it ("") returns to the public bundle.
Certificate validity is checked against the clock, so TLS is only tried after NTP succeeds; auto mode whose clock never becomes correct uses no-TLS after 60 seconds, while mqtts… waits.
NTP and clock
Section titled “NTP and clock”ntp_server = auto picks servers in this order:
- Gateway mode: the broker host (DC Gateway), then the gateway IP from DHCP, then
id.pool.ntp.orgas a last fallback if the LAN may reach the internet. - Direct mode: the broker host (Celestian NTP), then the fallbacks
0.id.pool.ntp.org…3.id.pool.ntp.org.
An explicit value replaces the first two and the pool remains a fallback. The effective list is in ntp_server_effective in the configuration report.
Without a synchronized clock: SenFlat v2 telemetry is marked ts:0 (Celestian stores it with an estimated time and flags it), and maintenance mode is inactive. ts:1 only if NTP succeeded within the last 3 days.
Success indicators
Section titled “Success indicators”| Indicator | Meaning |
|---|---|
Green LED, LCD ONLINE |
Ethernet and MQTT connected |
Yellow LED, NO-MQTT |
Ethernet is up, broker unreachable |
Red LED, NO-LAN |
cable or PoE problem, no IP |
AUTH! |
the broker rejected credentials or client id; retried every 60 seconds |
| Blinking blue LED | identify command |