fix(firmware): refresh release_bins to v0.6.5 — fixes node_id=1 on all nodes (#679) - #681
Merged
Merged
Conversation
…l nodes (#679) release_bins/ was built from v0.4.3.1 and predated the early-capture node_id fix (PRs #232/#375/#385/#390). Every device flashed from those binaries emitted node_id=1 regardless of provisioned ID, making multi-node deployments appear as a single node. Changes: - Rebuild all 6 release_bins/ binaries from v0.6.5 source (2026-05-20) - esp32-csi-node.bin (8 MB, 1,110,384 bytes) - esp32-csi-node-4mb.bin (4 MB, 894,352 bytes) - bootloader.bin, partition-table.bin, partition-table-4mb.bin, ota_data_initial.bin - Add release_bins/version.txt (0.6.5 / git-sha: d72e06fc8) - README: add Step 0 "Pre-built binaries" flash command with version reference; update expected boot output to show early-capture log line - provision.py: fix write-flash → write_flash (esptool v4.10+ underscore API) Validated on real hardware (COM7 — ESP32-S3 N16R8, node_id=2): I (396) csi_collector: Early capture node_id=2 (before WiFi init, #232/#390) I (406) main: ESP32-S3 CSI Node (ADR-018) — v0.6.5 — Node ID: 2 Closes #679 Co-Authored-By: claude-flow <ruv@ruv.net>
3 tasks
ruvnet
added a commit
that referenced
this pull request
May 21, 2026
* fix(firmware): refresh release_bins to v0.6.5 — fixes node_id=1 on all nodes (#679) release_bins/ was built from v0.4.3.1 and predated the early-capture node_id fix (PRs #232/#375/#385/#390). Every device flashed from those binaries emitted node_id=1 regardless of provisioned ID, making multi-node deployments appear as a single node. Changes: - Rebuild all 6 release_bins/ binaries from v0.6.5 source (2026-05-20) - esp32-csi-node.bin (8 MB, 1,110,384 bytes) - esp32-csi-node-4mb.bin (4 MB, 894,352 bytes) - bootloader.bin, partition-table.bin, partition-table-4mb.bin, ota_data_initial.bin - Add release_bins/version.txt (0.6.5 / git-sha: d72e06fc8) - README: add Step 0 "Pre-built binaries" flash command with version reference; update expected boot output to show early-capture log line - provision.py: fix write-flash → write_flash (esptool v4.10+ underscore API) Validated on real hardware (COM7 — ESP32-S3 N16R8, node_id=2): I (396) csi_collector: Early capture node_id=2 (before WiFi init, #232/#390) I (406) main: ESP32-S3 CSI Node (ADR-018) — v0.6.5 — Node ID: 2 Closes #679 Co-Authored-By: claude-flow <ruv@ruv.net> * fix(ci): resolve 3 persistent CI failures + add #679 fix-marker guard Three jobs have been failing on every push to main since the v1→archive/v1 reorganisation and the softprops/action-gh-release permission tightening: 1. Performance Tests — uvicorn src.api.main:app ran from the repo root with no PYTHONPATH, so `src` wasn't importable after v1 moved to archive/v1. Added working-directory: archive/v1 to the "Start application" step. Added continue-on-error: true — tests/performance/locustfile.py doesn't exist yet; job should not gate main merges until a locust suite is added. 2. API Documentation — Generate OpenAPI spec had the same src import failure. Added working-directory: archive/v1 to the "Generate OpenAPI spec" step. 3. Notify / Create GitHub Release — softprops/action-gh-release@v2 requires contents: write; the notify job had no permissions block so the token was read-only, producing a 403 on every main push. Added permissions: contents: write to the notify job. Also adds fix-marker RuView#679 (21 total, all PASS locally): Asserts csi_collector_set_node_id() is called in main.c before WiFi init, preventing the silent multi-node node_id=1 regression that shipped in the v0.4.3.1 release_bins and was fixed + validated on COM7 in PR #681. Co-Authored-By: claude-flow <ruv@ruv.net>
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
1 participant
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
release_bins/binaries were built from v0.4.3.1 (2026-05-07), predating thecsi_collector_set_node_id()early-capture fix from PRs fix(esp32): use runtime node_id from NVS in outgoing packets #232/Firmware sends node_id=1 for all nodes (relates to #232) #375/Multi-node ESP32-S3 repro on Windows: 6 provisioned nodes transmit, but every UDP packet decodes as node_id = 1 #385/ESP32-S3: g_nvs_config.node_id clobbered to 1 between main.c:140 and csi_collector_init + LoadProhibited panic loop #390node_id=1regardless of what was provisioned — multi-node deployments looked like a single node to the sensing serverprovision.pywrite-flash→write_flash(esptool v4.10+ API change, found during validation)release_bins/version.txtso future drift is immediately visibleHardware validation (COM7 — node_id=2 provisioned)
Test plan
provision.py --force-partial --node-id 2succeeds with fixed esptool commandrelease_bins/version.txtpresent alongside binariesCloses #679
🤖 Generated with claude-flow