Live Data
Real-time sensor readings from connected nodes
Time Range:
Waiting for data...
Connect your MQTT device to see live data
Connect your MQTT device to see live data
System Logs
Raw MQTT messages and system events
Historical Data
Query and visualize saved measurements
Metrics:
π‘οΈ ESP32 Secure OTA Manager
Deploy cryptographically signed firmware over W5500 Ethernet
π Transport: HTTPS + CA Pinning
π Authenticity: Secure Boot V2 (RSA-3072)
π‘οΈ Storage: AES-256-XTS Flash Encryption
β³ Lifecycle: Anti-Rollback Counter
πΎ Recovery: Dual Partition (ota_0 / ota_1)
1. Upload Signed Firmware (.bin)
π
Drag & drop signed ESP32 binary or
Validates ESP32 Header (0xE7), app descriptor (0xABCD5432) & SHA256
2. Target Node & Deployment
OTA Progress: Idle
IDLE
1. Trigger
2. Download
3. Verify
4. Flash
5. Reboot & Validate
0%
π Secure OTA Technical Manual & Deployment Workflow
Complete reference for compiling, validating, staging, and deploying firmware binaries wirelessly over Ethernet
βοΈ
1. Arduino IDE Compilation & Binary Export
- Open
ESP32_EXAMPLE/ESP32_EXAMPLE.inoin Arduino IDE. - Configure network credentials, MQTT credentials, and PZEM channel names in
secrets.h. - Select Tools -> Board -> ESP32 Dev Module.
- Select Tools -> Partition Scheme:
- Option A:
Minimal SPIFFS (1.9MB APP with OTA). - Option B (Custom): Select
Customand use the includedESP32_EXAMPLE/partitions.csvfile.
- Option A:
- Click Sketch -> Export Compiled Binary (Shortcut:
Ctrl + Alt + S). - Exact File to Upload: Open the sketch folder
build/esp32.esp32.esp32/and uploadESP32_EXAMPLE.ino.bin(~945 KB).
(Do NOT uploadmerged.binβthat is for USB flashing only!)
π‘οΈ
2. Dual-Partition Architecture & Anti-Bricking
- Partition Slots (ota_0 / ota_1): The ESP32 flash memory divides application space into two identical slots (~1.9 MB each).
- Zero-Downtime Download: The currently active partition continues executing the meter sampling loop without interruption while chunked firmware data streams into the passive partition.
- Power & Network Loss Resiliency: If an update is interrupted by a power brownout or Ethernet disconnect, the bootloader cancels the staging process and reboots safely into the original active partition. The board can never be bricked by a bad transfer.
- Rollback Validation: Upon first boot of new firmware,
SecureOTA.cppverifies sensor loop stability before marking the partition permanently valid.
π
3. Multi-Layer Binary Validation Protocol
- ESP32 Header Magic Byte: Verifies
0xE9 / 0xE7header to prevent flashing non-ESP32 files or corrupted data. - ESP-IDF App Descriptor: Reads segment offsets, entry point addresses, and compile timestamps from the image header (offset
0x20). - Streaming SHA-256 Checksum: As packets stream into flash over W5500 Ethernet, an on-the-fly SHA-256 digest is computed and matched against the server hash.
- Anti-Rollback Counter (SecVer): Compares firmware security version against internal eFuse / NVS counters. Downgrade attempts to older vulnerable binaries are automatically rejected.
- Session HMAC Tokens: MQTT trigger commands require time-bound cryptographic HMAC signatures generated by the Express server.
π‘
4. Staging, Deployment & Troubleshooting
- Staging & Validation: Drag & drop the
.binfile into Step 1 above. The web app validates binary magic bytes (0xE9 / 0xE7), calculates SHA-256, and extracts version details before staging. - Target Device Selection: Always test deployment on a single target ESP32 node (e.g.
Main_Panel_1) first before using the All Connected Nodes (Broadcast) option. - Live Telemetry Tracking: Monitor progress in real time on the progress bar and log box above. ESP32 devices report progress percentages back over MQTT (
sensor/pzem/+/ota/status). - Serial Monitor Debugging: Connect an FTDI / USB cable at
115200 baudto observe live bootloader logs:[SecureOTA] Active Partition: ota_0 | Validated.
π
5. Hardware Secure Boot v2 & Firmware Signing
- eFuse Hardware Protection: Secure Boot v2 verifies digital signatures against public keys burnt into ESP32 eFuses before allowing binary execution.
- Header Compatibility: Signed binaries maintain standard
0xE9header magic bytes at offset0; digital signature footers append to the end of the file. - Signing Helper Tool: Use
espsecure.pyor the included project script:python scripts/sign_firmware.py build/.../ESP32_EXAMPLE.ino.bin ota_key.pem - PrivateKey Safety: Private
.pemkeys must never be committed to Git repositories or exposed publicly.
β οΈ
Secure OTA Risks, Pro-Tips & Operational Notes
π¨ Critical Security & Hardware Risks:
- Permanent eFuse Key Burning: Once Secure Boot v2 eFuses are blown on an ESP32 chip, users CANNOT disable it or change the public key. Losing the private key permanently bricks future OTA updates!
- Unsigned Binary Rejection: Enabling Secure Boot on hardware will cause the bootloader to permanently reject unsigned binaries.
π‘ Pro-Tips for Safe Deployment:
- Key Backup: Always store three encrypted backups of
ota_key.pemin separate off-site secure locations. - Staging Hardware Test: Always keep 1 development ESP32 board in the lab to test binary uploads before pushing updates to live electrical panels.
π Important Operational Notes:
- Anti-Rollback Counter: Firmware compiled with a lower Security Version (e.g.
sec_ver: 1) will be rejected if the device is already runningsec_ver: 2. - Flash Size Requirement: Ensure the partition table reserves at least 1.9MB for each OTA slot when using dual-partition schemes.
Active Nodes
Connected: 0