Max

OTA Firmware Flow

Device registry → flash → self-test → commit or rollback.

OTA Firmware Flow (v2026-08-02T101544Z-ab2bbdebf5) 2026-08-01 | Device registry → flash → self-test → commit or rollback. 1 - DEVICE REGISTRY - Maintains device records DeviceRegistry add_device() lookup_by_mac() upsert_by_mac() 2 - FIRMWARE DOCTOR - Monitors and corrects firmware health FirmwareDoctor on_device_online() on_device_offline() on_ota_flashed() _watch_ota_reboot() report_telemetry() 3 - OTA MANAGER - Handles firmware updates OTAManager beginUpdate() lastError() OTARollback begin() _loadNvs() 1. DeviceRegistry adds or updates de… 2. FirmwareDoctor monitors device st… 3. FirmwareDoctor triggers OTA updat… 4. OTAManager begins firmware update… 5. OTARollback checks for rollback c… DeviceRegistry.add_device() payload {"device_id": "KV-1234", "name": "Blaine", "friendly_name": "Blaine", "hardware_class": "V3", "mac_address": "AA:BB:CC:D… OTAManager.beginUpdate() payload {"url": "https://example.com/firmware.bin"} FirmwareDoctor uses event_bus for communication with other components. OTARollback is not fully detailed in the source, so some steps are inferred. Legend actor = initiates work · process = code path · store = state on disk · bus = durable queue · dashed = separate process cyan = request flow · pink = state read/write · dashed green = pull / return path · red = refusal

Provenance

This drawing is generated, not drawn. It is rebuilt from the source files below, so when they change the picture changes — a diagram here cannot quietly describe a system that no longer works this way.

Owner
Max
Slug
ota-firmware-flow
Rendered
2026-08-02T101544Z
From commit
ab2bbdebf5
Watches
3 paths
  • daemon/src/firmware_doctor.py
  • daemon/src/device_registry.py
  • firmware/mx/lib/OTAManager