Add explicit Dig2Go peer firmware propagation - #72
Open
theysayheygreg wants to merge 8 commits into
Open
Conversation
added 8 commits
August 25, 2026 23:40
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds an explicitly commanded Dig2Go-to-Dig2Go update path, separate from ordinary laptop fleet OTA.
A controller starts one chosen seed with an exact-target
Fleet Update Propagatecommand:This is the same command path used by the five-device bench test. It starts the selected source directly; it does not enter ordinary OTA selection and does not require a button.
The chosen source then:
FleetUpdateOffer;TubesOTAnetwork for legacy-only sessions and a RAM-onlyTubes-<nonce>network for mixed modern turns; andA successfully updated modern receiver stores a durable, at-most-once baton before reboot. After reboot it receives one bounded propagation turn, allowing the update to continue without a post-reboot acknowledgment or laptop coordinator.
Ordinary server-backed fleet OTA remains the separate
Ycommand and does not implicitly start propagation.Physical evidence
Bench testing demonstrated:
Verification
bash test/tubes_mesh/run.shnode --test tools/fleet-update-protocol-test.jspio run -e esp32_quinled_dig2go_tubespio run -e esp32_quinled_dig2go_tubes_p2pgit diff --checkCoverage includes explicit propagation-command separation from ordinary OTA, legacy wire compatibility, rendezvous and host lifecycle, HTTP range serving, exact running-image inspection, target validation, two-receiver fanout, modern offer validation, lease claim/replay prevention, and failed-pull radio recovery.
The existing Python 3.14 50-client fleet-server test issue is unchanged and reproduces on
origin/main; this PR does not introduce it.Current limits