Is your feature request related to a problem? Please describe.
Yes. MeshMonitor can already serve as a centralized interface for monitoring and managing Meshtastic and MeshCore devices, but firmware updates still generally require leaving MeshMonitor and using another application, web flasher, DFU utility, USB flashing process, or other platform-specific method.
For users managing multiple nodes, especially nodes installed at different physical locations, this creates unnecessary additional work. A device may already be visible and manageable through MeshMonitor, but when a firmware update becomes available the administrator still needs to determine:
- What firmware version the device is currently running
- Whether a newer firmware version is available
- Whether the device is running Meshtastic or MeshCore
- Which firmware image matches the detected hardware
- Which firmware role/build is appropriate
- Whether that hardware supports OTA/DFU updating
- Which transport can actually perform the update
- Which release channel should be used
- Which external application or flashing method is required
- Whether the firmware update completed successfully
- Whether the device rebooted correctly
- Whether the node reconnected after the update
- Whether its configuration and identity were preserved
Both Meshtastic and MeshCore already have firmware-update mechanisms for supported hardware, although the exact process varies by platform and transport.
MeshMonitor could provide a single management layer over those existing mechanisms.
Instead of requiring the administrator to understand whether a device internally needs OTA, DFU, a temporary Wi-Fi access point, USB, UF2, serial flashing, or another mechanism, MeshMonitor could detect the protocol, hardware, role, firmware version, and connection method and then expose the safest supported update workflow.
The desired experience would be similar to the simplified firmware-update experience available in mobile applications: identify the device, identify the correct firmware, confirm the update, transfer it using the appropriate supported mechanism, reboot, reconnect, and verify that the expected firmware is running.
Describe the solution you'd like
I would like MeshMonitor to have a Firmware Update / OTA Manager for both Meshtastic and MeshCore.
The manager should be able to:
- Detect whether a device is Meshtastic or MeshCore
- Detect the hardware model/platform when possible
- Detect the currently installed firmware version
- Detect the device role/build when relevant
- Check the appropriate firmware source for available releases
- Determine whether an update is available
- Determine whether the currently connected device supports OTA/DFU
- Determine whether the current transport can perform that update
- Automatically select the correct firmware artifact
- Verify firmware compatibility before installation
- Download firmware from the appropriate official source
- Verify firmware integrity when hashes/signatures are available
- Start the correct OTA/DFU/update mechanism
- Show update progress
- Wait for the device to reboot
- Reconnect to the device
- Verify the new firmware version
- Record the update result
- Provide recovery information when something fails
The user should not have to manually determine which firmware file belongs to a device when MeshMonitor already has enough information to determine that safely.
One Firmware Manager for Both Protocols
The Firmware Manager could abstract the underlying protocol-specific update mechanisms.
Conceptually:
MeshMonitor
│
Firmware Manager
│
┌─────────────┴─────────────┐
│ │
Meshtastic MeshCore
│ │
Hardware/Role Hardware/Role
│ │
Supported Updater Supported Updater
│ │
OTA / DFU / Other OTA / DFU / Other
│ │
└─────────────┬─────────────┘
│
Managed Device
From the user's perspective, the experience should remain consistent regardless of the underlying firmware platform.
For example:
Firmware Update Available
Device:
Ridge Relay
Protocol:
Meshtastic
Hardware:
Heltec V3
Installed:
2.x.x
Available:
2.x.x
Update Method:
Supported OTA
[Release Notes] [Update Firmware]
Or:
Firmware Update Available
Device:
Harbor Gateway
Protocol:
MeshCore
Hardware:
ESP32-based device
Installed:
1.x.x
Available:
1.x.x
Update Method:
OTA
[Release Notes] [Update Firmware]
The administrator should not need to manually understand every platform-specific flashing mechanism when MeshMonitor can determine the appropriate workflow.
Meshtastic Support
For Meshtastic devices, MeshMonitor could use the hardware and firmware information already exposed by the device to determine the appropriate firmware target and supported update method.
MeshMonitor should use official Meshtastic-supported update mechanisms rather than creating a separate firmware protocol.
Possible Meshtastic update states could include:
OTA Supported
DFU Supported
USB/Serial Required
Manual Update Required
Unsupported
Unknown Hardware
Unknown Firmware
For example:
Device:
Pine Gateway
Protocol:
Meshtastic
Hardware:
RAK4631
Installed:
2.x.x
Latest Stable:
2.x.x
Update Method:
nRF52 DFU
Status:
Update Available
[Update Firmware]
Or:
Device:
Field Node 7
Protocol:
Meshtastic
Hardware:
Unknown
Installed:
2.x.x
Latest Stable:
2.x.x
Automatic Update:
Unavailable
Reason:
MeshMonitor could not confidently determine the firmware target.
[View Device Information]
MeshMonitor should never guess the target firmware.
MeshCore Support
MeshCore should also be included in the same Firmware Manager.
MeshCore supports OTA/DFU workflows on supported hardware, but the exact method depends on the platform.
For supported ESP32 devices, the firmware can enter an OTA mode that exposes a temporary Wi-Fi access point and firmware upload interface.
For supported nRF52 devices, the firmware can enter a DFU workflow where the firmware package is transferred using a compatible DFU client.
The exact method depends on the hardware, so MeshMonitor should detect the device platform and provide the appropriate workflow.
Conceptually:
MeshCore Device
│
├── ESP32
│ └── Start OTA
│ └── OTA Wi-Fi / firmware upload
│
├── nRF52
│ └── Start OTA
│ └── Bluetooth DFU
│
└── Unsupported Platform
└── Manual flashing instructions
For example:
Device:
Summit Relay
Protocol:
MeshCore
Platform:
ESP32
Installed:
1.x.x
Latest:
1.x.x
OTA:
Supported
[Update Firmware]
Or:
Device:
Lake Node
Protocol:
MeshCore
Platform:
nRF52
Installed:
1.x.x
Latest:
1.x.x
Update Method:
Bluetooth DFU
[Start Firmware Update]
The implementation does not necessarily need to fully automate every MeshCore workflow on day one.
For example, an initial MeshCore implementation could provide:
MeshCore Firmware Update
Device:
Summit Relay
Platform:
ESP32
Step 1:
Firmware downloaded and verified.
Step 2:
MeshMonitor has placed the device into OTA mode.
Step 3:
Connect to the device OTA network.
Step 4:
Upload the firmware.
[Start OTA]
Later, if MeshMonitor can safely automate more of the transport process, the workflow could become increasingly integrated.
For nRF52 devices, MeshMonitor could initially trigger DFU mode and provide the appropriate firmware package, even if the actual BLE transfer must initially be completed using an external DFU-capable application.
That would still be a major improvement because MeshMonitor would already handle:
- Device identification
- Firmware version detection
- Firmware compatibility
- Correct firmware selection
- Firmware download
- OTA/DFU initiation
- Post-update version verification
MeshCore Roles
MeshCore firmware can also vary depending on the device role.
The Firmware Manager should therefore account for the role/build when determining the correct firmware.
For example:
Protocol:
MeshCore
Device:
Cedar Relay
Hardware:
Supported ESP32 Device
Role:
Repeater
Installed:
1.x.x
Available:
1.x.x Repeater
Compatibility:
Verified
[Update Firmware]
A repeater should not accidentally receive companion firmware, and a companion device should not receive repeater firmware unless the administrator explicitly intends to change its role.
If MeshMonitor cannot confidently determine the role:
Firmware Update Blocked
MeshMonitor detected the hardware but could not verify the required MeshCore firmware role.
Current Role:
Unknown
Automatic firmware selection has been disabled.
[View Details]
Firmware Dashboard
There could be a centralized page such as:
or:
Devices → Firmware Updates
This page could show all devices managed by the current MeshMonitor installation.
For example:
| Device |
Protocol |
Hardware |
Installed |
Available |
Method |
Status |
| Ridge Relay |
Meshtastic |
Heltec V3 |
2.x.x |
2.x.x |
OTA |
Update Available |
| Harbor Gateway |
MeshCore |
ESP32 |
1.x.x |
1.x.x |
OTA |
Update Available |
| Pine Gateway |
Meshtastic |
RAK4631 |
2.x.x |
2.x.x |
DFU |
Current |
| Summit Relay |
MeshCore |
nRF52 |
1.x.x |
1.x.x |
DFU |
Update Available |
| Field Node 7 |
Meshtastic |
Unknown |
2.x.x |
2.x.x |
Manual |
Unsupported |
| Cedar Relay |
MeshCore |
ESP32 |
1.x.x |
1.x.x |
OTA |
Current |
This would make it easy to understand firmware health across an entire MeshMonitor installation.
Firmware Summary
At the top of the page:
Firmware Status
14 Managed Devices
8 Up to Date
4 Updates Available
1 Manual Update Required
1 Unknown Firmware
And optionally split by protocol:
Meshtastic
7 Devices
2 Updates Available
MeshCore
7 Devices
2 Updates Available
Device Firmware Section
Firmware information could also appear directly on each device page.
Example:
Firmware
Device:
Ridge Relay
Protocol:
Meshtastic
Hardware:
Heltec V3
Installed:
2.x.x
Latest Stable:
2.x.x
Release Channel:
Stable
Update Method:
OTA
Status:
Update Available
[Release Notes] [Update Firmware]
MeshCore example:
Firmware
Device:
Harbor Gateway
Protocol:
MeshCore
Hardware:
ESP32
Role:
Repeater
Installed:
1.x.x
Latest:
1.x.x
Update Method:
OTA
Status:
Update Available
[Release Notes] [Update Firmware]
If the device is current:
Firmware
Installed:
2.x.x
Latest:
2.x.x
Status:
Up to date
If automatic updating is unavailable:
Firmware
Installed:
1.x.x
Latest:
1.x.x
Automatic Update:
Unavailable
Reason:
Current device/transport does not support an update through MeshMonitor.
[View Manual Update Instructions]
Protocol Detection
MeshMonitor should automatically identify which firmware ecosystem applies to each managed device.
Possible values:
Meshtastic
MeshCore
Unknown
Firmware sources and compatibility rules should then be protocol-specific.
For example:
Device:
Birch Gateway
Protocol:
MeshCore
Firmware Source:
Official MeshCore releases
Hardware:
Detected
Role:
Detected
versus:
Device:
Oak Relay
Protocol:
Meshtastic
Firmware Source:
Official Meshtastic releases
Hardware:
Detected
This prevents firmware from one ecosystem ever being offered to a device from the other ecosystem.
Automatic Hardware Detection
The user should not have to manually select a firmware target whenever MeshMonitor already knows the device hardware.
For example:
Hardware detected:
HELTEC_V3
Protocol:
Meshtastic
Firmware target:
heltec-v3
Compatibility:
Verified
For MeshCore:
Hardware detected:
Supported ESP32 Board
Protocol:
MeshCore
Role:
Repeater
Firmware target:
ESP32 Repeater Build
Compatibility:
Verified
If the hardware cannot be confidently identified:
Unable to verify hardware target.
Automatic firmware update has been disabled for this device.
[View Device Information]
Again, never guess.
Release Channels
Where supported by the firmware ecosystem, MeshMonitor should allow the user to choose an appropriate firmware release channel.
For example:
Firmware Release Channel
(*) Stable
( ) Beta
( ) Alpha / Development
Stable should be the default.
Example:
Device:
Oak Relay
Protocol:
Meshtastic
Installed:
2.x.x
Stable:
2.x.x
Beta:
2.x.x-beta
Selected Channel:
Stable
[Update]
If a development channel is selected:
Warning
You selected a pre-release firmware channel.
Pre-release firmware may contain unfinished features, regressions, or compatibility issues.
[Cancel] [Continue]
MeshCore release-channel behavior may differ from Meshtastic, so the manager should expose only channels that actually exist for the selected ecosystem rather than assuming both projects use identical release structures.
Firmware Source
MeshMonitor should clearly indicate the firmware source.
For example:
Protocol:
Meshtastic
Firmware Source:
Official Meshtastic release
Or:
Protocol:
MeshCore
Firmware Source:
Official MeshCore release
This is particularly important because firmware flashing can render a device temporarily or permanently unavailable if the wrong image is installed.
Optional Custom Firmware
A future advanced feature could allow users to upload custom firmware.
For example:
Firmware Source
(*) Official Release
( ) Upload Custom Firmware
Custom firmware should require an explicit warning:
Custom Firmware
Warning:
This firmware was supplied manually and may not be verifiable against the official firmware catalog.
Installing incompatible firmware could make the device unavailable.
[Cancel] [Continue]
Custom firmware support would not need to be part of the initial implementation.
Pre-Update Validation
Before beginning a firmware update, MeshMonitor should perform all checks available for that device.
Possible checks include:
- Device is currently reachable
- Protocol is known
- Hardware target is known
- Device role is known when required
- Correct firmware artifact is available
- Firmware matches the detected hardware
- Firmware matches the detected protocol
- Firmware matches the device role
- OTA/DFU is supported by the hardware
- Current transport supports the update process
- Device has sufficient power
- Device has sufficient free flash/storage if applicable
- Firmware integrity has been verified
- Upgrade path is supported
- Current connection has been stable
- Configuration backup has completed when enabled
Example:
Firmware Update Check
Device:
Ridge Relay
Protocol:
Meshtastic
Hardware:
Heltec V3
Current:
2.x.x
Installing:
2.x.x
Protocol Match:
✓ Verified
Hardware Match:
✓ Verified
Firmware Integrity:
✓ Verified
Connection:
✓ Ready
Power:
✓ External Power
Configuration Backup:
✓ Complete
[Cancel] [Start Update]
MeshCore example:
Firmware Update Check
Device:
Harbor Gateway
Protocol:
MeshCore
Hardware:
ESP32
Role:
Repeater
Current:
1.x.x
Installing:
1.x.x
Protocol Match:
✓ Verified
Hardware Match:
✓ Verified
Role Match:
✓ Verified
OTA Support:
✓ Available
Firmware Integrity:
✓ Verified
[Cancel] [Start Update]
Configuration Backup Before Updating
Before performing a firmware update, MeshMonitor could optionally create a backup of device configuration that it is already authorized to access.
For Meshtastic this could include applicable items such as:
- Device configuration
- LoRa configuration
- Channels
- Module configuration
- Owner information
- Position settings
- Network settings
For MeshCore this could include whatever configuration can safely and appropriately be exported through its supported management interface.
Example:
Before updating:
[x] Back up supported device configuration
Device:
Silver Relay
Protocol:
Meshtastic
Firmware:
2.x.x
The backup should be associated with the device identity and firmware version.
Sensitive information should not be unnecessarily exposed in logs or UI output.
Update Confirmation
Firmware flashing should always require explicit confirmation.
Example:
Update Firmware?
Device:
Silver Relay
Protocol:
Meshtastic
Hardware:
Supported ESP32 Device
Current:
2.x.x
Installing:
2.x.x
The device will reboot during this process.
Do not disconnect power while the firmware is being installed.
[Cancel] [Update Firmware]
MeshCore example:
Update Firmware?
Device:
Cedar Relay
Protocol:
MeshCore
Hardware:
nRF52
Role:
Repeater
Current:
1.x.x
Installing:
1.x.x
The device will enter DFU mode and temporarily disconnect.
[Cancel] [Update Firmware]
Firmware Download
MeshMonitor should obtain firmware from the appropriate official firmware source whenever possible.
Conceptually:
Checking firmware catalog...
↓
Identifying protocol...
↓
Detecting hardware...
↓
Detecting role...
↓
Selecting firmware...
↓
Downloading firmware...
↓
Verifying firmware...
↓
Preparing device...
↓
Starting OTA/DFU...
The user should not normally need to manually search release pages and determine which binary or ZIP belongs to the device.
Firmware Integrity
Firmware downloaded by MeshMonitor should be verified whenever the official firmware source provides a checksum, hash, signature, or equivalent integrity metadata.
Example:
Firmware:
firmware-device-version.bin
Source:
Official Release
Integrity:
✓ Verified
If verification fails:
Firmware Verification Failed
The downloaded firmware could not be verified and will not be installed.
[Retry Download]
Connection-Aware Updating
A device being visible in MeshMonitor is not the same thing as having an update-capable connection to that device.
MeshMonitor should distinguish between:
Directly Connected
Update-Capable Connection
Directly Connected
Update Unsupported
Remote Mesh Node
No Firmware Transport
Unknown Connection
For example:
Device:
Remote Hill Node
Protocol:
Meshtastic
Firmware:
2.x.x
Update Available:
Yes
Automatic Update:
Unavailable
Reason:
This device is visible through the LoRa mesh but does not have a directly supported firmware-update transport.
Or:
Device:
Remote Valley Relay
Protocol:
MeshCore
Firmware:
1.x.x
Update Available:
Yes
Automatic Update:
Unavailable
Reason:
The node is reachable through the mesh, but MeshMonitor does not currently have a supported firmware-transfer path to the device.
Do Not Send Firmware Across the LoRa Mesh
This feature should not treat ordinary mesh visibility as permission or capability to transfer a firmware image across LoRa.
The goal is not to create firmware-over-LoRa.
The goal is to use the official/supported firmware update mechanisms available for devices that MeshMonitor can manage through an appropriate update-capable transport.
Possible statuses:
OTA Supported
DFU Supported
Manual Update Required
Remote Mesh Node
Transport Unsupported
Unknown
This distinction is important for both Meshtastic and MeshCore.
Meshtastic Update Methods
Different Meshtastic hardware platforms may require different update mechanisms.
Possible platforms include:
- ESP32 family
- nRF52 family
- RP2040/RP2350 family
- Other supported targets
The UI should abstract those differences.
The user should ideally see:
while MeshMonitor determines the supported mechanism.
Conceptually:
Meshtastic
│
├── ESP32
│ └── Supported OTA mechanism
│
├── nRF52
│ └── DFU package / supported DFU workflow
│
├── RP2040/RP2350
│ └── Supported update mechanism or manual flash
│
└── Other
└── Appropriate supported method
If a platform cannot currently be updated automatically, MeshMonitor should still show firmware status and provide manual-update guidance.
MeshCore ESP32 OTA
MeshCore's existing ESP32 OTA implementation can start a temporary Wi-Fi OTA network and expose a firmware-update endpoint.
MeshMonitor could integrate this in stages.
Initial Integration
Device:
Harbor Relay
Protocol:
MeshCore
Platform:
ESP32
Firmware:
Update Available
[Prepare OTA Update]
After clicking:
Preparing MeshCore OTA...
✓ Correct firmware selected
✓ Firmware downloaded
✓ Firmware verified
✓ Device placed into OTA mode
Next:
Connect to the device's OTA Wi-Fi network and continue the update.
[Continue]
Future Fully Integrated Flow
If technically feasible from the MeshMonitor host:
Preparing device...
✓
Connecting to OTA interface...
✓
Uploading firmware...
██████████████░░░░░░ 70%
The implementation should use the existing MeshCore OTA behavior rather than requiring a completely new updater protocol.
MeshCore nRF52 DFU
MeshCore also supports OTA/DFU workflows for supported nRF52 devices.
MeshMonitor could initially provide:
Device:
Lake Relay
Protocol:
MeshCore
Platform:
nRF52
Firmware:
Update Available
[Prepare DFU Update]
Then:
DFU Ready
✓ Correct firmware package downloaded
✓ Firmware verified
✓ Device placed into DFU mode
Firmware File:
Ready
Complete the Bluetooth DFU transfer using a compatible DFU client.
[Download Firmware] [Recovery Instructions]
If MeshMonitor later gains the ability to perform the BLE DFU transfer directly from the host, this could become:
Entering DFU...
✓
Connecting...
✓
Uploading firmware...
████████████████░░░░ 82%
The UI architecture should therefore allow partial and full automation depending on what the host platform can support.
MeshCore OTA Reliability
MeshMonitor does not need to manage bootloaders automatically in the first implementation, but it could detect when a device may not meet recommended OTA prerequisites and warn the administrator.
For example:
OTA Compatibility Warning
Device:
Lake Relay
Protocol:
MeshCore
Platform:
nRF52
MeshMonitor cannot verify that this device has the recommended OTA-capable bootloader configuration.
The update may require physical recovery if DFU fails.
[Cancel] [Continue]
OTA / DFU Progress
Updates should display clear progress.
For example:
Updating Ridge Relay
Protocol:
Meshtastic
Firmware:
2.x.x → 2.x.x
Downloading firmware...
100%
Verifying firmware...
✓
Preparing device...
✓
Uploading firmware...
████████████████░░░░ 82%
Do not disconnect the device.
Then:
Firmware uploaded.
Waiting for device to reboot...
Then:
Device detected.
Reconnecting...
Then:
Firmware Update Complete
Device:
Ridge Relay
Protocol:
Meshtastic
Previous:
2.x.x
Current:
2.x.x
Status:
Connected
[Done]
MeshCore should use the same overall user experience:
Updating Harbor Relay
Protocol:
MeshCore
Firmware:
1.x.x → 1.x.x
Firmware verified...
✓
OTA mode started...
✓
Uploading...
██████████████████░░ 90%
Waiting for reboot...
MeshMonitor should not report success simply because a firmware file finished transferring.
Ideally it should wait for the device to:
- Reboot
- Reconnect
- Report its firmware version
- Match the expected installed version
Update State Machine
The firmware manager could use explicit stages such as:
Checking
↓
Identifying Protocol
↓
Identifying Hardware
↓
Identifying Role
↓
Selecting Firmware
↓
Downloading
↓
Verifying
↓
Preparing Device
↓
Entering OTA / DFU
↓
Uploading
↓
Verifying Flash
↓
Rebooting
↓
Reconnecting
↓
Verifying Firmware Version
↓
Complete
The UI should clearly indicate where a failure occurred.
For example:
Firmware Update Failed
Device:
Oak Gateway
Stage:
Reconnecting
Firmware transfer completed, but MeshMonitor has not been able to reconnect to the device.
Possible causes:
- Device is still rebooting
- Transport changed after reboot
- Device entered bootloader/recovery mode
- Firmware failed to start
[Retry Connection] [View Recovery Instructions]
Preserve Device Identity and Configuration
A normal update should not unexpectedly change device identity or erase configuration unless the selected firmware/update path explicitly requires it.
MeshMonitor could compare basic identity information before and after the update.
For example:
Before Update
Device Identity:
Detected
Protocol:
Meshtastic
Hardware:
Heltec V3
After Update
Device Identity:
Matches
Protocol:
Meshtastic
Hardware:
Heltec V3
✓ Identity Verified
If the device reconnects with unexpected identity information:
Device Identity Changed
MeshMonitor detected a device after the firmware update, but its identity does not match the device that was updated.
Automatic configuration restore has been stopped.
[View Details]
MeshMonitor should never automatically restore a configuration backup to an unidentified device.
Firmware Notifications
MeshMonitor could optionally notify administrators when updates become available.
For example:
Firmware Update Available
Device:
Birch Relay
Protocol:
Meshtastic
Installed:
2.x.x
Available:
2.x.x
or:
Firmware Update Available
Device:
Stone Gateway
Protocol:
MeshCore
Installed:
1.x.x
Available:
1.x.x
Possible notification preferences:
Firmware Notifications
[x] Stable firmware updates
[ ] Pre-release firmware updates
[x] Meshtastic updates
[x] MeshCore updates
Firmware Update Badge
Devices with outdated firmware could show a badge directly in device lists.
For example:
Ridge Relay
Meshtastic
2.x.x
[Update Available]
or:
Harbor Relay
MeshCore
1.x.x
[Update Available]
Bulk Firmware Status
For installations with many devices:
Firmware Status
18 Devices
11 Up to Date
5 Updates Available
1 Manual Update Required
1 Unknown
Filter options could include:
Protocol:
[All ▼]
Status:
[All ▼]
Update Method:
[All ▼]
Possible filters:
- Meshtastic
- MeshCore
- Update Available
- Up to Date
- OTA Supported
- DFU Supported
- Manual Update Required
- Remote Mesh Node
- Unknown
Bulk Updates
A future enhancement could allow multiple directly connected/update-capable devices to be selected.
Firmware updates should preferably run sequentially, not blindly in parallel.
For example:
Update Selected Devices
4 devices selected.
Update Mode:
Sequential
1. Ridge Relay
2. Harbor Gateway
3. Pine Gateway
4. Summit Relay
[Cancel] [Begin Updates]
Then:
Firmware Update Queue
✓ Ridge Relay Complete
→ Harbor Gateway Updating...
○ Pine Gateway Waiting
○ Summit Relay Waiting
This would reduce the risk of taking several important devices offline simultaneously.
Critical Device Protection
Some nodes may perform important functions such as:
- Gateway
- Router/repeater
- MQTT bridge
- Remote-site uplink
- Important coverage relay
- Infrastructure node
MeshMonitor could allow an administrator to mark a device as:
When attempting to update it:
Warning: Critical Device
Harbor Gateway is marked as a critical device.
Updating firmware will temporarily take this device offline.
[Cancel] [Continue]
This would be especially useful for installations where losing one gateway or relay temporarily could affect large portions of the deployment.
Never Automatically Flash Without Permission
Firmware checking and firmware installation should be treated differently.
Recommended default:
Automatically check for updates:
Yes
Automatically install firmware:
No
MeshMonitor should never silently flash firmware by default.
Firmware installation should normally require explicit administrator action.
Scheduled Updates
A future enhancement could allow firmware updates to be scheduled.
For example:
Schedule Firmware Update
Device:
Silver Gateway
Protocol:
Meshtastic
Version:
2.x.x
Install:
3:00 AM
[Cancel] [Schedule]
Before the scheduled update begins, MeshMonitor should repeat all compatibility, connection, firmware, and power checks.
If the device is no longer safely updateable:
Scheduled Firmware Update Skipped
Reason:
Device connection is no longer suitable for OTA.
No firmware was installed.
Firmware Compatibility
MeshMonitor should never assume that the newest firmware release is automatically compatible with every device.
Checks may include:
- Protocol
- Hardware target
- MCU/platform
- Device role
- Firmware artifact type
- Minimum bootloader requirement
- Required partition layout
- Upgrade-path limitations
- Firmware metadata compatibility
- Special device requirements
If compatibility cannot be verified:
Firmware Update Blocked
MeshMonitor could not verify that this firmware is compatible with the selected device.
Automatic flashing has been disabled.
[View Details]
Firmware History
MeshMonitor could keep a local firmware update history.
For example:
Firmware History - Ridge Relay
2026-09-14
Meshtastic
2.x.x → 2.x.x
Method: OTA
Status: Successful
2026-08-27
Meshtastic
2.x.x → 2.x.x
Method: OTA
Status: Successful
MeshCore example:
Firmware History - Harbor Gateway
2026-09-14
MeshCore
1.x.x → 1.x.x
Method: OTA
Status: Successful
The history could record:
- Date/time
- Device
- Protocol
- Hardware
- Role
- Previous firmware
- Installed firmware
- Release channel
- Update method
- Result
Sensitive configuration information should not appear in normal firmware logs.
Firmware Update Logs
Detailed troubleshooting logs could show:
Firmware Update Log
Device:
Ridge Relay
Protocol:
Meshtastic
Hardware:
Heltec V3
From:
2.x.x
To:
2.x.x
Method:
OTA
Result:
Successful
Stages:
✓ Firmware metadata retrieved
✓ Protocol verified
✓ Hardware verified
✓ Firmware downloaded
✓ Firmware integrity verified
✓ Device prepared
✓ Firmware transferred
✓ Device rebooted
✓ Device reconnected
✓ Firmware version verified
MeshCore example:
Firmware Update Log
Device:
Harbor Relay
Protocol:
MeshCore
Platform:
ESP32
Role:
Repeater
Method:
OTA
Result:
Successful
Stages:
✓ Protocol verified
✓ Hardware verified
✓ Role verified
✓ Firmware downloaded
✓ Firmware verified
✓ OTA mode entered
✓ Firmware uploaded
✓ Device rebooted
✓ Device reconnected
✓ Firmware version verified
Recovery
Firmware updates can fail, so recovery should be considered part of the feature from the beginning.
Example:
Firmware Update Recovery
Device:
Pine Gateway
Protocol:
Meshtastic
The firmware update did not complete successfully.
Last successful stage:
Firmware Upload
Current state:
Bootloader detected
Available options:
[Retry Firmware Update]
[View Recovery Instructions]
MeshCore example:
Firmware Update Recovery
Device:
Lake Relay
Protocol:
MeshCore
Platform:
nRF52
The DFU transfer did not complete successfully.
Available options:
[Retry DFU]
[Download Firmware Package]
[View Recovery Instructions]
MeshMonitor should only offer recovery actions that are actually supported by the hardware.
Optional Rollback
Where supported by the device/update mechanism, a future enhancement could provide rollback.
For example:
Firmware History
Current:
2.x.x
Previous:
2.x.x
[Rollback]
If unsupported:
Rollback:
Not supported by this device
MeshMonitor should never imply that rollback is available when the underlying hardware or bootloader cannot provide it safely.
Search and Filtering
The Firmware Manager could include search and filtering.
For example:
Search Devices:
[________________________]
Protocol:
[All ▼]
Firmware Status:
[All ▼]
Update Method:
[All ▼]
Possible filters:
- Meshtastic
- MeshCore
- Up to Date
- Update Available
- OTA
- DFU
- Manual Update
- Unknown
- Failed Update
- Critical Device
Release Notes / Changelog
Before installing an update, MeshMonitor could show the release notes.
For example:
Firmware Update
Current:
2.x.x
Available:
2.x.x
Release Notes:
- Fixes
- Improvements
- New features
- Known issues
[Cancel] [Install Update]
This would be especially useful when deciding whether to update critical infrastructure.
Manual Update Fallback
Even when MeshMonitor cannot perform the update itself, it should still provide useful information.
For example:
Firmware Update Available
Device:
Remote Field Node
Protocol:
MeshCore
Installed:
1.x.x
Available:
1.x.x
Automatic Update:
Not Supported
Reason:
No supported firmware update transport is available.
[Download Correct Firmware] [View Instructions]
The important improvement is that MeshMonitor has already identified the correct protocol, hardware, role, and firmware file.
This still eliminates much of the manual work.
Describe alternatives you've considered
Currently firmware updates require administrators to use the existing firmware-management tools separately from MeshMonitor.
Depending on the protocol and hardware, this may involve:
- Meshtastic iOS or Android applications
- Meshtastic web flasher
- USB/serial flashing
- BLE DFU
- UF2 flashing
- Platform-specific flashing utilities
- MeshCore configuration tools
- MeshCore web flasher
- MeshCore OTA mode
- MeshCore ESP32 OTA Wi-Fi workflow
- MeshCore nRF52 DFU workflow
- Downloading firmware manually
- Determining the correct hardware target manually
- Determining the correct MeshCore role manually
- Checking release versions manually
- Physically accessing nodes
- Returning to MeshMonitor afterward to verify whether the device came back online
These existing tools should remain available and MeshMonitor should use official update mechanisms rather than replacing them with incompatible custom protocols.
However, requiring separate management tools makes the workflow fragmented.
If MeshMonitor is already the central dashboard for a collection of Meshtastic and MeshCore devices, firmware status and firmware management are a natural extension of that functionality.
Another alternative would be to initially implement firmware update detection only.
For example:
Firmware Update Available
[Download Firmware]
[Open Flashing Instructions]
That would already be useful and could serve as the first development phase.
Full OTA/DFU support could then be added incrementally for hardware and transports where it can be implemented safely.
Suggested Implementation Phases
A staged implementation could be:
Phase 1:
Detect Meshtastic and MeshCore firmware versions.
Phase 2:
Show available firmware updates.
Phase 3:
Automatically identify protocol, hardware, and MeshCore role.
Phase 4:
Automatically select the correct firmware artifact.
Phase 5:
Download and verify official firmware from the appropriate project.
Phase 6:
Add update-preparation workflows and manual flashing fallback.
Phase 7:
Implement Meshtastic OTA/DFU for supported hardware/transports.
Phase 8:
Implement MeshCore ESP32 OTA integration.
Phase 9:
Implement MeshCore nRF52 DFU integration where technically possible.
Phase 10:
Add configuration backup and post-update verification.
Phase 11:
Add firmware notifications and update history.
Phase 12:
Add sequential bulk updates.
Phase 13:
Add scheduled updates.
Phase 14:
Add rollback/recovery features where supported.
This would allow the feature to provide immediate value without requiring universal OTA support from the first release.
Additional context
The goal is to make firmware management a first-class part of MeshMonitor for both supported mesh ecosystems.
Today the workflow may look like:
Notice outdated firmware
↓
Determine protocol
↓
Determine hardware
↓
Determine device role
↓
Leave MeshMonitor
↓
Find firmware release
↓
Find correct firmware artifact
↓
Open another application/tool
↓
Enter OTA / DFU / flash mode
↓
Flash firmware
↓
Wait for reboot
↓
Return to MeshMonitor
↓
Check whether device reconnected
↓
Verify firmware manually
The desired workflow would instead be:
MeshMonitor detects update
↓
Select device
↓
Protocol detected
↓
Hardware detected
↓
Role detected
↓
Firmware selected automatically
↓
Compatibility verified
↓
Click Update
↓
Correct OTA / DFU mechanism used
↓
Device reboots
↓
MeshMonitor reconnects
↓
Firmware version verified
↓
Complete
Possible Firmware Manager Layout
Firmware Updates
[All] [Meshtastic] [MeshCore] [Updates] [History]
--------------------------------------------------
Ridge Relay
Protocol: Meshtastic
Hardware: Heltec V3
Installed: 2.x.x
Available: 2.x.x
Method: OTA
Status: Update Available
[Release Notes] [Update]
--------------------------------------------------
Harbor Gateway
Protocol: MeshCore
Hardware: ESP32
Role: Repeater
Installed: 1.x.x
Available: 1.x.x
Method: OTA
Status: Update Available
[Release Notes] [Update]
--------------------------------------------------
Pine Gateway
Protocol: Meshtastic
Hardware: RAK4631
Installed: 2.x.x
Available: 2.x.x
Status: Up to Date
--------------------------------------------------
Lake Relay
Protocol: MeshCore
Hardware: nRF52
Role: Repeater
Installed: 1.x.x
Available: 1.x.x
Method: DFU
Status: Update Available
[Prepare DFU]
--------------------------------------------------
Remote Field Node
Protocol: MeshCore
Installed: 1.x.x
Available: 1.x.x
Status: Manual Update Required
[Download Firmware] [Instructions]
Possible Update Details
Firmware Update
Device:
Harbor Gateway
Protocol:
MeshCore
Hardware:
ESP32
Role:
Repeater
Installed:
1.x.x
Available:
1.x.x
Firmware Source:
Official MeshCore release
Update Method:
OTA
Compatibility:
✓ Protocol
✓ Hardware
✓ Role
✓ Firmware
✓ Transport
Configuration Backup:
Enabled
[Cancel] [Update Firmware]
Possible Global Settings
Firmware Settings
Update Checking:
[x] Check for firmware updates automatically
Protocols:
[x] Meshtastic
[x] MeshCore
Notifications:
[x] Stable updates
[ ] Pre-release updates
Installation:
[ ] Automatically install updates
Default:
Automatic installation disabled
Important Scope
This feature should not mean:
- Flash arbitrary remote nodes simply because they appear in the mesh
- Send large firmware images through ordinary LoRa messaging
- Guess firmware targets
- Guess MeshCore roles
- Install firmware without administrator permission
- Automatically flash unsupported hardware
- Use unofficial firmware without clearly identifying it
- Hide platform-specific risks
Instead, the feature should:
- Detect
- Validate
- Inform
- Select
- Verify
- Update when safely supported
- Provide manual fallback when not supported
- Verify the device afterward
Main Goal
The main goal is to make Meshtastic and MeshCore firmware management native to MeshMonitor.
From inside MeshMonitor, administrators should be able to:
Detect
↓
Compare
↓
Select
↓
Verify
↓
Download
↓
Update
↓
Reboot
↓
Reconnect
↓
Confirm
MeshMonitor should know:
- Which protocol the device uses
- Which hardware it uses
- Which role/build it needs
- Which firmware is currently installed
- Which firmware is available
- Which update mechanism is supported
- Whether the current transport can perform the update
- Whether the firmware is compatible
- Whether the firmware transfer succeeded
- Whether the device successfully returned afterward
In short, MeshMonitor should provide a unified OTA Firmware Manager for both Meshtastic and MeshCore, allowing supported devices to be identified, checked for updates, matched with the correct firmware, updated using the appropriate official OTA/DFU mechanism, rebooted, reconnected, and verified without forcing the administrator to manually jump between multiple applications and flashing tools.
Is your feature request related to a problem? Please describe.
Yes. MeshMonitor can already serve as a centralized interface for monitoring and managing Meshtastic and MeshCore devices, but firmware updates still generally require leaving MeshMonitor and using another application, web flasher, DFU utility, USB flashing process, or other platform-specific method.
For users managing multiple nodes, especially nodes installed at different physical locations, this creates unnecessary additional work. A device may already be visible and manageable through MeshMonitor, but when a firmware update becomes available the administrator still needs to determine:
Both Meshtastic and MeshCore already have firmware-update mechanisms for supported hardware, although the exact process varies by platform and transport.
MeshMonitor could provide a single management layer over those existing mechanisms.
Instead of requiring the administrator to understand whether a device internally needs OTA, DFU, a temporary Wi-Fi access point, USB, UF2, serial flashing, or another mechanism, MeshMonitor could detect the protocol, hardware, role, firmware version, and connection method and then expose the safest supported update workflow.
The desired experience would be similar to the simplified firmware-update experience available in mobile applications: identify the device, identify the correct firmware, confirm the update, transfer it using the appropriate supported mechanism, reboot, reconnect, and verify that the expected firmware is running.
Describe the solution you'd like
I would like MeshMonitor to have a Firmware Update / OTA Manager for both Meshtastic and MeshCore.
The manager should be able to:
The user should not have to manually determine which firmware file belongs to a device when MeshMonitor already has enough information to determine that safely.
One Firmware Manager for Both Protocols
The Firmware Manager could abstract the underlying protocol-specific update mechanisms.
Conceptually:
From the user's perspective, the experience should remain consistent regardless of the underlying firmware platform.
For example:
Or:
The administrator should not need to manually understand every platform-specific flashing mechanism when MeshMonitor can determine the appropriate workflow.
Meshtastic Support
For Meshtastic devices, MeshMonitor could use the hardware and firmware information already exposed by the device to determine the appropriate firmware target and supported update method.
MeshMonitor should use official Meshtastic-supported update mechanisms rather than creating a separate firmware protocol.
Possible Meshtastic update states could include:
For example:
Or:
MeshMonitor should never guess the target firmware.
MeshCore Support
MeshCore should also be included in the same Firmware Manager.
MeshCore supports OTA/DFU workflows on supported hardware, but the exact method depends on the platform.
For supported ESP32 devices, the firmware can enter an OTA mode that exposes a temporary Wi-Fi access point and firmware upload interface.
For supported nRF52 devices, the firmware can enter a DFU workflow where the firmware package is transferred using a compatible DFU client.
The exact method depends on the hardware, so MeshMonitor should detect the device platform and provide the appropriate workflow.
Conceptually:
For example:
Or:
The implementation does not necessarily need to fully automate every MeshCore workflow on day one.
For example, an initial MeshCore implementation could provide:
Later, if MeshMonitor can safely automate more of the transport process, the workflow could become increasingly integrated.
For nRF52 devices, MeshMonitor could initially trigger DFU mode and provide the appropriate firmware package, even if the actual BLE transfer must initially be completed using an external DFU-capable application.
That would still be a major improvement because MeshMonitor would already handle:
MeshCore Roles
MeshCore firmware can also vary depending on the device role.
The Firmware Manager should therefore account for the role/build when determining the correct firmware.
For example:
A repeater should not accidentally receive companion firmware, and a companion device should not receive repeater firmware unless the administrator explicitly intends to change its role.
If MeshMonitor cannot confidently determine the role:
Firmware Dashboard
There could be a centralized page such as:
or:
This page could show all devices managed by the current MeshMonitor installation.
For example:
This would make it easy to understand firmware health across an entire MeshMonitor installation.
Firmware Summary
At the top of the page:
And optionally split by protocol:
Device Firmware Section
Firmware information could also appear directly on each device page.
Example:
MeshCore example:
If the device is current:
If automatic updating is unavailable:
Protocol Detection
MeshMonitor should automatically identify which firmware ecosystem applies to each managed device.
Possible values:
Firmware sources and compatibility rules should then be protocol-specific.
For example:
versus:
This prevents firmware from one ecosystem ever being offered to a device from the other ecosystem.
Automatic Hardware Detection
The user should not have to manually select a firmware target whenever MeshMonitor already knows the device hardware.
For example:
For MeshCore:
If the hardware cannot be confidently identified:
Again, never guess.
Release Channels
Where supported by the firmware ecosystem, MeshMonitor should allow the user to choose an appropriate firmware release channel.
For example:
Stable should be the default.
Example:
If a development channel is selected:
MeshCore release-channel behavior may differ from Meshtastic, so the manager should expose only channels that actually exist for the selected ecosystem rather than assuming both projects use identical release structures.
Firmware Source
MeshMonitor should clearly indicate the firmware source.
For example:
Or:
This is particularly important because firmware flashing can render a device temporarily or permanently unavailable if the wrong image is installed.
Optional Custom Firmware
A future advanced feature could allow users to upload custom firmware.
For example:
Custom firmware should require an explicit warning:
Custom firmware support would not need to be part of the initial implementation.
Pre-Update Validation
Before beginning a firmware update, MeshMonitor should perform all checks available for that device.
Possible checks include:
Example:
MeshCore example:
Configuration Backup Before Updating
Before performing a firmware update, MeshMonitor could optionally create a backup of device configuration that it is already authorized to access.
For Meshtastic this could include applicable items such as:
For MeshCore this could include whatever configuration can safely and appropriately be exported through its supported management interface.
Example:
The backup should be associated with the device identity and firmware version.
Sensitive information should not be unnecessarily exposed in logs or UI output.
Update Confirmation
Firmware flashing should always require explicit confirmation.
Example:
MeshCore example:
Firmware Download
MeshMonitor should obtain firmware from the appropriate official firmware source whenever possible.
Conceptually:
The user should not normally need to manually search release pages and determine which binary or ZIP belongs to the device.
Firmware Integrity
Firmware downloaded by MeshMonitor should be verified whenever the official firmware source provides a checksum, hash, signature, or equivalent integrity metadata.
Example:
If verification fails:
Connection-Aware Updating
A device being visible in MeshMonitor is not the same thing as having an update-capable connection to that device.
MeshMonitor should distinguish between:
For example:
Or:
Do Not Send Firmware Across the LoRa Mesh
This feature should not treat ordinary mesh visibility as permission or capability to transfer a firmware image across LoRa.
The goal is not to create firmware-over-LoRa.
The goal is to use the official/supported firmware update mechanisms available for devices that MeshMonitor can manage through an appropriate update-capable transport.
Possible statuses:
This distinction is important for both Meshtastic and MeshCore.
Meshtastic Update Methods
Different Meshtastic hardware platforms may require different update mechanisms.
Possible platforms include:
The UI should abstract those differences.
The user should ideally see:
while MeshMonitor determines the supported mechanism.
Conceptually:
If a platform cannot currently be updated automatically, MeshMonitor should still show firmware status and provide manual-update guidance.
MeshCore ESP32 OTA
MeshCore's existing ESP32 OTA implementation can start a temporary Wi-Fi OTA network and expose a firmware-update endpoint.
MeshMonitor could integrate this in stages.
Initial Integration
After clicking:
Future Fully Integrated Flow
If technically feasible from the MeshMonitor host:
The implementation should use the existing MeshCore OTA behavior rather than requiring a completely new updater protocol.
MeshCore nRF52 DFU
MeshCore also supports OTA/DFU workflows for supported nRF52 devices.
MeshMonitor could initially provide:
Then:
If MeshMonitor later gains the ability to perform the BLE DFU transfer directly from the host, this could become:
The UI architecture should therefore allow partial and full automation depending on what the host platform can support.
MeshCore OTA Reliability
MeshMonitor does not need to manage bootloaders automatically in the first implementation, but it could detect when a device may not meet recommended OTA prerequisites and warn the administrator.
For example:
OTA / DFU Progress
Updates should display clear progress.
For example:
Then:
Then:
Then:
MeshCore should use the same overall user experience:
MeshMonitor should not report success simply because a firmware file finished transferring.
Ideally it should wait for the device to:
Update State Machine
The firmware manager could use explicit stages such as:
The UI should clearly indicate where a failure occurred.
For example:
Preserve Device Identity and Configuration
A normal update should not unexpectedly change device identity or erase configuration unless the selected firmware/update path explicitly requires it.
MeshMonitor could compare basic identity information before and after the update.
For example:
If the device reconnects with unexpected identity information:
MeshMonitor should never automatically restore a configuration backup to an unidentified device.
Firmware Notifications
MeshMonitor could optionally notify administrators when updates become available.
For example:
or:
Possible notification preferences:
Firmware Update Badge
Devices with outdated firmware could show a badge directly in device lists.
For example:
or:
Bulk Firmware Status
For installations with many devices:
Filter options could include:
Possible filters:
Bulk Updates
A future enhancement could allow multiple directly connected/update-capable devices to be selected.
Firmware updates should preferably run sequentially, not blindly in parallel.
For example:
Then:
This would reduce the risk of taking several important devices offline simultaneously.
Critical Device Protection
Some nodes may perform important functions such as:
MeshMonitor could allow an administrator to mark a device as:
When attempting to update it:
This would be especially useful for installations where losing one gateway or relay temporarily could affect large portions of the deployment.
Never Automatically Flash Without Permission
Firmware checking and firmware installation should be treated differently.
Recommended default:
MeshMonitor should never silently flash firmware by default.
Firmware installation should normally require explicit administrator action.
Scheduled Updates
A future enhancement could allow firmware updates to be scheduled.
For example:
Before the scheduled update begins, MeshMonitor should repeat all compatibility, connection, firmware, and power checks.
If the device is no longer safely updateable:
Firmware Compatibility
MeshMonitor should never assume that the newest firmware release is automatically compatible with every device.
Checks may include:
If compatibility cannot be verified:
Firmware History
MeshMonitor could keep a local firmware update history.
For example:
MeshCore example:
The history could record:
Sensitive configuration information should not appear in normal firmware logs.
Firmware Update Logs
Detailed troubleshooting logs could show:
MeshCore example:
Recovery
Firmware updates can fail, so recovery should be considered part of the feature from the beginning.
Example:
MeshCore example:
MeshMonitor should only offer recovery actions that are actually supported by the hardware.
Optional Rollback
Where supported by the device/update mechanism, a future enhancement could provide rollback.
For example:
If unsupported:
MeshMonitor should never imply that rollback is available when the underlying hardware or bootloader cannot provide it safely.
Search and Filtering
The Firmware Manager could include search and filtering.
For example:
Possible filters:
Release Notes / Changelog
Before installing an update, MeshMonitor could show the release notes.
For example:
This would be especially useful when deciding whether to update critical infrastructure.
Manual Update Fallback
Even when MeshMonitor cannot perform the update itself, it should still provide useful information.
For example:
The important improvement is that MeshMonitor has already identified the correct protocol, hardware, role, and firmware file.
This still eliminates much of the manual work.
Describe alternatives you've considered
Currently firmware updates require administrators to use the existing firmware-management tools separately from MeshMonitor.
Depending on the protocol and hardware, this may involve:
These existing tools should remain available and MeshMonitor should use official update mechanisms rather than replacing them with incompatible custom protocols.
However, requiring separate management tools makes the workflow fragmented.
If MeshMonitor is already the central dashboard for a collection of Meshtastic and MeshCore devices, firmware status and firmware management are a natural extension of that functionality.
Another alternative would be to initially implement firmware update detection only.
For example:
That would already be useful and could serve as the first development phase.
Full OTA/DFU support could then be added incrementally for hardware and transports where it can be implemented safely.
Suggested Implementation Phases
A staged implementation could be:
This would allow the feature to provide immediate value without requiring universal OTA support from the first release.
Additional context
The goal is to make firmware management a first-class part of MeshMonitor for both supported mesh ecosystems.
Today the workflow may look like:
The desired workflow would instead be:
Possible Firmware Manager Layout
Possible Update Details
Possible Global Settings
Important Scope
This feature should not mean:
Instead, the feature should:
Main Goal
The main goal is to make Meshtastic and MeshCore firmware management native to MeshMonitor.
From inside MeshMonitor, administrators should be able to:
MeshMonitor should know:
In short, MeshMonitor should provide a unified OTA Firmware Manager for both Meshtastic and MeshCore, allowing supported devices to be identified, checked for updates, matched with the correct firmware, updated using the appropriate official OTA/DFU mechanism, rebooted, reconnected, and verified without forcing the administrator to manually jump between multiple applications and flashing tools.