176 lines
9.1 KiB
Markdown
176 lines
9.1 KiB
Markdown
# Full firmware profiles
|
|
|
|
Full combines the features supported by an exact board and firmware role in
|
|
one image. Use runtime settings to choose the services you need instead of
|
|
flashing a separate image for each transport. Hardware, memory, and the
|
|
installed flash layout still determine which combinations can run.
|
|
|
|
**Full is not a runtime role switch.** Choose Companion, Repeater, Room Server,
|
|
or Sensor in the [firmware picker](firmware_picker.md). Changing roles requires
|
|
the matching firmware; enabling a bridge does not turn a Companion into a
|
|
repeater.
|
|
|
|
## Choose the board, role, and profile
|
|
|
|
| Choice | What Full combines | Important limits |
|
|
| --- | --- | --- |
|
|
| Full Companion | The board's supported USB, Bluetooth, ESP32 WiFi, and qualified serial/Ethernet Companion transports, plus terminal chat and mOTA serving | The primary radio and board interfaces remain those of the selected target. Full Companion serves updates to other nodes; it does not install LoRa mOTA on itself. |
|
|
| ESP32 Full Repeater or Room Server | Standalone operation, supported USB/WiFi services, and the qualified MQTT, ESP-NOW, or RS-232 combination | Not every image contains all three bridges. Read its capabilities and check the compiled controls. |
|
|
| ESP32 Full Sensor | Sensor operation, supported CLI/logging, and qualified WiFi firmware-update and TCP 5001 seeding services | Current Sensor profiles do not gain the repeater's MQTT/ESP-NOW/RS-232 bridges. |
|
|
| nRF52 Full supported sensors or Reduced sensors | Two separately qualified Repeater, Room Server, or Sensor recipes with LoRa OTA | These are sensor-driver choices, not ESP32 network features. Full Companion remains a separate profile. |
|
|
|
|
Select the exact hardware variant and storage choice. Read the selected
|
|
image's capability manifest for update methods and requirements; a similar
|
|
filename is not evidence that another board's image will work.
|
|
|
|
## Full Companion: choose the active transports
|
|
|
|
Close any application using the USB port, then open the
|
|
[USB web console](https://flasher.meshcore.io/console) at 115200 baud. A fresh
|
|
Full Companion starts in the text terminal. If an app already selected Binary
|
|
Companion mode, send this line and wait for the terminal banner:
|
|
|
|
```text
|
|
+++MESHCORE-TERM-START
|
|
```
|
|
|
|
Run `help`, `board`, and `version` to inspect the device. The same image can
|
|
serve an app through its compiled transports or provide
|
|
[terminal chat](terminal_chat_cli.md). USB remains the normal installation
|
|
and recovery path.
|
|
|
|
On a Bluetooth-capable Companion, `get bluetooth` shows the running state;
|
|
`set bluetooth on` enables the saved Bluetooth preference. On an ESP32
|
|
profile with WiFi, `start webconfig ap` opens a temporary setup portal where
|
|
you can save network credentials. MQTT-capable Companions also expose broker
|
|
settings there; MQTT is not included on every Companion board.
|
|
|
|
Most Full Companions can use multiple transports together. **SenseCAP
|
|
Indicator** selects Bluetooth or infrastructure WiFi per boot using
|
|
`set companion.transport ble` or `set companion.transport wifi`, followed
|
|
by `reboot`; USB remains available. Generic ESP-NOW and Indicator ESP-NOW
|
|
profiles use ESP-NOW as their primary mesh radio. Full does not convert those
|
|
profiles into LoRa radios.
|
|
|
|
USB logging shares the ESP32 Companion's single USB port. Use
|
|
`set usb.logging off`, then `+++MESHCORE-TERM-STOP` and close the terminal
|
|
before reconnecting a Binary Companion app. nRF52 Full Companion can instead
|
|
add a separate logging port with `set usb.logging on reboot`; use its primary
|
|
port for Companion commands and mOTA serving. A one-port host bridge can use
|
|
`set usb.logging stream reboot`, which occupies the primary port until logging
|
|
is disabled. See the [USB mode guide](full_companion_usb_switcher.md).
|
|
|
|
## ESP32 infrastructure: enable the compiled services
|
|
|
|
Full Repeater and Room Server images retain their normal role while their
|
|
supported bridges run. A LoRa/ESP-NOW bridge keeps LoRa as its primary radio
|
|
and exchanges packets with its ESP-NOW peers over 2.4 GHz. MQTT publishes
|
|
observed traffic to brokers; it does not subscribe to broker messages or
|
|
inject them into LoRa. RS-232 uses the board's configured UART and pins.
|
|
|
|
Check `get bridge.type` on bridge-capable images. Depending on the recipe,
|
|
it can report combinations such as `mqtt+espnow`, `rs232+espnow`, or
|
|
`mqtt+rs232+espnow`. Use only the controls compiled into your image:
|
|
|
|
| Service | Saved enable/disable control | Check actual operation |
|
|
| --- | --- | --- |
|
|
| MQTT | `set mqtt.enabled on` / `off` | `get mqtt.running`, `get mqtt.status` |
|
|
| ESP-NOW | `set espnow.enabled on` / `off` | `get espnow.running` |
|
|
| RS-232 | `set rs232.enabled on` / `off` | `get rs232.running` |
|
|
| USB packet logs | `set usb.logging on` / `off` | `get usb.logging` |
|
|
|
|
An enabled preference is not proof that a service started. Missing
|
|
credentials, a channel mismatch, or a UART conflict can prevent operation.
|
|
`bridge.enabled` is a historical alias with different meanings between
|
|
recipes; use the explicit transport controls on combined images.
|
|
|
|
For an MQTT-capable image, this example selects a custom broker:
|
|
|
|
```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 mqtt.enabled on
|
|
get mqtt.status
|
|
```
|
|
|
|
Replace the sample network and broker values. Add the broker's username and
|
|
password if needed. Use the [WiFi/MQTT guide](WiFi.md#how-the-mqtt-bridge-works)
|
|
for TLS, publication settings, broker-slot limits, and reconnect behavior.
|
|
Where MQTT and USB logging coexist, `set logging.output off|usb|wifi|both`
|
|
selects those two outputs together; it does not change LoRa repeating.
|
|
|
|
For ESP-NOW, configure both peers with the same channel and compatible
|
|
`bridge.format`. `wrapped` uses the shared `bridge.secret` for bridge peers;
|
|
`raw` connects to primary-ESP-NOW MeshCore nodes. When MQTT WiFi and ESP-NOW
|
|
run together, the ESP-NOW channel must match the access point's fixed WiFi
|
|
channel. ESP-NOW alone needs no WiFi credentials. Follow the
|
|
[two-board setup](espnow_bridge_setup.md) for the complete commands.
|
|
|
|
For RS-232, stop the UART bridge before changing its configuration:
|
|
|
|
```text
|
|
set rs232.enabled off
|
|
get bridge.uart
|
|
set bridge.baud 115200
|
|
set rs232.enabled on
|
|
get rs232.running
|
|
```
|
|
|
|
Use the UART and pin assignment supported by your board. GPS can reserve or
|
|
share a UART; enabling the bridge may be rejected or pause a yieldable GPS
|
|
provider. Check the board's recipe before changing `bridge.uart`.
|
|
|
|
### Capacity and role exceptions
|
|
|
|
MKE S3 combines UART and ESP-NOW in its normal Full repeater. Full Heltec V3,
|
|
WSL3, and RAK3112 MQTT repeaters also retain independent RS-232 alongside
|
|
MQTT and ESP-NOW. **T-LoRa V2.1** retains two Full repeater choices because
|
|
of internal RAM limits: UART plus ESP-NOW, or MQTT plus ESP-NOW. Other
|
|
measured capacity exceptions retain dedicated images. Non-ESP32 boards do
|
|
not inherit these ESP32 combinations; Wio-E5, for example, keeps a separate
|
|
RS-232 image.
|
|
|
|
## nRF52: Full and Reduced supported sensors
|
|
|
|
Qualified nRF52 Repeater, Room Server, and Sensor builds offer **Full
|
|
supported sensors + LoRa OTA** and **Reduced sensors + LoRa OTA**. Full
|
|
includes the drivers supported by that board's full recipe; it does not add
|
|
support for every possible attached sensor. Reduced omits selected optional
|
|
environmental/ranging drivers while retaining generic I2C and supported board
|
|
peripherals. Reduced RAK3401/RAK4631 recipes also retain their supported
|
|
INA219/INA226/INA260/INA3221 voltage/current drivers.
|
|
|
|
Both profiles retain their exact board/role OTA identity and storage layout.
|
|
Choose the matching storage variant and meet its staging/bootloader
|
|
requirements. These profiles are LoRa OTA receivers; nRF52 Full Companion
|
|
is an update source and does not acquire WiFi or on-device MQTT. An attached
|
|
Pi can publish its USB packets using a separate host bridge. See
|
|
[sensor/storage choices](firmware_picker.md#hardware-and-variant-names).
|
|
|
|
## Install or update the matching layout
|
|
|
|
Expanded ESP32 Full images need application slots large enough for the image.
|
|
Use `get storage.layout` on firmware that provides it to inspect the installed
|
|
partition table. Firmware version alone does not establish the layout; use
|
|
the [partition lookup guide](esp32_partition_catalog.md) for older firmware.
|
|
|
|
For a compatible layout, use the exact board/role application-only image
|
|
through a supported updater. To change an ESP32 layout, use the matching
|
|
merged image over USB or an exact board/role staged migration ZIP whose README
|
|
supports your installed source layout and update route. An app-only image
|
|
cannot change the partition table, and a merged image is not a browser-OTA
|
|
application. The picker links the matching migration package where available.
|
|
|
|
ESP32 Full Companion WiFi self-update requires two application slots; the
|
|
single-slot profiles require USB. Infrastructure WiFi/LoRa self-update also
|
|
depends on the exact image's declared capabilities and installed layout.
|
|
nRF52 updates use the matching application UF2/DFU package or a qualified
|
|
LoRa route; they do not use the ESP32 browser procedure. See the
|
|
[ESP32 WiFi update and partition guide](esp32_wifi_partition_migration.md)
|
|
for supported staged routes and the [WiFi guide](WiFi.md) for role-specific
|
|
network setup.
|