+ Not documented yet. The v2 topic rebuild (see the V2 tab) fully replaced the legacy topic set — there was no dual-publish + migration period. This tab is reserved for historical reference on the pre-v2 shape and will be filled in later. +
+| {h} | ))}||||
|---|---|---|---|---|
| {row.address} | {row.direction} | +{row.switch ?? '—'} | {row.notes} |
+ Every switch above only takes effect while mqtt.enable (the master connection switch) is on. Read current state with mqtt.get_topics, change it with mqtt.set_topics (Commands tab → mqtt namespace).
+
+ Always optional — a request without req_id gets a reply without one, so v1 clients and any existing caller are unaffected. Implemented bus-wide (not MQTT-only) so a client fanning requests out over one shared channel — multiple devices on one broker — can match replies to requests. No access control yet: any caller can set any req_id today.
+
{row.notes}
+
+ LWT (Last Will and Testament): on an unclean disconnect (crash, power loss, network loss), the broker automatically publishes {'{"device_id":"...","state":"offline","ok":false}'} here (retained), overwriting the last "online" heartbeat. For intentional disconnects (e.g. mqtt.disable), the firmware publishes the same payload explicitly before disconnecting, since LWT doesn't fire on a clean disconnect.
+
+ The opposite of control/command: unsolicited data the board sends because it needs to be read now. Not a reply to anything — never carries req_id. Not retained, since it's an event stream, not a status snapshot. Currently the only event type is bell_overload, published when per-bell strike load exceeds configured thresholds.
+
{row.notes}
+{row.notes}
+{row.notes}
+
+ Note: two other boot counters exist in the firmware for unrelated purposes — firmware.status's boot_count tracks boots since the current OTA slot was flashed (rollback-safety bookkeeping only), and the device also keeps a rotating SD-side history of the last 200 boots with timestamps. boot_count in this payload is the one to use for "how many times has this device rebooted."
+
+ Deliberately separate from the 30s heartbeat — none of these fields need 30-second freshness, and the heartbeat already fires forever, per device, at fleet scale. CPU temperature is sampled locally every 15s and reduced to min/max/avg between reports (so a short thermal spike doesn't get averaged away or missed entirely); the other fields are monotonic or rarely-changing, so a single read at report time loses no information. Moved here from system/info (was diagnostics_report) since it's quantitative telemetry, not a discrete event — and gained bell strike/heat data, matching this topic's explicit "bell heat ratings" purpose.
+
{row.notes}
+
+ Note: short-lived, fire-and-forget FreeRTOS tasks (mqttRecon, mqttHB, mqttConnect, netRecon, and others created without keeping a task handle) cannot appear in stack_high_water — only tasks that keep a stored handle can be queried this way.
+