Merge beta into main#51
Conversation
Sync main to beta after #39
Matches the naming used by the AIR-1 firmware channel feature; "Stable" is clearer than "Main" for users who don't know the branch layout. Devices that stored "Main" fall back to the initial option, which is the same channel. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Rename Firmware Channel option Main to Stable
The rolling pre-release created a tag named "beta", colliding with the beta branch. git resolves a bare fetch refspec to refs/tags/ before refs/heads/, so ESPHome remote packages pinned to ref: beta silently fetch the tag (frozen at creation time) instead of the branch tip - users following beta as a package get stale YAML no matter how often they clean caches. Reproduced and confirmed on MSR-1, which inherited this pattern from CAST-1. Rename the release tag to beta-fw and update the manifest URLs to match. The old beta release/tag should be deleted after this merges and the renamed release is populated. Version: 26.7.8.1 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Rename rolling beta release tag to beta-fw (branch/tag collision)
esphome::select::Select::state is deprecated (removal slated for 2026.7.0) and the removal has now reached ESPHome beta, so the CI beta legs fail with "TemplateSelect has no member named 'state'". Replace the nine id(wizmote_action_*).state reads with .current_option() - same string, identical compiled behavior on stable. Same fix Core.yaml already got in fix/select-state-dev-compat; these uses arrived later with the WizMote feature. No version bump - rides with the unified PR's 26.7.12.1. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Fix ESPHome beta build: deprecated Select .state in wizmote.yaml
Aligns the live CAST-1 channel implementation with the pattern MSR-1 shipped as 26.7.9.1 (ApolloAutomation/MSR-1 #100/#103/#104), folding in the beta-channel-default wrapper work: - NEW: bluetooth_proxy + esp32_ble_tracker compile into both images; a "Bluetooth Proxy" switch (default off, persisted, re-applied at boot) starts/stops scanning at runtime. The existing CONFIG_BT_* sdkconfig options put BT allocations in PSRAM, keeping internal RAM free for the audio pipelines. - apply_ota_source is now re-applied at boot (on_boot -100) - previously a reboot left the update entity on its compile-time default source. URLs come from stable/beta manifest-base substitutions; the Type (WiFi/Ethernet) x Channel (Stable/Beta) cross is unchanged. - Firmware Update button upgraded from bare perform(true) to the standard flow (apply_ota_source + fetch window before perform) - http_request consolidated into Core.yaml and buffers raised to the proven sizes (rx 4096->5120 for GitHub's ~3.6KB CSP header line, tx 1024->2048 for the ~850-char signed-redirect query) - beta-channel/ wrappers default the select to Beta on beta builds (from the beta-channel-default branch); build-beta.yml builds them - version 26.7.12.1 Supersedes #46. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Unified firmware: runtime Bluetooth Proxy switch + channel fix set
|
Warning Review limit reached
Next review available in: 12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add an empty encryption: key to the api: block so ESPHome/HA provisions a per-device API key on adoption, matching MSR-1. Bump firmware version to 26.7.14.1. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
The label-check job in ci.yml duplicates label-check.yml and, because ci.yml runs on plain pull_request, always fails on fork-submitted PRs where the token is read-only and cannot apply labels. label-check.yml already handles this on pull_request_target. Drop the redundant job and the now-unneeded pull-requests/issues write permissions, matching the already-clean main on MSR-1 and CAST-1. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Remove duplicate label-check job from CI workflow
Enable API encryption
Auto-assign on fork PRs via pull_request_target
2 participants
Merge
betaintomain.Brings the current CAST-1 beta firmware to the stable channel. Notably includes:
.statein wizmote.yaml (Fix ESPHome beta build: deprecated Select .state in wizmote.yaml #49) —.statewas removed on the ESPHome beta/dev channel (deprecated on stable, slated for removal in 2026.7.0); switches to.current_option(). This is what's currently failing CI onmain.beta-fwto avoid branch/tag collision (Rename rolling beta release tag to beta-fw (branch/tag collision) #45)To merge after #48 and #50.
🤖 Generated with Claude Code