[snekxs]

Summary

• Preserve the receiver's HID++ register 0xF1 bytes as diagnostics without interpreting them as a 14.x firmware version.
• Show firmware status as unknown when the receiver version has no verified decode, so the card cannot falsely claim the receiver is current or has an update.

Hardware evidence

On a PRO LIGHTSPEED receiver, G HUB updated firmware from 14.3.19 to 14.4.20 and reported success. Register 0xF1 returned the same MCU1 (01 07 02) and MCU2 (02 00 11) bytes before and after the flash. The receiver re-enumerated as 046D:AB24 during the update.

Verification

npm run build (TypeScript and Vite) passed locally.

Summary by CodeRabbit

• Bug Fixes
  • Receiver firmware status now shows as unknown when the receiver’s primary firmware details are unavailable, rather than indicating it is up to date.
  • Receiver diagnostics no longer interpret register data as a package version, helping avoid misleading firmware version comparisons. Raw register data remains available for diagnostics.

[cloudflare-workers-and-pages]

Deploying openmouse with    Cloudflare Pages

Latest commit:	26633a9
Status:	✅  Deploy successful!
Preview URL:	https://3ef2c4b5.openmouse.pages.dev
Branch Preview URL:	https://fix-logitech-receiver-f1-raw.openmouse.pages.dev

View logs

[snekxs]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: cac65674-2d97-487b-acdf-ee5146ff1766

---

📥 Commits

Reviewing files that changed from the base of the PR and between bb2b447 and 26633a9.

---

📒 Files selected for processing (2)

• src/app/cards/FirmwareCard.tsx
• src/device/controller.ts

---

Limit details: You’ve used all 10 included reviews currently available.

---

---

📝 Walkthrough

Walkthrough

The receiver firmware probe now treats register 0xF1 payload bytes as diagnostics rather than a package version, requires an explicit device index and parameters, and validates the first reply byte against the requested parameter. FirmwareCard reports an unknown status when the selected receiver MCU or version is missing.

Changes

Receiver firmware diagnostics

Layer / File(s)	Summary
Receiver register probe src/device/controller.ts	The probe requires an explicit device index and parameter list. It rejects replies whose first payload byte does not match the first requested parameter and returns version: null. Raw response bytes remain available for diagnostics.
Firmware status display src/app/cards/FirmwareCard.tsx	The receiver version is no longer described as a manifest-comparable package version. If the selected MCU or version is missing, the status pill shows fw.unknown before the up-to-date check.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: ydw1904

---

Merge Risk | ⚪ Minimal · up to 26633

Merge Risk: ⚪ Minimal · up to 26633

The receiver now avoids presenting unverified register bytes as a firmware version and reports an unknown status when version data is missing. No confirmed merge-blocking issue remains.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to 26633

The change prevents unverified receiver bytes from producing misleading firmware-update claims. It adds no external entrypoint, device-write privilege, or flashing capability. The response-format assumption remains unverified across receiver models, but rejected replies affect diagnostic and status availability rather than update authority.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — Within the traced receiver path, manipulated HID reply bytes can affect whether receiver diagnostics are retained, but can no longer supply a receiver package version to update-status comparison. No new device-write or cross-service authority follows from that input.

Trust Boundaries and Controls

• observed — The receiver-data interpretation boundary becomes more conservative: accepted device bytes remain diagnostic data with no decoded version. The existing response-header checks remain, and the head adds MCU-selector validation before retaining the payload.

Resilience and Maintainability Implications

• observed — Receiver state remains controller-owned, is cleared at probe initiation and disconnect, and is published only when the active device identity still matches. Read listeners clean up on response, timeout, or send failure. The PR does not change these lifecycle controls or add persistence.

---

Pre-merge checks | 4 | 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: preventing false receiver firmware version reporting.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

---

---

⚔️ Resolve merge conflicts 💡

• Resolve merge conflict in branch fix/logitech-receiver-f1-raw

---

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 2
• Waived: $0.50 (charged $0.00)
• View usage details

Note

This review exceeded your plan’s limits and used usage-based reviews—free during trial, billed after paid activation unless disabled. Manage usage-based reviews.

---

_{Comment @coderabbitai help to get the list of available commands.}

[jazzstack]

Closing in favor of #1225, which merged today and fixed the same root cause for the same device family (closes #1111).

Same conclusion as this PR: the register 0xF1 per-MCU readout is a bootloader identity, not an app version — the 14.3.19 → 14.4.20 flash evidence in this PR's description matches exactly what #1225 used. In the merged fix the receiver readout is shown as an informational bootloader row (labeled as such, with a note that no receiver update check runs yet) and produces no dfuInfo at all, so the card can neither claim "up to date" nor "update available" from those bytes.

Sorry this raced your PR — it predates it by two weeks and had passing checks. If you'd prefer the diagnostics-only framing from this PR kept in the card (raw register bytes surfaced outside the firmware verdict), the groundwork is all in place and I'd welcome a follow-up — happy to re-review.