dandri/HaloKeymind
1
0
Fork 0
mirror of https://github.com/mikecarper/MeshCore.git synced 2026-09-17 08:44:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: document role feature switches and audit 1.17.1.5 guidance

Browse Source
This commit is contained in:
mikecarper
2026-09-05 23:01:58 -07:00
parent 2630379365
commit eb4ca56f1b
31 changed files with 2037 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MQTT_IMPLEMENTATION.md
+47 -24
View File
@@ -1,24 +1,31 @@
# MQTT Bridge Implementation for MeshCore
This document describes the MQTT bridge implementation that allows MeshCore repeaters to uplink packet data to multiple MQTT brokers.
This document describes the on-device ESP32 MQTT bridge for observer
infrastructure and MQTT-capable Companions. The text `mqtt.*`, `bridge.*`,
and `logging.output` commands below apply to infrastructure CommonCLI.
Full Companion configures MQTT through WebConfig instead; see
[feature switches by role](docs/role_feature_switches.md). Use the
[USB web console](https://flasher.meshcore.io/console) for ASCII commands.
## Quick Start Guide
### Browser setup (recommended)
Normal ESP32 MQTT repeater-, room-server-, and WiFi-companion builds include an
all-in-one WebConfig portal. The same page is used by non-MQTT ESP32 builds,
where the MQTT tab and wizard step are removed at runtime.
Expanded Full ESP32 observer builds and supported WiFi/Full Companions include
WebConfig. Non-MQTT builds with WebConfig omit its MQTT controls. Some portable
images omit the portal while retaining the compact WiFi firmware uploader;
check the exact artifact capability manifest.
1. Flash an observer build such as `heltec_v4_repeater_observer_mqtt`.
2. On a fresh node with no saved WiFi SSID, join the open
2. Enable the portal with `set webui on` if it is off.
On a fresh node with no saved WiFi SSID, join the open
`MeshCore-Setup-XXXX` access point. The captive page should open
automatically; otherwise browse to <http://192.168.4.1/>.
3. Complete the wizard, review the settings, and choose **Save & Reboot**. The
MQTT bridge remains stopped while the setup AP owns WiFi and starts normally
after the reboot.
4. Verify the connections on the portal's status page or with
`get mqtt.status` from the CLI.
`get mqtt.status` from the infrastructure CLI. Companion users check the portal.
The setup AP stops after 10 minutes with no connected client. WiFi companion
builds enable the WebUI by default. Repeater and room-server builds default it
@@ -50,11 +57,10 @@ stop webconfig
set bridge.enabled on
```
The classic 4 MB ESP32
`LilyGo_TLora_V2_1_1_6_repeater_observer_mqtt_` and
`LilyGo_TLora_V2_1_1_6_room_server_observer_mqtt_` targets omit the browser
portal because the async web-server code does not fit while retaining two app
slots for LoRa OTA. Configure those two builds with the CLI below.
The 1.17.1.5 expanded Full TLora V2.1-1.6 MQTT artifacts include WebConfig,
as verified in their capability manifests. Older/slimmer direct PlatformIO
recipes can omit it; use the infrastructure CLI for those images. A board's
flash size alone does not establish whether the release contains WebConfig.
MQTT WiFi companions use this same wizard instead of the former two-page setup.
The portal remains on the companion's station IP, alongside the companion
@@ -63,12 +69,18 @@ LAN page is intentionally unauthenticated; use a trusted WiFi network.
### CLI setup and fallback
For CLI setup, you need console access over serial (115200 baud) or a repeater
login through the companion app.
The commands in this section are for MQTT-capable Repeater/Room Server
infrastructure. Use the USB web console at 115200 baud or an authenticated
remote login through the Companion app. For Full Companion, use the MQTT
WebConfig cards; these infrastructure MQTT commands are not accepted by its
text terminal.
**1. Flash the observer firmware to your device**
The easiest route is the [MeshCore Observer Flasher](https://observer.gessaman.com/) -- pick
For this fork's 1.17.1.5 USA Cascade images, use the
[firmware picker](docs/firmware_picker.md). The upstream
[MeshCore Observer Flasher](https://observer.gessaman.com/) offers a separate
Observer distribution -- pick
**MQTT Observer Firmware**, select your device, and flash from the browser (Chrome or Edge).
To build it yourself instead, use one of the observer build targets (e.g.
`heltec_v4_repeater_observer_mqtt`) -- see [Build Configuration](#build-configuration).
@@ -280,7 +292,7 @@ pio run -e ThinkNode_M7_room_server_observer_mqtt
**ThinkNode M7 -- WiFi only:** the M7 has an onboard CH390 Ethernet controller,
and `ThinkNode_M7_companion_radio_ethernet` uses it, but the MQTT bridge link
management is bound to the WiFi station API, so observer environments uplink
over WiFi. See `UPSTREAM_BUGS.md` for the Ethernet gap. The board has PSRAM, so
over WiFi. The bridge still uses WiFi even when the Companion image also includes Ethernet. The board has PSRAM, so
these builds get neighbors publication (`WITH_MQTT_NEIGHBORS`) automatically.
**TLora naming:** The env prefix `LilyGo_TLora_V2_1_1_6` is LilyGo's **T-LoRa V2.1-1.6** board (SX1276); PlatformIO selects **`ttgo-lora32-v1`** (TTGO LoRa32 V1.0). **MQTT observer** envs extend a slim base **without** `sensor_base` so they retain dual-app OTA on the 4 MB flash; **all other** `LilyGo_TLora_V2_1_1_6_*` targets still use optional I2C environmental sensors as before. The repeater observer also keeps 256 recent-repeater entries instead of the normal ESP32 default of 2,048. The **`lilygo_tlora_c6`** variant is separate hardware (ESP32-C6).
@@ -289,7 +301,13 @@ these builds get neighbors publication (`WITH_MQTT_NEIGHBORS`) automatically.
### Partition Table Changes - Merged Firmware Required
Some MQTT observer builds use a non-default partition table to accommodate the larger firmware size (MQTT libraries, TLS, cert bundle, etc.). **When a board's partition table changes, you must flash the merged firmware (`*-merged.bin`) the first time** so the new partition layout and bootloader are written together. After that initial flash, standard OTA or non-merged updates will work normally.
The table below describes **base PlatformIO recipes**, not every `build.sh`
release overlay. Option 3 promotes MQTT infrastructure to expanded Full
layouts; inspect that artifact's partition/capability metadata and the installed
layout before updating. To install a changed partition table, flash the
matching `*-merged.bin` over USB. An application-only OTA upload does not
change the partition table. Subsequent OTA updates require an image that fits
the installed application slots and satisfies the updater's compatibility checks.
| Environment | Partition Table | Flash Size | App Slot Size | Notes |
|-------------|----------------|------------|---------------|-------|
@@ -304,14 +322,16 @@ Some MQTT observer builds use a non-default partition table to accommodate the l
| `LilyGo_TBeam_1W_repeater_observer_mqtt` | `default_16MB.csv` | 16 MB | 6.25 MB | Set in `boards/t_beam_1w.json`; required vs implicit `default.csv` |
| `LilyGo_TBeam_1W_room_server_observer_mqtt` | `default_16MB.csv` | 16 MB | 6.25 MB | same |
Boards absent from this table need no special first flash: their observer envs use the
same partition table as the board's other firmwares.
A board absent from the base-recipe table can still need a layout migration
when installing an expanded Full release image. A merged flash writes the
bootloader and partition table, but it does **not inherently erase NVS**.
An erase operation, relocated/resized storage, or incompatible filesystem
layout can lose settings; unchanged storage can retain them. Back up identity
and configuration before a layout migration and check them afterward.
Flashing a **full merged image** (`*-merged.bin` at offset `0x0`) writes a new bootloader **and** partition table. If that layout **differs** from what is already on the device, **NVS is typically wiped or invalidated** - expect to lose stored configuration (admin preferences, WiFi, MQTT slots, name, etc.) and reconfigure from scratch.
- **`LilyGo_TLora_V2_1_1_6_repeater_observer_mqtt_`:** This uses the custom `dual_ota_1984k.csv` layout. Install its merged image when coming from a standard TLora build, the room-server observer, or any older `huge_app.csv` build; expect to reconfigure after that partition change.
- **`LilyGo_TLora_V2_1_1_6_room_server_observer_mqtt_`:** This retains the normal `min_spiffs.csv` layout. Moving from another `min_spiffs` TLora build does not itself require a partition change, but coming from the repeater observer's custom layout, `huge_app.csv`, or a non-MeshCore layout does.
- **`Station_G2_*_observer_mqtt`** and **`LilyGo_TBeam_1W_*_observer_mqtt`**: These use `default_16MB.csv` to accommodate the larger size of the MQTT observer firmware. Installing MQTT observer firmware on these devices requires a **merged** flash the first time. The same applies if you move **from** firmware built with a **different** partition table: the first merged flash that installs this layout will **wipe** stored settings.
For example, the base TLora repeater observer uses `dual_ota_1984k.csv` while
its room-server sibling uses `min_spiffs.csv`. Compare those with the actual
release layout rather than assuming a filename or role change is compatible.
**How to flash the merged firmware:**
@@ -327,7 +347,10 @@ You can flash the merged firmware using either the web flasher or the command li
esptool.py write_flash 0x0 .pio/build/LilyGo_T3S3_sx1262_repeater_observer_mqtt/firmware-merged.bin
```
> **Note:** If the **partition layout is unchanged** (e.g. updating the MQTT observer build in place), device configuration in NVS is usually retained; Bluetooth pairings may still be cleared on some upgrade paths. If the **partition table is new to the device**, see **NVS / settings when the partition layout changes** above - stored settings are typically lost. After the first merged flash **for a given layout**, subsequent updates on that board can use OTA or the standard non-merged binary when applicable.
When the installed partition layout is unchanged, normal application updates
usually retain preferences. Full Companion and infrastructure can use different
layouts on the same board; follow the exact image's installation directions.
### Build Flags
- `WITH_MQTT_BRIDGE=1` - Enable MQTT bridge (required)
- `WITH_SNMP=1` - Enable SNMP agent (optional, see [MQTT_SNMP.md](MQTT_SNMP.md))
MQTT_INTERNALS.md
+5 -3
View File
@@ -195,9 +195,11 @@ it loses is the settings the newer build added.
That asymmetry is the whole point. Refusing the file costs the operator the network
itself -- `/mqtt_prefs` holds `wifi_ssid`/`wifi_password` as well as the broker config,
so a node that falls back to defaults has no WiFi, no portal, and no OTA, recoverable
only over serial. Reading it costs a feature's settings. Losing later settings is the
acceptable half of that trade; losing the node is not.
so falling back to defaults loses the saved station connection and broker
configuration. A compiled setup AP or on-demand OTA service may still provide
local recovery; LoRa OTA availability is separate. A remotely deployed node
can nevertheless become unreachable through its former WiFi management path.
Reading the compatible prefix preserves that path at the cost of later settings.
The tail survives until something actually writes. `saveMQTTPrefs()` rewrites at this
binary's own length, so a rollback that changes no observer setting and is later rolled
MQTT_SNMP.md
+22 -11
View File
@@ -1,5 +1,9 @@
# SNMP Agent for MeshCore Observer Firmware
These are infrastructure CommonCLI commands, not Full Companion MQTT controls.
See [feature switches by role](docs/role_feature_switches.md) and the
[USB web console](https://flasher.meshcore.io/console).
This document describes the optional SNMP v2c agent that allows network monitoring tools to poll MeshCore observer nodes for health and performance metrics.
## Overview
@@ -112,27 +116,34 @@ The agent starts automatically once WiFi connects and `snmp_enabled = 1` in pref
## Build Configuration
SNMP is enabled at compile time with the `WITH_SNMP=1` build flag. It is
currently included in these observer firmware targets:
included in these base observer environments (resolved for 1.17.1.5):
- `Heltec_v3_repeater_observer_mqtt`
- `Heltec_v3_room_server_observer_mqtt`
- `Heltec_WSL3_repeater_observer_mqtt`
- `Heltec_WSL3_room_server_observer_mqtt`
- `heltec_v4_repeater_observer_mqtt`
- `heltec_v4_room_server_observer_mqtt`
- `heltec_v4_expansionkit_repeater_observer_mqtt`
- `heltec_v4_expansionkit_room_server_observer_mqtt`
- `Heltec_v3_repeater_observer_mqtt`
- `Heltec_v3_repeater_observer_mqtt_sim` (simulation environment)
- `Heltec_v3_room_server_observer_mqtt`
- `RAK_3112_repeater_observer_mqtt`
- `RAK_3112_room_server_observer_mqtt`
- `Station_G2_repeater_observer_mqtt`
- `Station_G2_room_server_observer_mqtt`
- `Station_G3_ESP32_repeater_observer_mqtt`
- `Station_G3_ESP32_room_server_observer_mqtt`
- `RAK_3112_repeater_observer_mqtt`
- `RAK_3112_room_server_observer_mqtt`
- `ThinkNode_M7_repeater_observer_mqtt`
- `ThinkNode_M7_room_server_observer_mqtt`
- `heltec_v4_expansionkit_repeater_observer_mqtt`
- `heltec_v4_expansionkit_room_server_observer_mqtt`
- `heltec_v4_r8_repeater_observer_mqtt`
- `heltec_v4_r8_room_server_observer_mqtt`
- `heltec_v4_r8_tft_portrait_repeater_observer_mqtt`
- `heltec_v4_r8_tft_portrait_room_server_observer_mqtt`
- `heltec_v4_r8_tft_repeater_observer_mqtt`
- `heltec_v4_r8_tft_room_server_observer_mqtt`
- `heltec_v4_repeater_observer_mqtt`
- `heltec_v4_room_server_observer_mqtt`
The build flag in each variant's `platformio.ini` is authoritative; update this
list whenever SNMP is added to or removed from an environment.
The resolved build flags, including inherited sections and release overlays,
are authoritative. Update this list when environments change.
To add SNMP to another observer variant, add the following to its `platformio.ini`:
README.md
+6 -1
View File
@@ -1,5 +1,10 @@
## About MeshCore
For **1.17.1.5 USA Cascade**, start with the [release guide](docs/releases/1.17.1.5.md),
[firmware picker](docs/firmware_picker.md), and [feature switches by role](docs/role_feature_switches.md).
Use the [USB web console](https://flasher.meshcore.io/console) for the default
ASCII terminal on Full Companion, Repeater, Room Server, and Sensor images.
MeshCore is a lightweight, portable C++ library that enables multi-hop packet routing for embedded projects using LoRa and other packet radios. It is designed for developers who want to create resilient, decentralized communication networks that work without the internet.
## [SEARCH] What is MeshCore?
@@ -7,7 +12,7 @@ MeshCore is a lightweight, portable C++ library that enables multi-hop packet ro
MeshCore now supports a range of LoRa devices, allowing for easy flashing without the need to compile firmware manually. Users can flash a pre-built binary using tools like Adafruit ESPTool and interact with the network through a serial console.
MeshCore provides the ability to create wireless mesh networks, similar to Meshtastic and Reticulum but with a focus on lightweight multi-hop packet routing for embedded projects. Unlike Meshtastic, which is tailored for casual LoRa communication, or Reticulum, which offers advanced networking, MeshCore balances simplicity with scalability, making it ideal for custom embedded solutions, where devices (nodes) can communicate over long distances by relaying messages through intermediate nodes. This is especially useful in off-grid, emergency, or tactical situations where traditional communication infrastructure is unavailable.
> **WiFi and MQTT** - Prebuilt observer firmware, release notes, and browser-based
> **Upstream Observer WiFi and MQTT** - Observer firmware, release notes, and browser-based
> flashing are available at [observer.gessaman.com](https://observer.gessaman.com/).
> See [WiFi and MQTT by Firmware Type](./docs/WiFi.md) for the
> role/build matrix and setup overview. For the complete MQTT command and
RELEASE.md
+22 -12
View File
@@ -2,19 +2,29 @@
For the USA Cascade 1.17.1.5 matrix, use
[the option 3 release instructions](docs/releases/1.17.1.5.md).
The [Full Companion feature guide](docs/full_companion_features.md) is intended
to accompany the release assets.
Package the qualified outputs with `scripts/package_cascade_release.py`.
Local staging does not publish or push anything. Include the
[feature switches by role](docs/role_feature_switches.md),
[Full Companion guide](docs/full_companion_features.md), and
[USB web console](https://flasher.meshcore.io/console) in each role's notes.
The five 1.17.1.5 pages are development prereleases.
GitHub Actions is set up to automatically build and release firmware.
## Legacy tag-triggered GitHub Actions
It will automatically build firmware when one of the following tag formats are pushed.
The repository also has older workflows matching `companion-*`, `repeater-*`,
and `room-server-*` tags (for example `repeater-v1.0.0`). They invoke the shared
`firmware-builder.yml`, build their own target set, and request a draft release.
They are separate from the qualified option 3 matrix and local release staging.
- `companion-v1.0.0`
- `repeater-v1.0.0`
- `room-server-v1.0.0`
**The broad `repeater-*` trigger also matches `repeater-room-*` Cascade tags.**
For 1.17.1.5 this workflow added its own artifacts and changed the title of the
already-published Repeater/Room Server page. Do not assume a published Cascade
page is untouched while that workflow is running. Check workflow completion,
release title/body, and the final asset inventory after publication. Preserve
existing assets when making a documentation-only release edit.
> NOTE: replace `v1.0.0` with the version you want to release as.
- You can push one, or more tags on the same commit, and they will all build separately.
- Once the firmware has been built, a new (draft) GitHub Release will be created.
- You will need to update the release notes, and publish it.
Use role-specific introductions for Companion, Repeater/Room Server, Sensor,
LoRa OTA Repeater, and expanded Full infrastructure pages. Link the exact
board/storage [OTAFIX 2.4.6 release](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
where nRF52 bootloader requirements apply. Later documentation commits can be
linked from release notes without moving the firmware tag or rebuilding assets.
WEB_CONFIG_REVIEW.md
+1 -1
View File
@@ -2,7 +2,7 @@
> **Historical review (2026-07-18).** This file preserves the findings against
> the commits named below; its line numbers and present-tense statements are not
> a current audit of the 2026-08-18 tree. Consult [docs/WiFi.md](docs/WiFi.md),
> an audit of the current tree. Consult [docs/WiFi.md](docs/WiFi.md),
> [MQTT_IMPLEMENTATION.md](MQTT_IMPLEMENTATION.md), and
> [test/README.md](test/README.md) for current operation and test coverage.
> Findings are left in their original form unless a resolution is explicitly
docs/WiFi.md
+23 -16
View File
@@ -12,9 +12,11 @@ purposes:
- ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection
to a WiFi access point.
The firmware role and the build profile are separate choices. For example, a
logging repeater is not an MQTT observer, and a WiFi companion does not publish
to MQTT unless its target name also contains `mqtt`.
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 `mqtt` in their filename; check the artifact capability manifest.
See [feature switches by role](role_feature_switches.md) for the different
Companion and infrastructure controls and the USB web console.
## Quick reference
@@ -26,7 +28,8 @@ to MQTT unless its target name also contains `mqtt`.
| `*_room_server_observer_mqtt` | Yes | Yes | Runs the room server and uplinks radio traffic |
| `*_companion_radio_wifi` | Yes | No | Exposes the MeshCore companion protocol on TCP port 5000 |
| `*_companion_radio_wifi_mqtt` | Yes | Yes | Runs both the TCP companion interface and the MQTT uplink |
| USB, BLE, or serial companion | No | No | Uses the transport named by the target instead |
| `*_companion_radio_full*` | 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 |
| `*_repeater_bridge_espnow` | Build-dependent on ESP32 | No | Uses ESP-NOW for its bridge; `bridge.format wrapped|raw` 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 |
@@ -58,7 +61,7 @@ flood filters and forwarding decision. A packet may therefore be observed on
MQTT even when a later scope, path, region, duplicate, or repeat rule prevents
the node from forwarding it over LoRa.
MQTT publication and LoRa repetition are separate:
On infrastructure observer builds, MQTT publication and LoRa repetition are separate:
- `set repeat on|off` controls whether an observer repeats eligible LoRa
packets;
@@ -421,8 +424,11 @@ The companion owns WiFi connection and recovery in this build. The MQTT bridge
waits for that connection rather than creating a second one. Stopping MQTT does
not disable the TCP companion service.
The same WebConfig page contains the MQTT settings. MQTT companions have no
text admin CLI, so browser configuration is the normal setup method.
MQTT-capable Full Companions also combine these services. The WebConfig page
contains MQTT settings; Full Companion has a USB/TCP text terminal, but does
not expose the infrastructure `mqtt.*`, `bridge.enabled`, or `logging.output`
commands there. Select `none` for every broker slot and save to disable MQTT;
restore the desired presets/settings and save to enable it.
## WebConfig without MQTT
@@ -530,18 +536,18 @@ meaning can change when the service reorders or adds presets.
| MQTT | Builds explicit MQTT observer or WiFi-companion-MQTT targets with USB packet logging off. Non-companion ESP32 MQTT observers always use FULL expanded partitions. |
| FULL ESP32 USB + WiFi | Uses the board's MQTT target with USB packet logging and direct WiFi MQTT together, expanded dual-OTA partitions, up to 254 neighbors, LoRa OTA, and full-size ESP32 features such as WebConfig where supported. `get/set logging.output off\|usb\|wifi\|both` persists the active paths. Classic T-Beam MQTT observers retain their 50-entry table because their persistent discovery state exhausts internal DRAM at 254. |
| FULL ESP32 logging fallback | Uses the board's non-MQTT target only when no matching WiFi MQTT environment exists. It keeps debug and packet logging, expanded dual-OTA partitions, up to 254 neighbors, and LoRa OTA. Persistent `usb.logging off` also provides normal output-off operation, so ESP-NOW FULL roles need no second non-logging image. |
| LoRa-OTA no-external-sensors | A lean repeater image with no MQTT; ESP32 builds retain the compact on-demand browser WiFi uploader and 254 neighbors. |
| LoRa-OTA no-external-sensors | A lean repeater image with no MQTT; ESP32 builds retain the compact on-demand browser WiFi uploader and up to 254 neighbors, subject to target RAM limits. |
All repeater profiles use the full 254-entry neighbor table, including standard,
logging, bridge, and LoRa-OTA builds on every supported platform. The classic
T-Beam SX1262 and SX1276 MQTT observer repeaters retain 50 entries because their
persistent MQTT discovery state leaves insufficient internal-DRAM margin at 254.
Repeater profiles use up to 254 neighbors. Selected Generic E22, Heltec V2,
Meshadventurer, T-Beam OTA/MQTT, and TLora MQTT profiles use 50 to preserve
internal-DRAM reserves. Consult the artifact capability manifest and
[ESP32 memory budget](esp32_memory_budget.md) for the exact target.
The interactive Option 1 **FULL everything** choice and the standalone FULL
command select the unified USB + WiFi image when a matching MQTT target exists;
otherwise they select the logging fallback. The build matrix no longer emits
any separate standard logging image, or a non-MQTT FULL twin for a role covered
by the unified image. All FULL profiles include LoRa OTA, WebConfig where supported,
by the unified image. Expanded Full infrastructure profiles include LoRa OTA, WebConfig where supported,
up to 254 neighbors, and expanded dual-OTA partitions. Target-specific
internal-DRAM limits still apply.
@@ -601,8 +607,8 @@ Check the complete firmware filename and role. In particular:
- `logging` does not mean MQTT;
- `ota` does not mean MQTT;
- `companion_radio_wifi` does not mean MQTT;
- the filename must contain `observer_mqtt` or `wifi_mqtt` for the corresponding
on-device MQTT feature.
- `observer_mqtt` and `wifi_mqtt` identify explicit MQTT targets, but Full
Companion can include MQTT without either marker; inspect its capabilities.
Rolling firmware back does not restore settings erased by a full flash or a
partition-table change. If the correct MQTT target still has no configuration,
@@ -638,4 +644,5 @@ setup AP. Full Companion targets whose primary mesh radio is ESP-NOW use
b/g/n+LR instead and keep the setup AP, infrastructure station, and mesh on the
persisted `espnow.channel` (channel 1 by default). Their configured 2.4 GHz
router and every other primary ESP-NOW node must use that same channel.
MQTT diagnostics apply only to a `wifi_mqtt` companion target.
On MQTT-capable Companions, inspect MQTT status in WebConfig; the infrastructure
MQTT text diagnostic commands above are not Companion terminal commands.
docs/cli_build_matrix.md
+5 -4
View File
@@ -58,9 +58,10 @@ A command belonging to a different role is not considered a profile cut. For
example, adding FULL features to a sensor does not turn it into a repeater
administrator.
Repeater profiles use 254 neighbor entries across supported platforms. The
classic T-Beam SX1262 and SX1276 MQTT observer repeaters are the exception and
retain 50 because their MQTT discovery tables are constrained by internal DRAM.
Repeater profiles use up to 254 neighbor entries. Measured internal-DRAM
limits reduce selected Generic E22, Heltec V2, Meshadventurer, T-Beam OTA/MQTT,
and TLora MQTT profiles to 50. Check the artifact capability manifest and
[ESP32 memory budget](esp32_memory_budget.md) for the exact target.
## Profile matrix
@@ -68,7 +69,7 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.
|---|---|
| Standard non-MQTT repeater or room server | Keeps the normal role CLI and, where USB is a safe plaintext console, embeds debug/packet logging behind persistent `get/set usb.logging`. The explicitly selected portable policy can omit WebConfig and browser WiFi OTA, so those commands are unavailable and the omission is recorded in the capability manifest. |
| Legacy standard logging | No longer emitted separately. Its behavior is compiled into the ordinary artifact. Size-constrained STM32 targets embed packet logging without verbose `MESH_DEBUG`. |
| LoRa-OTA (`-ota-`) | LoRa OTA adds the `ota ...` commands; it does not otherwise reduce the role CLI. ESP32 `no_external_sensors` artifacts retain the compact browser WiFi uploader, the complete CLI, and a 254-entry neighbor table. |
| LoRa-OTA (`-ota-`) | LoRa OTA adds the `ota ...` commands; it does not otherwise reduce the role CLI. ESP32 `no_external_sensors` artifacts retain the compact browser WiFi uploader, the complete CLI, and up to 254 neighbors, subject to recorded internal-DRAM reductions. |
| Internal-flash nRF52 repeater auto pair | `full-ota` retains the board's external-sensor drivers; `reduced-ota` omits the declared optional sensors to leave additional internal-flash staging room. RAK3401 and RAK4631 reduced builds retain INA219, INA226, INA260, and INA3221 I2C voltage/current monitors at a measured cost below 5 KiB. Both artifacts carry the same stable OTA target identity and are checked for `ota ...` and `retry.preset`; RAK artifacts also verify the retained monitor drivers. |
| ESP32 MQTT observer or ESP-NOW bridge | Always uses the expanded FULL partition profile. The build never substitutes a reduced CLI to fit the legacy application slot. |
| FULL ESP32 USB + WiFi | Uses the matching MQTT target with packet logging on, verbose debug off, and the complete command surface supported by that role and hardware. `get/set logging.output off\|usb\|wifi\|both` selects and persists the active output paths. |
docs/cli_command_availability.md
+3 -1
View File
@@ -5,7 +5,9 @@ This page is the command-by-command companion to
links to its detailed documentation.
The tables cover the text administration CLI used by repeater, room-server,
sensor, and bridge firmware. Companion firmware uses the companion protocol,
sensor, and bridge firmware. Full Companion also has its own ASCII USB/TCP
terminal; see [feature switches by role](role_feature_switches.md). Companion
apps use the companion protocol,
KISS firmware uses framed KISS/TNC commands, and terminal-chat firmware has its
own interface, so those build roles are not represented here.
docs/cli_commands.md
+20 -5
View File
@@ -1,10 +1,15 @@
# CLI Commands
For copy/paste on/off recipes and the differences from Full Companion, see
[feature switches by role](role_feature_switches.md). The
[USB web console](https://flasher.meshcore.io/console) opens the default ASCII
terminal at 115200 baud; it does not require on-device WebConfig or WiFi.
This document provides an overview of CLI commands that can be sent to MeshCore Repeaters, Room Servers and Sensors.
See [CLI Availability by Firmware Build](cli_build_matrix.md) for the role and
profile matrix, including the commands intentionally omitted from portable
firmware.
profile matrix. Commands depend on compiled features; some portable builds
omit WebConfig while retaining the complete role CLI and compact WiFi updater.
See [CLI Command Availability Matrix](cli_command_availability.md) for the
command-by-command nRF52 and ESP32 build tables.
@@ -156,7 +161,10 @@ See [LoRa CLI host service](host_cli_service.md) for the complete
- `start ota ap`
- `stop ota`
`start ota` serves the web upload page on the station IP when connected to WiFi;
On nRF52, `start ota` invokes Bluetooth DFU with the matching bootloader and
application DFU ZIP. The WiFi/AP instructions below apply to ESP32.
On ESP32, `start ota` serves the web upload page on the station IP when connected to WiFi;
otherwise it raises the `MeshCore-OTA` access point. `start ota ap` always raises
the access point, which is useful when the normal network uses client isolation.
@@ -1496,7 +1504,12 @@ get clock.sync.status
**Default:** `on` for fresh Cascade-profile builds and Companion firmware; `off` for other infrastructure profiles
**Note:** Infrastructure firmware enters sleep between radio transmissions. It refuses to enable power saving from the local serial console or while an active USB serial data connection is detected; USB power alone does not block power saving.
**Note:** Infrastructure sleep depends on the board implementation. The bare
`powersaving on` command rejects local serial requests or an active USB data
connection on nRF52 and standalone ESP32; ESP32 bridge builds reject that bare
enable command. USB power alone does not block a remote enable request.
The separate `set powersaving on` form saves/applies the preference without
those guards; it is also the form used by infrastructure WebConfig.
Companion firmware defaults this setting to `on`. Full Companion accepts the command from its local USB terminal and exposes the same setting in WebConfig. On ESP32, it lowers the CPU clock to 80 MHz, enables idle yielding, and enables the configured GPS duty cycle. USB and each active wireless transport remain available; SenseCAP Indicator Full keeps only its selected BLE or infrastructure-WiFi secondary transport active. `powersaving off` restores the board's normal CPU clock and disables the GPS duty cycle. This device setting is separate from LoRa RXPS (`radio.rxps`) and WiFi modem power save (`wifi.powersave`). Infrastructure WebConfig uses the `set powersaving` form; enabling it can put the node to sleep and make WiFi temporarily unavailable.
@@ -3672,7 +3685,9 @@ Requires WiFi connected and the MQTT bridge running.
- `set bridge.baud <rate>`
**Parameters:**
- `rate`: Baud rate (`9600`, `19200`, `38400`, `57600`, or `115200`)
- `rate`: Integer baud rate from `9600` through the board's compiled
`BRIDGE_MAX_BAUD` (commonly `500000`); for example `115200`. Stop the bridge
with `set bridge.enabled off` before changing it, then enable it again.
**Default:** `115200`
docs/companion_radio_full.md
+4
View File
@@ -1,5 +1,9 @@
# Full Companion
For runtime on/off commands and board exceptions, see
[feature switches by role](role_feature_switches.md). Open the
[USB web console](https://flasher.meshcore.io/console) for the default ASCII terminal.
For practical on/off commands and update directions, see
[Full Companion feature switches](full_companion_features.md).
docs/faq.md
+7
View File
@@ -1,5 +1,12 @@
# Frequently Asked Questions
For this fork's **1.17.1.5 USA Cascade** release, start with
[feature switches by role](role_feature_switches.md) and the
[USB web console](https://flasher.meshcore.io/console). For nRF52 OTAFIX use
the exact board/storage build from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6);
older bootloader links below provide upstream/background context.
A list of frequently-asked questions and answers for MeshCore
- [Frequently Asked Questions](#frequently-asked-questions)
docs/firmware_picker.md
+6 -1
View File
@@ -1,5 +1,10 @@
# Firmware picker
After selecting an image, use [feature switches by role](role_feature_switches.md)
to turn MQTT, logging, power saving, and other former variant settings on/off.
The [USB web console](https://flasher.meshcore.io/console) works with the
default ASCII terminal on Full Companion and infrastructure roles.
Pick the choices in any order. Every selection narrows all the other controls
to firmware combinations that were actually built in the current release set.
@@ -250,7 +255,7 @@ update package.
nRF52 LoRa OTA requires an OTAFIX bootloader built for the exact board. There
is no universal bootloader file. Use the
[latest stable OTAFIX release](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/latest)
[OTAFIX 2.4.6 for this release](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
and select the hardware-matched HEX, Serial DFU ZIP, or bootloader-update UF2.
## Hardware and variant names
docs/full_companion_features.md
+10 -3
View File
@@ -1,5 +1,9 @@
# Full Companion: turn features on and off
For side-by-side Companion and infrastructure commands, see
[feature switches by role](role_feature_switches.md). MQTT and logging controls
differ between these roles.
Use the exact `companion_radio_full` image for your board. Full includes its
supported transports and MOTA sending in one firmware; ordinary settings do
not require rebuilding it. USB remains the normal way to update the Companion
@@ -9,7 +13,8 @@ MOTA packages on itself.
## Open the text terminal
Close the app or serial monitor using the USB port, then open a terminal at
115200 baud. A fresh boot starts in text mode. If it is already in Binary
115200 baud, or use the [USB web console](https://flasher.meshcore.io/console).
A fresh Full Companion boot starts in ASCII text mode. If it is already in Binary
Companion mode, send this line once and wait for the terminal banner:
```text
@@ -92,7 +97,9 @@ and configure a broker slot to enable it; choose the `none` preset for every
slot to disable broker connections. The MQTT status, packets, raw, receive,
and transmit switches control their individual functions. Save the settings
and follow any reboot instruction shown. Builds without MQTT omit these
controls. There is no need for a separate logging or WiFi-MQTT Companion
controls. Full Companion does not accept infrastructure text commands such as
`set bridge.enabled`, `set logging.output`, or `set mqtt1.preset`; use these
WebConfig controls for MQTT. There is no need for a separate logging or WiFi-MQTT Companion
image when that feature is included in Full.
## Send MOTA from any Full Companion
@@ -115,7 +122,7 @@ This works on both ESP32 and nRF52 Full. Close the text terminal first.
`motatool` automatically sends `ota folder on` and owns USB while serving.
Stop the host tool to detach the source; use `normalradio` afterward to
return early, or let the window expire. A `.bin`, `.uf2`, or DFU `.zip` is
not itself a `.mota`; use [motatool](../tools/mota/README.md) to prepare the
not itself a `.mota`; use [motatool](https://github.com/mikecarper/MeshCore/blob/keymindCascade/tools/mota/README.md) to prepare the
package for the exact destination firmware and hardware.
ESP32 also accepts a host over WiFi:
docs/full_companion_usb_switcher.md
+3 -3
View File
@@ -254,6 +254,6 @@ such as `get radio.cad`. If binary bytes appear, send the exact terminal start
token or reboot.
The switch policy is implemented in
[`UsbAsciiBinarySwitch.h`](../src/helpers/UsbAsciiBinarySwitch.h), with stream
ownership in [`main.cpp`](../examples/companion_radio/main.cpp) and framing in
[`ArduinoSerialInterface.cpp`](../src/helpers/ArduinoSerialInterface.cpp).
[`UsbAsciiBinarySwitch.h`](https://github.com/mikecarper/MeshCore/blob/keymindCascade/src/helpers/UsbAsciiBinarySwitch.h), with stream
ownership in [`main.cpp`](https://github.com/mikecarper/MeshCore/blob/keymindCascade/examples/companion_radio/main.cpp) and framing in
[`ArduinoSerialInterface.cpp`](https://github.com/mikecarper/MeshCore/blob/keymindCascade/src/helpers/ArduinoSerialInterface.cpp).
docs/halo_keymind_settings.md
+4 -1
View File
@@ -1,7 +1,10 @@
# Halo and Keymind Branch Settings
This file covers only CLI settings and helper commands added by the Halo or
Keymind branches. Use `docs/cli_commands.md` for the general MeshCore CLI.
Keymind branches. Use [CLI commands](cli_commands.md) for the general infrastructure CLI.
For MQTT, logging, and former variant controls, use
[feature switches by role](role_feature_switches.md); Full Companion uses
different controls for some of these settings.
See [Repeater Flood Filtering and Moderation](flood_filtering.md) for a focused
filter setup and troubleshooting guide.
docs/hardware_validation_checklist.md
+5
View File
@@ -1,5 +1,10 @@
# Hardware validation checklist
This file records dated hardware observations and open validation tasks.
Historical defaults, versions, and test frequencies below describe the tested
revision, not necessarily the current release. For current ASCII USB defaults
and runtime switches, use [feature switches by role](role_feature_switches.md).
Use this checklist for release-candidate hardware runs. A check is complete only
when its log identifies the physical device, firmware artifact, artifact hash,
command result, and cold/warm boot outcome. Do not infer success from a tool's
docs/index.md
+6 -1
View File
@@ -4,6 +4,11 @@ Welcome to the MeshCore documentation.
Below are a few quick start guides.
- [1.17.1.5 Markdown audit](./releases/1.17.1.5-doc-audit.md)
- [1.17.1.5 USA Cascade release](./releases/1.17.1.5.md)
- [Feature switches by role: Companion, Repeater, Room Server, Sensor](./role_feature_switches.md)
- [USB web console](https://flasher.meshcore.io/console)
- [Full Companion feature switches](./full_companion_features.md)
- [Frequently Asked Questions](./faq.md)
- [Firmware Picker](./firmware_picker.md)
- [CLI Commands](./cli_commands.md)
@@ -27,4 +32,4 @@ Below are a few quick start guides.
If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.
- [Documentation Source](https://github.com/meshcore-dev/MeshCore/tree/main/docs)
- [Documentation Source](https://github.com/mikecarper/MeshCore/tree/keymindCascade/docs)
docs/lora_ota_automation.md
+9
View File
@@ -1,5 +1,14 @@
# Scripted LoRa OTA from start to finish
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
The dedicated [RAK3401 chain report](rak3401_mota_chain.md) records the
physical failures of withdrawn migrations and the physically qualified compact
nine-step replacement. Its runner blocks the withdrawn chains and pins every
docs/ota_easy.md
+16 -6
View File
@@ -1,5 +1,14 @@
# Easy firmware updates over LoRa
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
This guide shows the shortest manual path for sending firmware from a computer to a MeshCore node over
LoRa. Choose the package type for the **destination** node:
@@ -28,7 +37,7 @@ locally over USB/BLE DFU or SWD first; there is no raw-card compatibility handof
| Setting | Value |
| --- | --- |
| Center frequency | 909.950 MHz |
| Center frequency | 910.525 MHz |
| Bandwidth | 250 kHz |
| Spreading factor | SF5 |
| Coding rate used in this guide | CR5 |
@@ -37,7 +46,7 @@ locally over USB/BLE DFU or SWD first; there is no raw-card compatibility handof
The copy/paste command is:
```text
tempradio 909.950,250,5,5,120
tempradio 910.525,250,5,5,120
```
The fourth value is the transmit coding rate. This guide uses CR5, but the participating nodes' coding rates
@@ -117,7 +126,8 @@ RAK13302 share a chip-select and cannot be used together. Other
normal repeaters can still serve as intermediate relays but cannot necessarily
install an update themselves. ESP32
`-ota-` siblings also retain the lightweight browser WiFi uploader (`start
ota`), the complete CLI, and a 254-entry neighbor table. RP2040 and STM32
ota`), the complete CLI, and up to 254 neighbors; constrained targets use 50
as recorded in their capability manifests. RP2040 and STM32
repeaters do not currently have a safe self-apply path, but current repeater
firmware can still relay OTA packets opaquely during TempRadio.
@@ -375,7 +385,7 @@ especially with older single-block receivers. Use `hops 1` only when one real in
On the source node, destination node, and every intermediate repeater, then run:
```text
tempradio 909.950,250,5,5,120
tempradio 910.525,250,5,5,120
```
All participating nodes must use the same frequency, bandwidth, and spreading factor. Their time windows must
@@ -404,7 +414,7 @@ cable-free source is:
python3 tools/ble_mota/ble_mota_seeder.py \
--device MeshCore-MyCompanion \
--dir ./motas \
--local 'tempradio 909.950,250,5,5,120'
--local 'tempradio 910.525,250,5,5,120'
```
Leave this command running until the destination finishes downloading.
@@ -490,7 +500,7 @@ ota status
## Quick troubleshooting
- **Nothing appears in `ota ls`:** confirm that `motatool serve` is still running and every required node
has an active `tempradio 909.950,250,5,5,120` window.
has an active `tempradio 910.525,250,5,5,120` window.
- **The CLI says LoRa OTA is not included:** that firmware does not contain the LoRa OTA feature.
If it is the source or destination, install a supported `-ota-` build over WiFi or USB first. An intermediate
repeater does not need the OTA CLI and can relay opaquely while its matching `tempradio` window is active.
docs/ota_meshtower_v2_sdcard.md
+9
View File
@@ -1,5 +1,14 @@
# MeshTower V2 microSD LoRa OTA
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
The `Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors` target uses the MeshTower V2 onboard
microSD socket as persistent storage for its own LoRa OTA downloads. It accepts
full application images, in-place application deltas, and explicitly selected
docs/ota_nrf52_bootloader_update.md
+9
View File
@@ -1,5 +1,14 @@
# nRF52 bootloader updates over LoRa
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
Selected nRF52840 repeater LoRa-OTA builds can replace their matching OTAFIX
bootloader without replacing the running application. This is a privileged
maintenance path, not a normal firmware update. A stock bootloader must first
docs/ota_nrf52_qspi.md
+11
View File
@@ -1,5 +1,14 @@
# nRF52 repeater LoRa OTA with external QSPI
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
Selected nRF52840 repeater builds use their dedicated external QSPI NOR flash as
a raw LoRa OTA staging device. This removes the internal-flash staging conflict:
the complete `.mota` stays off-chip, and the bootloader can use the entire
@@ -82,6 +91,8 @@ stock RAK3401 + RAK15001 assembly cannot provide reliable OTA staging without
a hardware chip-select rework. This restriction does not apply to the
separate-CS W25Q16 wiring below.
<a id="one-w25q16-wiring-for-rak4631-or-rak3401--rak13302"></a>
### One W25Q16 wiring for RAK4631 or RAK3401 + RAK13302
An external Winbond W25Q16JV breakout can remain attached to a RAK19007 while
docs/ota_protocol.md
+3 -2
View File
@@ -153,8 +153,9 @@ The firmware-configured INA3221 address and RAK12500 address are both `0x42`, so
one bus at those addresses. Keep RAK12500 at `0x42`, strap INA3221 A0 to SCL for `0x43`, and use firmware
built with `-DTELEM_INA3221_ADDRESS=0x43` when both are installed.
ESP32 siblings retain the compact browser WiFi updater and use the full
254-entry neighbor table. RP2040 and STM32 targets are not offered because
ESP32 siblings retain the compact browser WiFi updater and use up to
254 neighbors. Internal-DRAM-constrained targets use 50 as recorded in the
artifact capability manifest; see [ESP32 memory budget](esp32_memory_budget.md). RP2040 and STM32 targets are not offered because
those platforms do not yet have a safe bootloader/apply path.
nRF52 LoRa-OTA siblings use size optimization rather than the Adafruit platform's default `-Ofast`. This
docs/ota_user_guide.md
+12 -3
View File
@@ -1,5 +1,14 @@
# Updating your node over the air (OTA) - user guide
For **1.17.1.5**, use the exact board/storage profile from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6)
for nRF52 OTAFIX installations. New internal-flash hybrid receivers require
its 64 KiB retained-RAM handoff; QSPI and microSD targets require their own
matching bootloader profiles. Earlier preview versions mentioned below
describe compatibility/migration history, not the current recommended download.
Full Companion is a MOTA source and normally updates itself over USB.
This guide is for **node operators**: how to update your MeshCore device's firmware over the radio, in
plain language. No cables, no programmer - your node can download a new firmware from a neighbour and
install it. (For the technical wire format, see [the OTA protocol spec](ota_protocol.md).)
@@ -16,13 +25,13 @@ only while `tempradio` is actually running on that node. Every source, receiver,
therefore have an overlapping temporary-radio window.
The recommended temporary OTA settings use 250 kHz bandwidth, SF5, CR5, and a 120-minute window. For a
North American node currently configured for 909.950 MHz, run this on every participating node:
North American node currently configured for 910.525 MHz, run this on every participating node:
```text
tempradio 909.950,250,5,5,120
tempradio 910.525,250,5,5,120
```
Use the node's current permitted regional frequency in place of `909.950` when necessary.
Use the node's current permitted regional frequency in place of `910.525` when necessary.
The scripted updater checks the firmware version of the receiver and every
sender before deciding whether RX power saving can remain active. At
docs/releases/1.17.1.5-doc-audit.md
+122
View File
@@ -0,0 +1,122 @@
# Markdown audit — 1.17.1.5 USA Cascade
Audited on 2026-09-05 against firmware source `26303793`, the resolved build
configuration, and the qualified 1.17.1.5 staging manifests. The scope was all
**71 tracked Markdown files** present at the start, including root documents,
docs, examples, tools, tests, variants, and vendored library documentation.
Generated/ignored build directories and external repositories were outside that scope.
## Corrections
- Added [role-specific feature switches](../role_feature_switches.md), exact
Companion/infrastructure MQTT and logging controls, board exceptions, SNMP,
and the [USB web console](https://flasher.meshcore.io/console).
- Added an [exact-name variant map](1.17.1.5-variant-map.tsv); every one of its
1,325 covered entries resolves to a staged firmware file. The 36 excluded
entries are identified rather than linked to substitute hardware.
- Corrected universal 254-neighbor claims, Full Companion MQTT filename/CLI
assumptions, TLora Full WebConfig availability, and partition/NVS guidance.
- Distinguished infrastructure bare `powersaving on` guards from the separate
`set powersaving on` form; corrected the RS232 baud range and SNMP environment list.
- Linked OTAFIX 2.4.6 and its board/storage requirements from operator guides;
aligned the two manual USA OTA quickstarts with 910.525 MHz.
- Marked old provider catalogs and dated hardware results as historical;
documented the legacy tag workflow that also matches `repeater-room-*`.
- Fixed the vendored MQTT documentation link and documentation-site links
that incorrectly treated repository source files as generated site pages.
## Verification and limits
All original Markdown files were scanned for relative links, section anchors,
source-path references, version/default claims, and role/OTA terminology.
Flagged operator instructions were checked against CommonCLI, its observer
extension, Companion command handlers, board configuration, and release manifests.
Brace-expanded source references and SDK-relative paths were retained as such.
Historical measurements, changelogs, upstream findings, contribution/security
policies, and licenses were not rewritten as new validation results.
The documentation site passed a strict MkDocs Material build. Relative repository
links and section anchors were checked separately, including documents outside
the MkDocs source directory. Console and current bootloader links were checked
on their primary sites. This was not a crawl of every third-party URL or a
new hardware/firmware qualification; no claim is made that every board was
physically tested or every protocol statement independently re-proved.
## Original file coverage
“Retained” means no correction was identified by this documentation audit;
it does not certify all historical statements as current hardware behavior.
| File | Disposition |
| --- | --- |
| [AGENTS.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/AGENTS.md) | Scanned; retained |
| [ALERTS.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/ALERTS.md) | Scanned; retained |
| [CHANGELOG.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/CHANGELOG.md) | Historical record retained |
| [CONTRIBUTING.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/CONTRIBUTING.md) | Scanned; retained |
| [MEMORY_MONITORING.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MEMORY_MONITORING.md) | Scanned; retained |
| [MQTT_IMPLEMENTATION.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MQTT_IMPLEMENTATION.md) | Corrected or clarified |
| [MQTT_INTERNALS.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MQTT_INTERNALS.md) | Corrected or clarified |
| [MQTT_OWNERSHIP.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MQTT_OWNERSHIP.md) | Historical record retained |
| [MQTT_SNMP.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MQTT_SNMP.md) | Corrected or clarified |
| [README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/README.md) | Corrected or clarified |
| [RELEASE.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/RELEASE.md) | Corrected or clarified |
| [RESTORE_UPSTREAM_NOTES.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/RESTORE_UPSTREAM_NOTES.md) | Historical record retained |
| [SECURITY.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/SECURITY.md) | Scanned; retained |
| [STABILITY_TESTABILITY_HANDOFF.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/STABILITY_TESTABILITY_HANDOFF.md) | Historical record retained |
| [UPSTREAM_BUGS.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/UPSTREAM_BUGS.md) | Scanned; retained |
| [WEB_CONFIG_REVIEW.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/WEB_CONFIG_REVIEW.md) | Corrected or clarified |
| [arch/stm32/Adafruit_LittleFS_stm32/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/arch/stm32/Adafruit_LittleFS_stm32/README.md) | Vendored documentation/license retained |
| [arch/stm32/Adafruit_LittleFS_stm32/src/littlefs/LICENSE.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/arch/stm32/Adafruit_LittleFS_stm32/src/littlefs/LICENSE.md) | Vendored documentation/license retained |
| [arch/stm32/Adafruit_LittleFS_stm32/src/littlefs/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/arch/stm32/Adafruit_LittleFS_stm32/src/littlefs/README.md) | Vendored documentation/license retained |
| [docs/WiFi.md](../WiFi.md) | Corrected or clarified |
| [docs/cli_build_matrix.md](../cli_build_matrix.md) | Corrected or clarified |
| [docs/cli_command_availability.md](../cli_command_availability.md) | Corrected or clarified |
| [docs/cli_commands.md](../cli_commands.md) | Corrected or clarified |
| [docs/companion_offline_queue.md](../companion_offline_queue.md) | Scanned; retained |
| [docs/companion_protocol.md](../companion_protocol.md) | Scanned; retained |
| [docs/companion_radio_full.md](../companion_radio_full.md) | Corrected or clarified |
| [docs/docs.md](../docs.md) | Scanned; retained |
| [docs/esp32_memory_budget.md](../esp32_memory_budget.md) | Scanned; retained |
| [docs/faq.md](../faq.md) | Corrected or clarified |
| [docs/filter_tool.md](../filter_tool.md) | Scanned; retained |
| [docs/firmware_picker.md](../firmware_picker.md) | Corrected or clarified |
| [docs/flood_filtering.md](../flood_filtering.md) | Scanned; retained |
| [docs/full_companion_features.md](../full_companion_features.md) | Corrected or clarified |
| [docs/full_companion_usb_switcher.md](../full_companion_usb_switcher.md) | Corrected or clarified |
| [docs/gps_tracking.md](../gps_tracking.md) | Scanned; retained |
| [docs/halo_keymind_settings.md](../halo_keymind_settings.md) | Corrected or clarified |
| [docs/hardware_validation_checklist.md](../hardware_validation_checklist.md) | Corrected or clarified |
| [docs/host_cli_service.md](../host_cli_service.md) | Scanned; retained |
| [docs/index.md](../index.md) | Corrected or clarified |
| [docs/kiss_modem_protocol.md](../kiss_modem_protocol.md) | Scanned; retained |
| [docs/lora_ota_automation.md](../lora_ota_automation.md) | Corrected or clarified |
| [docs/mbedtls-tls-footprint.md](../mbedtls-tls-footprint.md) | Scanned; retained |
| [docs/nrf52_companion_storage_recovery.md](../nrf52_companion_storage_recovery.md) | Scanned; retained |
| [docs/nrf52_power_management.md](../nrf52_power_management.md) | Scanned; retained |
| [docs/number_allocations.md](../number_allocations.md) | Scanned; retained |
| [docs/ota_easy.md](../ota_easy.md) | Corrected or clarified |
| [docs/ota_meshtower_v2_sdcard.md](../ota_meshtower_v2_sdcard.md) | Corrected or clarified |
| [docs/ota_nrf52_bootloader_update.md](../ota_nrf52_bootloader_update.md) | Corrected or clarified |
| [docs/ota_nrf52_qspi.md](../ota_nrf52_qspi.md) | Corrected or clarified |
| [docs/ota_protocol.md](../ota_protocol.md) | Corrected or clarified |
| [docs/ota_user_guide.md](../ota_user_guide.md) | Corrected or clarified |
| [docs/packet_format.md](../packet_format.md) | Scanned; retained |
| [docs/payloads.md](../payloads.md) | Scanned; retained |
| [docs/qr_codes.md](../qr_codes.md) | Scanned; retained |
| [docs/rak3401_mota_chain.md](../rak3401_mota_chain.md) | Historical record retained |
| [docs/releases/1.17.1.5.md](../releases/1.17.1.5.md) | Corrected or clarified |
| [docs/spiffs_regular_file_reads.md](../spiffs_regular_file_reads.md) | Scanned; retained |
| [docs/stats_binary_frames.md](../stats_binary_frames.md) | Scanned; retained |
| [docs/telemetry_decoder.md](../telemetry_decoder.md) | Scanned; retained |
| [docs/terminal_chat_cli.md](../terminal_chat_cli.md) | Scanned; retained |
| [docs/usb_serial_backpressure.md](../usb_serial_backpressure.md) | Scanned; retained |
| [examples/host_cli_service/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/examples/host_cli_service/README.md) | Scanned; retained |
| [lib/PsychicMqttClient/CHANGELOG.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/lib/PsychicMqttClient/CHANGELOG.md) | Vendored documentation/license retained |
| [lib/PsychicMqttClient/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/lib/PsychicMqttClient/README.md) | Corrected or clarified |
| [mesh-america/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/mesh-america/README.md) | Corrected or clarified |
| [test/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/test/README.md) | Scanned; retained |
| [test/test_mqtt_prefs_codec/FIXTURES.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/test/test_mqtt_prefs_codec/FIXTURES.md) | Historical record retained |
| [tools/mota/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/tools/mota/README.md) | Scanned; retained |
| [tools/sensecap_indicator_font/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/tools/sensecap_indicator_font/README.md) | Scanned; retained |
| [tools/sensecap_indicator_rp2040/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/tools/sensecap_indicator_rp2040/README.md) | Scanned; retained |
| [variants/sensecap_indicator-espnow/README.md](https://github.com/mikecarper/MeshCore/blob/keymindCascade/variants/sensecap_indicator-espnow/README.md) | Scanned; retained |
docs/releases/1.17.1.5-variant-map.tsv
+1362
View File
File diff suppressed because it is too large Load Diff
docs/releases/1.17.1.5.md
+30
View File
@@ -1,5 +1,11 @@
# MeshCore 1.17.1.5 Dev — USA Cascade
Use [feature switches by role](../role_feature_switches.md) for exact on/off
commands for Companion, Repeater, Room Server, and Sensor, including MQTT,
logging, power saving, GPS, and board exceptions. Open the
[USB web console](https://flasher.meshcore.io/console) for the default ASCII
terminal on Full Companion and infrastructure images.
The firmware identifier and main release tag follow
`v1.17.1.5-halo-keymind-cascade-dev-<commit>`, matching the 1.17.1.4 naming
convention. Supplemental pages retain the `repeater-room-`, `utility-`,
@@ -94,3 +100,27 @@ checksums, build notes, and Full Companion directions. The staging directory's
root `FIRMWARE-PICKER-1.17.1.5.html` opens the local downloads; the copies inside
each release group use the planned GitHub download URLs. Staging does not
push commits, create remote tags, or publish a GitHub release.
## Published release set and small-slot Heltec V4 updates
Published firmware tags remain at source commit `26303793`. Documentation can
advance independently. The original matrix qualified 540 profiles (1,080
firmware files) from 551 attempts; 11 oversized portable attempts have expanded
Full replacements. The [variant map](1.17.1.5-variant-map.tsv) maps all 1,361
previous-release choices to 1,325 covered choices and 36 excluded entries.
Multiple old choices map to the same current artifact.
For Heltec V4 with an existing compatible **1.25 MiB OTA application slot**, the
standard `heltec_v4_repeater` application is **1,179,200 bytes** and the lean
`heltec_v4_repeater_lora_ota_no_external_sensors` application is **1,232,024 bytes**.
Both fit that slot. Start the WiFi uploader with `start ota ap`, join
`MeshCore-OTA`, and open `http://192.168.4.1/update`. Upload the application
`.bin`; use `stop ota` to close an unused uploader. Their merged USB installers
write two 6.25 MiB application slots. Expanded Full V4 applications require
the larger layout and do not fit a 1.25 MiB slot.
- [Companion firmware](https://github.com/mikecarper/MeshCore/releases/tag/v1.17.1.5-halo-keymind-cascade-dev-26303793)
- [Repeater and Room Server firmware](https://github.com/mikecarper/MeshCore/releases/tag/repeater-room-v1.17.1.5-halo-keymind-cascade-dev-26303793)
- [Sensor firmware](https://github.com/mikecarper/MeshCore/releases/tag/utility-v1.17.1.5-halo-keymind-cascade-dev-26303793)
- [LoRa OTA repeater firmware](https://github.com/mikecarper/MeshCore/releases/tag/lora-ota-v1.17.1.5-halo-keymind-cascade-dev-26303793)
- [Expanded Full infrastructure](https://github.com/mikecarper/MeshCore/releases/tag/full-profiles-v1.17.1.5-halo-keymind-cascade-dev-26303793)
docs/role_feature_switches.md
+247
View File
@@ -0,0 +1,247 @@
# Feature switches by role — 1.17.1.5 USA Cascade
Use these settings with the exact board's canonical release image. Former
logging, power-saving, FEM-gain, and rotated-display variants are now runtime
choices where the hardware supports them. A setting cannot add missing radio
hardware, MQTT code, storage, or an OTA partition. Check the download's
`.capabilities.json` and the [firmware picker](firmware_picker.md).
For exact old device/variant names, search the
[1.17.1.5 variant map](releases/1.17.1.5-variant-map.tsv): it maps all 1,361
previous release entries to 1,325 covered choices or 36 excluded entries.
Many old choices share one current image; the command tables below explain
how to select their former behavior. Excluded entries have no download.
## Open the USB web console
Open the [MeshCore USB web console](https://flasher.meshcore.io/console) in
Chrome or Edge, connect a data-capable USB cable, close other applications
using that port, and select the device. Use **115200 baud** when prompted.
Full Companion, Repeater, Room Server, and Sensor start with an **ASCII USB
terminal**. Run `board`, then `version` on a Companion or `ver` on infrastructure.
If a Companion app has already switched USB to its binary protocol, send:
```text
+++MESHCORE-TERM-START
```
To hand the port back to a Companion app or USB MOTA host, send
`+++MESHCORE-TERM-STOP`, close the console, and connect the app/tool. Dedicated
USB/BLE/WiFi Companion images can start in binary mode; use the start token
there too. KISS firmware uses its modem protocol and is outside this release.
The linked console runs in your computer's browser over **USB**. It does not
need node WiFi or `set webui on`. **WebConfig** is a separate settings website
served by supported ESP32 images. Infrastructure WebConfig can include a
browser command terminal (`set wifi.cli on`); Companion WebConfig does not.
Full ESP32 Companion also has a text terminal at TCP port **5002**.
## Which old variant setting should I use?
These controls apply to every board with the corresponding compiled feature;
use the board exceptions below when the command differs.
| Former choice | Current image / runtime control |
| --- | --- |
| USB logging or Station G2/G3 logging variant | Same role's canonical image; `set usb.logging on` / `off` |
| Infrastructure USB logging, WiFi MQTT, or both | Unified MQTT-capable Full infrastructure; `set logging.output usb`, `wifi`, `both`, or `off` |
| Companion WiFi-MQTT variant | MQTT-capable Full Companion; configure broker slots in WebConfig |
| `_ps` power-saving variant | `powersaving on` / `off` on Companion; infrastructure forms and restrictions below |
| `_femoff` / FEM-gain variant | `set radio.fem.rxgain on` / `off`; separate TX switch where controllable |
| RX boost variant | `set radio.rxgain on` / `off` on a supported radio |
| iKOKA rotated-display variant | Full Companion: `set display.rotation 180`; `0` restores the board default |
| Separate USB, BLE, WiFi, Ethernet, or Terminal Chat Companion | Exact board's Full Companion where listed; supported transports are included, with SenseCAP selection below |
| RS232 repeater variant consolidated into the ordinary repeater | `set bridge.enabled on` / `off` on a build containing the RS232 bridge |
| ESP-NOW bridge or primary ESP-NOW radio | Select the matching hardware/role image first; bridge and primary-radio channel commands differ |
| LoRa OTA / external-storage variant | Still choose the exact receiver/storage image and matching bootloader; this is not a software on/off switch |
Full infrastructure and Full Companion are different roles. In particular,
**`logging.output` and `bridge.enabled` are infrastructure commands**, not
Full Companion MQTT switches.
## Full Companion commands
| Setting | Enable / select | Disable / restore | Read back |
| --- | --- | --- | --- |
| Device power saving | `powersaving on` | `powersaving off` | `powersaving` |
| LoRa RX power saving | `set radio.rxps on` | `set radio.rxps off` | `get radio.rxps` |
| Radio RX boost | `set radio.rxgain on` | `set radio.rxgain off` | `get radio.rxgain` |
| External FEM RX gain | `set radio.fem.rxgain on` | `set radio.fem.rxgain off` | `get radio.fem.rxgain` |
| External FEM TX gain | `set radio.fem.txgain on` | `set radio.fem.txgain off` | `get radio.fem.txgain` |
| ESP32 USB logging | `set usb.logging on` | `set usb.logging off` | `get usb.logging` |
| nRF52 second USB logging port | `set usb.logging on reboot` | `set usb.logging off reboot` | `get usb.logging` |
| ESP32 persistent WebConfig | `set webui on` | `set webui off` | `get webui` |
| ESP32 temporary setup AP | `start webconfig ap` | `stop webconfig` | `get webui` |
| Display rotation | `set display.rotation 90`, `180`, or `270` | `set display.rotation 0` | `get display.rotation` |
| Temporary MOTA radio window | `tempradio 910.525,250,5,5,120` | `normalradio` | `tempradio` |
Saved settings apply immediately unless noted. Rotation and gain controls
report unsupported hardware instead of creating that feature. Fresh Full
Companion preferences enable device power saving and leave USB logging off;
existing saved preferences win after an update.
**ESP32:** logging and binary Companion traffic share one USB port. Turn logging
off before handing USB to an app/MOTA host. **nRF52:** the optional second CDC
port is for logs; use the primary port for Companion/MOTA. Adding/removing the
second port requires the `reboot` suffix shown above.
### Companion MQTT: use WebConfig, not infrastructure CLI commands
1. Run `set webui on` and open the URL reported by `get webui`, or run
`start webconfig ap` and join the setup network.
2. In the MQTT cards, select a broker preset and configure its required
details. Save to enable that slot.
3. To disable MQTT connections, select **`none` for every broker slot** and
save. To enable them again, restore the desired presets/settings and save.
4. Use the separate status, packets, raw, receive, and transmit controls to
choose what is published. Turning off status publication alone leaves
broker connections enabled.
Full Companion has no USB text equivalents for `set mqtt1.preset`,
`set bridge.enabled`, or `set logging.output`. Use its WebConfig controls.
USB logging is independent of those broker slots. Images without MQTT code
do not show MQTT cards.
### Companion WiFi, Bluetooth, GPS, and board exceptions
Configure ESP32 WiFi with:
```text
set wifi.ssid MyNetwork
set wifi.pwd my-password
get wifi.status
```
`set wifi.powersave min` enables WiFi modem sleep; `none` disables it. `max`
is accepted only where the BLE/WiFi coexistence policy allows it. Read back
with `get wifi.powersave`. This is separate from device power saving and RXPS.
The assigned WiFi button/display switch controls WiFi services on supported
boards. `stop webconfig` closes only the portal; it is not a WiFi master switch.
There is no universal Bluetooth-off or Ethernet-off text command.
**SenseCAP Indicator Full only:** `set companion.transport wifi` followed by
`reboot` selects WiFi; `set companion.transport ble` followed by `reboot`
selects Bluetooth. Check `get companion.transport`. USB remains available.
Primary ESP-NOW Indicator images keep their mesh radio in either selection.
**GPS-equipped Companions:** use `gps=1` / `gps=0` in the Companion app's
custom sensor settings. These are app settings, not ASCII terminal commands.
See [GPS tracking](gps_tracking.md) for location-sharing settings.
## Repeater, Room Server, and Sensor commands
These roles use CommonCLI. Feature-dependent commands require the relevant
hardware/build; MQTT is present in observer builds, and WebConfig is absent
from some portable builds. The USB browser console still works without it.
| Setting | Enable | Disable | Read back |
| --- | --- | --- | --- |
| Live USB logging | `set usb.logging on` | `set usb.logging off` | `get usb.logging` |
| Capture RX log to node storage | `log start` | `log stop` | `log` prints the capture locally |
| MQTT / RS232 / ESP-NOW bridge master | `set bridge.enabled on` | `set bridge.enabled off` | `get bridge.enabled`, `get bridge.running`, `get bridge.type` |
| MQTT periodic status publication | `set mqtt.status on` | `set mqtt.status off` | `get mqtt.status` shows connection status |
| MQTT packet publication | `set mqtt.packets on` | `set mqtt.packets off` | `get mqtt.packets` |
| SNMP on supported MQTT infrastructure | `set snmp on`, then `reboot` | `set snmp off`, then `reboot` | `get snmp` |
| MQTT raw packet publication | `set mqtt.raw on` | `set mqtt.raw off` | `get mqtt.raw` |
| MQTT receive capture | `set mqtt.rx on` | `set mqtt.rx off` | `get mqtt.rx` |
| MQTT transmit capture | `set mqtt.tx on` (or `advert`) | `set mqtt.tx off` | `get mqtt.tx` |
| ESP32 persistent WebConfig | `set webui on` | `set webui off` | `get webui` |
| WebConfig browser command terminal | `set wifi.cli on` | `set wifi.cli off` | `get wifi.cli` |
| LoRa RX power saving | `set radio.rxps on` | `set radio.rxps off` | `get radio.rxps` |
| Radio RX boost | `set radio.rxgain on` | `set radio.rxgain off` | `get radio.rxgain` |
| Controllable FEM RX / TX gain | `set radio.fem.rxgain on` / `set radio.fem.txgain on` | `set radio.fem.rxgain off` / `set radio.fem.txgain off` | Corresponding `get radio.fem.rxgain` / `get radio.fem.txgain` |
| GPS, when compiled | `gps on` | `gps off` | `gps` |
Infrastructure `set usb.logging` has **no `reboot` suffix**, including nRF52.
`log start/stop` records to storage independently of live USB logging. Use
`log erase` to delete that capture.
### Infrastructure MQTT and logging output
On unified Full infrastructure with both MQTT and USB logging compiled:
| Command | USB logs | MQTT bridge |
| --- | --- | --- |
| `set logging.output off` | Off | Off |
| `set logging.output usb` | On | Off |
| `set logging.output wifi` | Off | On |
| `set logging.output both` | On | On |
`get logging.output` reports the selection. Fresh unified Full preferences
select `both`; saved settings override this. To toggle only MQTT while keeping
USB logging unchanged, use `set bridge.enabled off` / `on`. Neither setting
turns LoRa repeating off. Repeater forwarding uses `set repeat off` / `on`
and `get repeat` separately.
For a custom broker on an MQTT-capable Repeater or Room Server:
```text
set wifi.ssid MyNetwork
set wifi.pwd my-password
set mqtt.iata SEA
set mqtt1.preset custom
set mqtt1.server broker.example.com
set mqtt1.port 1883
set bridge.enabled on
get mqtt.status
```
Set `mqtt1.username` / `mqtt1.password` if required by that broker. Configure only
as many slots as the board supports. `set mqtt1.preset none` disables slot 1;
other configured slots remain enabled. `set mqtt.status off` disables status
messages, not MQTT itself. See the [MQTT reference](https://github.com/mikecarper/MeshCore/blob/keymindCascade/MQTT_IMPLEMENTATION.md)
for presets, TLS, credentials, and slot limits.
### Infrastructure power saving and bridges
`powersaving` reads the saved device setting. The bare **`powersaving on`**
command rejects local/USB-connected requests on nRF52 and standalone ESP32;
use it remotely with USB data disconnected. ESP32 bridge builds reject that
bare enable command. `powersaving off` disables it.
The separate **`set powersaving on` / `set powersaving off`** form, also used
by infrastructure WebConfig, saves/applies the preference without those
bare-command guards. Actual sleep depends on the board implementation and
can interrupt WiFi. Do not assume it behaves like Companion CPU/GPS saving.
On RS232-capable repeater images, stop the bridge before changing its serial
port or baud rate, then restart it:
```text
set bridge.enabled off
set bridge.baud 115200
set bridge.enabled on
```
**RAK4631:** `set bridge.uart 2` selects UART2 while the bridge is stopped.
Canonical GPS-enabled builds reserve UART1 for GPS; UART1 requires a dedicated
GPS-free image. **ESP-NOW bridge:** use `set bridge.channel <1..13>` and
`set bridge.format wrapped` / `raw` where supported. **Primary ESP-NOW mesh:**
use `set espnow.channel <1..13>` and reboot; this is a different radio setting.
For infrastructure WebConfig on the LAN, use `start webconfig` /
`stop webconfig`. To force a setup AP on an observer, first run
`set bridge.enabled off`, then `start webconfig ap`. When finished, run
`stop webconfig` and restore `set bridge.enabled on` if you did not reboot.
## Updating and sending MOTA
All released Full Companions can serve MOTA to other nodes. Close the console
and run `motatool serve --serial /dev/ttyACM0 --dir ./motas -v` on the USB host.
See [Full Companion instructions](full_companion_features.md) for WiFi/BLE
source commands and the bounded temporary radio setup.
| Role / hardware | Start self-update | Stop / requirement |
| --- | --- | --- |
| ESP32 Repeater, Room Server, Sensor with WiFi updater | `start ota` or `start ota ap`; open the returned URL (normally port 80, `/update`) | `stop ota`; close WebConfig first if it shares port 80 |
| ESP32 Full Companion with two application slots | `start ota` or `start ota ap`; returned URL uses port 8080, `/update` | `stop ota`; single-slot Full builds use USB |
| nRF52 infrastructure with Bluetooth DFU | `start ota` enters the Bluetooth update flow | Matching application DFU ZIP and board bootloader required |
| Qualified LoRa OTA receiver | Follow [LoRa OTA directions](ota_easy.md) | Exact destination package, storage profile, and overlapping temporary radio windows |
For nRF52 OTAFIX installations use the exact board/storage build from
[OTAFIX 2.4.6](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.11.0-OTAFIX2.4.6).
Its retained-RAM handoff is required by the new internal-flash hybrid receiver
images. Full Companions are sources and remain normally USB-updated.
The [complete infrastructure CLI](cli_commands.md), [role/build matrix](cli_build_matrix.md),
and [Full Companion feature guide](full_companion_features.md) provide details.
lib/PsychicMqttClient/README.md
+1 -1
View File
@@ -178,7 +178,7 @@ Otherwise the bundle will be overwritten by the MQTT client with unwanted side e
## Advanced Usage
Check the [documentation](/documentation.md) or the commented header file and the `FullyFeatured` example for a complete list of all event handlers and configuration options. You can even get access to the ESP-IDF MQTT Clients' configuration object, should you need parameters not broken out to the API.
Check the [documentation](https://github.com/theelims/PsychicMqttClient/blob/main/documentation.md) or the commented header file and the `FullyFeatured` example for a complete list of all event handlers and configuration options. You can even get access to the ESP-IDF MQTT Clients' configuration object, should you need parameters not broken out to the API.
## License
mesh-america/README.md
+7
View File
@@ -1,5 +1,12 @@
# Mesh America provider catalogs
**Legacy catalog snapshot:** these checked-in catalogs still reference
1.17.1.1/1.17.1.2. They are not the 1.17.1.5 release inventory. Use the
[current firmware picker](../docs/firmware_picker.md) and
[1.17.1.5 release guide](../docs/releases/1.17.1.5.md) for current downloads.
The commands below document maintenance of the older catalogs; publishing a
release does not update these JSON files automatically.
Generated provider catalogs for the Keymind Cascade MeshCore release assets.
The provider URLs stay stable when a new firmware release is published.