meshtastic
[Feature Request]: Implement a Two-Stage, Remotely Triggered Firmware Update
Platform
ESP32, Linux Native, NRF52, RP2040
Description
I wanted to propose a two-stage flash update mechanism that separates the file transfer from the flashing command, with the actual application of the update being delivered from a admin protobuf message.
Stage 1: Stage the Firmware File
This stage is focused on getting the firmware onto the device safely.
A node owner would connect using one of the standard methods (HTTP web server, Bluetooth, or Web Serial). They would use an option in the client apps to stage the firmware bin file, this would effectively stage the fimrware update ready for later application. This would invovle the admin uploading a valid meshtastic firmware-*.bin file. The node's firmware saves this file to a dedicated "staging" partition on its flash memory and performs an integrity/signature check to validate it. Once verified, the node's screen could display "Update Ready" or it could report this "Ready" status back via a notification. The client connection can now be safely terminated. The update is now "armed."
Stage 2: Trigger the Flash via Admin Message
The flash operation is initiated only when the node receives a specific, authenticated Admin protobuf message. This command could be named something like applyStagedFirmware. An administrator can send this message from any client with admin privileges connected to the mesh (e.g., the Python API, a web UI, or a future mobile app feature). The message would be directed to the specific nodeId of the armed device.
Upon receiving and authenticating the applyStagedFirmware message, the target node will:
- Verify it has a valid staged firmware. Immediately begin the self-contained flashing process, copying the firmware from the staging partition to the application partition.
- Reboot into the new firmware version and reapply its configuration backup taken prior to the update occuring, this will result in it being able to rejoin the mesh with the same settings as before.
This workflow ensures the risky file transfer is done first, and the final, critical command to execute the flash is a tiny, reliable packet that can be sent at any time.
This seems pretty onerous. There are already platform specific OTA flash methods that follow the standards defined by their respective SDKs. ESP32 has Wifi (poorly documented) and BLE based OTA and NRF has BLE only.
Only ESP32.
Needs to flash first ota-wifi.bin to correct partition.
meshtastic --host 1.2.3.4 --reboot-ota
Sometimes it's a little hard
You need espota.py from (arduino) framework esp32.
python espota.py -i 1.2.3.4 -f firmware-update.bin
If you use static IP inside meshtastic. IP will change during OTA.
( only if you have problems to saving settings)
Reset LittleFS: You will lose settings. WiFi should work. Sometimes LittleFS was got corrupted...
python espota.py -i 1.2.3.4 -f littlefs-xxxx.bin --spiffs
Portuguese How To:
Só esp32. Verificar o address da vossa partição ota
flashApp, app, ota_1, 0x260000, 0x0A0000,
Source: https://github.com/meshtastic/firmware-ota-wifi
# 1
O primeiro passo:
Flashar partição OTA
esptool -b 460800 write_flash 0x260000 ota.bin
Flashar a ota.bin só via serial
# 2
Update da firmware principal via OTA wifi
Manter o ping em paralelo.
- ping 10.1.0.240 (ip atual)
- ping 10.1.0.40 (novo ip)
Adaptar ao vosso caso
# 2.1
meshtastic --host 10.1.0.240 --reboot-ota
Geralmente não aceita à primeira. Confirmar com o ping.
Quando o novo ip responder:
python espota.py -i 10.1.0.40 -f firmware.bin
# END
Compile yourself, if you don't trust in my files:
https://u.easyhan.pt/meshtastic/
Only use "firmware-esp32**-update.bin". Don't use "factory" versions. Don't replace main firmware with ota.bin (I have done that mistake 😅).
For me BLE ota never worked...
__
You can replace bleota.bin with wifiota.bin and use default scripts