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. 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 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:

+++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. 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.

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, first follow its role's WiFi/MQTT setup and verify the actual connection with get wifi.status. Once connected, this example selects a custom broker:

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 broker value. Add the broker's username and password if needed. Use the WiFi/MQTT guide 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 for the complete commands.

For RS-232, stop the UART bridge before changing its configuration:

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.

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 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 for supported staged routes and the WiFi guide for role-specific network setup.