deploy: b80971b85f

cli_command_availability/index.html

@@ -1870,8 +1870,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 </tr>
 <tr>
 <td>Clock sync</td>
-<td><a href="../cli_commands/#estimate-and-correct-repeater-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
-<td>Repeater; <code>clock.sync.internet</code> needs MQTT</td>
+<td><a href="../cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
+<td>Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater</td>
 <td>Yes</td>
 <td>Yes</td>
 <td>Yes</td>
@@ -3309,8 +3309,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 </tr>
 <tr>
 <td>Clock sync</td>
-<td><a href="../cli_commands/#estimate-and-correct-repeater-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
-<td>Repeater; <code>clock.sync.internet</code> needs MQTT</td>
+<td><a href="../cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
+<td>Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater</td>
 <td>Yes</td>
 <td>Yes</td>
 <td>Yes</td>

cli_commands/index.html

@@ -1074,10 +1074,10 @@
 </li>
         
           <li class="md-nav__item">
-  <a href="#estimate-and-correct-repeater-time-after-startup" class="md-nav__link">
+  <a href="#estimate-and-correct-infrastructure-node-time-after-startup" class="md-nav__link">
     <span class="md-ellipsis">
       
-        Estimate and correct repeater time after startup
+        Estimate and correct infrastructure-node time after startup
       
     </span>
   </a>
@@ -3520,10 +3520,10 @@
 </li>
         
           <li class="md-nav__item">
-  <a href="#estimate-and-correct-repeater-time-after-startup" class="md-nav__link">
+  <a href="#estimate-and-correct-infrastructure-node-time-after-startup" class="md-nav__link">
     <span class="md-ellipsis">
       
-        Estimate and correct repeater time after startup
+        Estimate and correct infrastructure-node time after startup
       
     </span>
   </a>
@@ -5383,7 +5383,7 @@ Station G2/G3 targets default to <code>off</code>.</p>
 - The nRF52 hardware cannot stop a watchdog after it has started. Disabling is persisted immediately, then the current firmware stops feeding it so the board performs one watchdog restart within 60 seconds. It remains off after that restart.
 - This setting is nRF52-only. The SoftDevice flash deadlock does not apply to ESP32, whose existing watchdog behavior is unchanged.</p>
 <hr />
-<h4 id="estimate-and-correct-repeater-time-after-startup">Estimate and correct repeater time after startup</h4>
+<h4 id="estimate-and-correct-infrastructure-node-time-after-startup">Estimate and correct infrastructure-node time after startup</h4>
 <p><strong>Usage:</strong>
 - <code>get clock.sync</code>
 - <code>get clock.sync.status</code>
@@ -5401,22 +5401,22 @@ Station G2/G3 targets default to <code>off</code>.</p>
 - <code>get clock.sync.samples</code>
 - <code>set clock.sync.samples &lt;3-16&gt;</code></p>
 <p><strong>Defaults:</strong>
-- <code>clock.sync.mesh</code>: <code>on</code> for nRF52 repeaters; <code>off</code> for other builds
+- <code>clock.sync.mesh</code>: <code>on</code> for all repeater, sensor, and room-server builds
 - <code>clock.sync.mesh.edge</code>: <code>on</code>
 - <code>clock.sync.internet</code>: <code>off</code>
 - <code>clock.sync.drift</code>: <code>3600</code> seconds
 - <code>clock.sync.samples</code>: <code>9</code></p>
-<p>When either source is enabled, the repeater makes its first clock-bootstrap
+<p>When either source is enabled, the node makes its first clock-bootstrap
 attempt after 30 minutes of uptime, or immediately when the configured number
 of fresh evidence sources has been collected, whichever comes first. A
 successful estimate changes the RTC only when the absolute difference is
 <strong>greater than</strong> <code>clock.sync.drift</code>; correction can move the clock forward or
 backward. A valid estimate within the threshold counts as a successful sync
 without changing the clock. Seven days after each successful estimate, the
-repeater evaluates time again; the seven-day deadline therefore starts from the
+node evaluates time again; the seven-day deadline therefore starts from the
 last successful estimate rather than from boot. This is a lazy uptime deadline:
 the check runs on the first normal loop/wake after it becomes due and does not
-wake the device by itself. If no source or consensus is available, the repeater
+wake the device by itself. If no source or consensus is available, the node
 retries every 30 minutes, and newly collected evidence triggers another
 immediate evaluation once the configured source count is present. Every reboot
 starts with the initial bootstrap attempt. An existing saved setting always
@@ -5514,12 +5514,14 @@ one sender can claim multiple names and inflate the edge-mode vote count.</p>
 <p><code>clock.sync.internet</code> is available on WiFi MQTT repeater-observer builds. Its
 initial and seven-day queries run on the MQTT/WiFi task and are read-only until
 the repeater applies the configured drift test. Failed queries retry after 30
-minutes. On other repeater builds, the preference can be stored but status
-reports that internet time is unavailable. MQTT builds retain their existing
-startup NTP behavior required for MQTT/TLS/JWT operation; this setting controls
-the additional delayed drift checks. Startup NTP is always preferred when it
+minutes. On other infrastructure-node builds, the preference can be stored but
+status reports that internet time is unavailable. MQTT builds retain their
+existing startup NTP behavior required for MQTT/TLS/JWT operation; this setting
+controls the additional delayed drift checks. Startup NTP is always preferred when it
 succeeds, regardless of this setting.</p>
-<p>Changing any <code>clock.sync.*</code> setting starts a new attempt for the current boot.
+<p>Sensor and room-server builds support mesh clock consensus and report
+<code>clock.sync.internet</code> as unavailable. Changing any <code>clock.sync.*</code> setting starts
+a new attempt for the current boot.
 Settings are persistent in <code>/clock_sync</code>; samples and schedule state are not.</p>
 <p>A backward correction is intentionally allowed, but peers that already recorded
 a later timestamp from this node may temporarily reject its lower timestamps as

halo_keymind_settings/index.html

@@ -1425,13 +1425,13 @@ set flood.retry.ignore none
 </tr>
 <tr>
 <td><code>clock.sync.mesh</code></td>
-<td>Defaults on for nRF52 repeaters and off for other builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples.</td>
+<td>Defaults on for all repeater, sensor, and room-server builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples.</td>
 <td><code>get clock.sync.mesh</code>, <code>set clock.sync.mesh &lt;on|off&gt;</code>, <code>clock.sync.mesh now</code>, <code>get clock.sync.status[.table|.1-.16]</code></td>
 <td><code>set clock.sync.mesh on</code></td>
 </tr>
 <tr>
 <td><code>clock.sync.mesh.edge</code></td>
-<td>Defaults on so edge repeaters can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so <code>repeat off</code> and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples.</td>
+<td>Defaults on so edge infrastructure nodes can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so disabled forwarding and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples.</td>
 <td><code>get clock.sync.mesh.edge</code>, <code>set clock.sync.mesh.edge &lt;on|off&gt;</code></td>
 <td><code>set clock.sync.mesh.edge on</code></td>
 </tr>