mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-10-29 19:42:23 +00:00
deploy: dfef59331c
This commit is contained in:
mikecarper committed
1 parent
29e494231f
commit
a1498c6c92
3 files changed
+98
-9
No files matched your search
+70
-8
@@ -2880,6 +2880,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#emergency-battery-schedule" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Emergency battery schedule
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -6087,6 +6098,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#emergency-battery-schedule" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Emergency battery schedule
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -10458,8 +10480,8 @@ unsupported.</p>
|
||||
- <code>get battery.alert.critical</code>
|
||||
- <code>set battery.alert.critical <0-99></code></p>
|
||||
<p><strong>Defaults:</strong>
|
||||
- <code>battery.alert.low</code>: <code>20</code>
|
||||
- <code>battery.alert.critical</code>: <code>10</code></p>
|
||||
- <code>battery.alert.low</code>: <code>25</code>
|
||||
- <code>battery.alert.critical</code>: <code>15</code></p>
|
||||
<p><strong>Note:</strong> The low threshold must be greater than the critical threshold. Alerts at or below the critical threshold use <code>CRITICAL BATTERY</code> in the message; both severities use the same 12-hour resend cooldown.</p>
|
||||
<hr />
|
||||
<h4 id="pause-forwarding-when-the-battery-is-low">Pause forwarding when the battery is low</h4>
|
||||
@@ -10479,11 +10501,15 @@ readings remain available.</p>
|
||||
<li><code>set flood.battery <off|on|1-100></code></li>
|
||||
<li><code>get battery.forward</code></li>
|
||||
</ul>
|
||||
<p><code>set repeat.battery on</code> enables the saved repeat threshold, initially <strong>10%</strong>.
|
||||
<code>set flood.battery on</code> enables the saved flood threshold, initially <strong>20%</strong>.
|
||||
<p><code>set repeat.battery on</code> enables the saved repeat threshold, initially <strong>15%</strong>.
|
||||
<code>set flood.battery on</code> enables the saved flood threshold, initially <strong>25%</strong>.
|
||||
A number both enables the control and sets its threshold. <code>off</code> disables it
|
||||
while retaining that threshold for the next <code>on</code>. Changes are saved and take
|
||||
effect without a reboot.</p>
|
||||
<p>An older forwarding record with exactly the former 10% repeat / 20% flood
|
||||
defaults adopts 15% / 25% on upgrade. Its enabled controls and voltage endpoints
|
||||
stay unchanged. Other saved thresholds are retained; newly selected custom
|
||||
10% / 20% settings also remain available.</p>
|
||||
<p>Below the repeat threshold, the node stops LoRa retransmissions of received
|
||||
traffic. Below the flood threshold, it stops LoRa retransmissions of received
|
||||
flood traffic but may still
|
||||
@@ -10495,8 +10521,8 @@ battery recovery does not override a manual restriction.</p>
|
||||
limits. Exporting radio reception to WiFi, ESP-NOW, or RS232 is unchanged.</p>
|
||||
<p>Forwarding resumes automatically after the measured percentage reaches two
|
||||
percentage points above the applicable threshold, capped at 100%. With the
|
||||
initial thresholds, flood forwarding pauses below 20% and resumes at 22%; all
|
||||
relay forwarding pauses below 10% and resumes at 12%. This recovery margin
|
||||
initial thresholds, flood forwarding pauses below 25% and resumes at 27%; all
|
||||
relay forwarding pauses below 15% and resumes at 17%. This recovery margin
|
||||
avoids repeatedly switching forwarding on and off near a threshold.</p>
|
||||
<p>Battery voltage is sampled every 30 seconds while either control is enabled,
|
||||
and immediately when its configuration changes. <code>get battery.forward</code> reports
|
||||
@@ -10510,11 +10536,47 @@ set flood.battery on
|
||||
get battery.forward
|
||||
</code></pre>
|
||||
<p>To choose different thresholds and later disable the feature:</p>
|
||||
<pre><code class="language-text">set repeat.battery 15
|
||||
set flood.battery 25
|
||||
<pre><code class="language-text">set repeat.battery 12
|
||||
set flood.battery 22
|
||||
set repeat.battery off
|
||||
set flood.battery off
|
||||
</code></pre>
|
||||
<h4 id="emergency-battery-schedule">Emergency battery schedule</h4>
|
||||
<p>Supported ESP32 and nRF52 Repeater, Room Server and Sensor images enter the
|
||||
final battery-saving stage at <strong>5% or less</strong>, independently of the optional
|
||||
forwarding gates. Automatic mode returns to normal at <strong>7% or more</strong>. An
|
||||
invalid battery reading cannot activate it, or falsely clear an existing low
|
||||
battery state. Percentage uses the same configured voltage endpoints as
|
||||
<code>battery.forward</code>; it does not prove that a physical battery is connected.</p>
|
||||
<p>In emergency mode, normal work runs during the first <strong>15 minutes of every
|
||||
UTC hour</strong> (<code>:00:00</code> through <code>:14:59</code>). For the remaining 45 minutes the LoRa
|
||||
radio sleeps and normal mesh, sensor and screen work is suspended. The CPU
|
||||
uses timed sleep with brief watchdog, clock, voltage-protection and command
|
||||
maintenance wakes. Active firmware updates and unfinished critical operations
|
||||
defer sleep. Existing hard low-voltage protection remains in force.</p>
|
||||
<pre><code class="language-text">get power.emergency
|
||||
set power.emergency on
|
||||
set power.awake 30
|
||||
set power.awake 0
|
||||
set power.emergency auto
|
||||
</code></pre>
|
||||
<p><code>on</code> saves manual emergency mode, including across reboots. <code>auto</code> restores
|
||||
battery-controlled entry and is the default. The initial transition allows
|
||||
five seconds for its reply. <code>power.awake</code> keeps the node up for the next given
|
||||
number of minutes (0 cancels; maximum 10080), even outside the hourly window.
|
||||
That override is held in RAM and ends on reboot; it never disables hard
|
||||
low-voltage shutdown. Use it before maintenance that needs continuous uptime.
|
||||
LoRa commands must arrive during an awake window. Local USB commands can wait
|
||||
up to one ten-second maintenance interval while the node is sleeping.</p>
|
||||
<p><code>get power.emergency</code> reports the mode, battery estimate, desired <code>window</code>,
|
||||
actual radio ownership, seconds until the next awake window, and remaining
|
||||
hold. With an unset clock it reports <code>clock=uptime</code> and follows the same
|
||||
15/45-minute cycle from boot until a valid UTC clock is available. Queued
|
||||
future traffic does not keep a critically low node awake indefinitely.</p>
|
||||
<p>This schedule uses resumable timed sleep, preserving identity and settings.
|
||||
WiFi/ESP-NOW services are temporarily stopped and their previous live subset
|
||||
is restored when the node wakes. Companion builds and flash-constrained
|
||||
profiles that omit battery-forwarding controls do not add this feature.</p>
|
||||
<h4 id="set-the-battery-percentage-voltage-range">Set the battery percentage voltage range</h4>
|
||||
<p>The forwarding thresholds use a voltage-derived percentage. On infrastructure
|
||||
builds without the nRF52 voltage policy, the saved range is adjustable with:</p>
|
||||
|
||||
@@ -1 +1 @@
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependenLine truncated
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependenLine truncated
|
||||
@@ -2481,6 +2481,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#emergency-battery-schedule" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Emergency battery schedule
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2811,6 +2822,22 @@ A failed/corrupt settings file blocks configuration saves and automatic replay.<
|
||||
measurement or entry into ship mode. Read the corresponding status afterward.</p>
|
||||
<p>See the <a href="../test-results/solarxiao_power_2026-10-21/">bench acceptance report</a>
|
||||
for exact firmware identity, measured readouts and test limits.</p>
|
||||
<h2 id="emergency-battery-schedule">Emergency battery schedule</h2>
|
||||
<p>The <a href="../cli_commands/#emergency-battery-schedule">emergency schedule</a> keeps the
|
||||
radio and normal work awake for the first 15 minutes of each UTC hour, with
|
||||
timed sleep for the remaining 45 minutes. It starts automatically at 5% and
|
||||
recovers at 7%. Forwarding thresholds now default to 25% for floods and 15%
|
||||
for all relayed traffic; those forwarding gates remain opt-in.</p>
|
||||
<pre><code class="language-text">get power.emergency
|
||||
set power.emergency on
|
||||
set power.awake 30
|
||||
set power.emergency auto
|
||||
</code></pre>
|
||||
<p>The percentage follows the configured self battery voltage endpoints used by
|
||||
<code>battery.forward</code>. On MPPT carriers this is the XIAO ADC, not an estimate of
|
||||
the separate carrier battery's charge from INA260/LTC4162. Check the actual
|
||||
voltage source before relying on automatic entry. Manual mode and timed wake
|
||||
work independently of the charger. Hard low-voltage protection still applies.</p>
|
||||
<h2 id="conversion-defaults-and-carrier-revisions">Conversion defaults and carrier revisions</h2>
|
||||
<p>The supplied <a href="https://github.com/wehooper4/Meshtastic-Hardware/blob/main/XaioSeries/SolarXaio/MPPT/Standard/Schematic_SolarXaio_MPPT_2025-10-23.pdf">Standard schematic</a>
|
||||
shows R5/RSNSI and R14/RSNSB at 10 milliohms, a 10 kohm NTC bias and a 10 kohm
|
||||
|
||||
Reference in new issue
Block a user