Repository navigation
Release 26.10.12.1 - All Lights entity, song switching fix, ESPHome 2026.10 build fix - #28
Merged
Merged
Conversation
Collapses every multi-line YAML comment across Core.yaml, H-3.yaml and H-3D.yaml to one line of roughly 5-8 words, matching the CAST-1 pass. Comment-only change: the expanded `esphome config` output is an identical line multiset before and after (the only textual difference is nondeterministic key ordering inside logger.log actions). Verified with esphome 2026.7.1: config valid on both variants, and `esphome compile H-3.yaml` succeeds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Chore/comment cleanup
Rtttl::play() returns early when a song is already running, so pressing a second button started the new LED effect while the old song kept playing. Each play_song_* script now stops playback before setting up the new song. Version 26.8.26.1 🤖 Generated with [Claude Code](https://claude.com/claude-code)
…w-press Stop the current song before starting a new one
Home Assistant exposed only the five zone partitions, so there was no way to control all 37 LEDs at once. Adds a sixth partition spanning 0-36 alongside the zones, leaving the parent chain internal. all_lights_off and both on_shutdown blocks clear it so the entity state matches the LEDs, and each play_song_* turns it off first so a running All Lights effect does not fight the zone effects writing the same buffer. Version 26.8.26.2 🤖 Generated with [Claude Code](https://claude.com/claude-code)
H-3 had no entity reporting which firmware it is running, and its ESPHome Version was disabled_by_default so nobody saw it. Matches the pattern already on CAST-1, AIR-1, MSR-2 and PLT-1. Both live in H-3.yaml rather than Core.yaml because H-3D has no api, no web_server and logger baud_rate 0, so text sensors there have nowhere to surface. No version bump: this rides the bump in the All Lights PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Add an All Lights entity for the whole chain
Add the Apollo Firmware Version entity
Pressing it skips all component setup on the next boot, leaving the ornament dark and unresponsive to its buttons for 5 minutes. No other Apollo product exposes a safe_mode button at all. Sets disabled_by_default: true, matching Factory Reset on this device. Safe mode itself is unchanged, so automatic boot-loop recovery still works; only the manual trigger is hidden. Version 26.8.26.3 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Hide the Restart (Safe Mode) button by default
The 0-36 partition added in #17 owned the same pixels as the five zone lights with independent state, so turning All Lights off left a zone either physically lit (its effect repaints on its own interval) or dark while still reporting on. Rebuilds it on partition's single_light_id segment form, which wraps each zone light instead of a pixel range. AddressableLightWrapper::write_state returns early when the wrapped light's remote_values.is_on(), so a zone the user turned on is never painted over, and it drives zones with set_publish(false) so a master-driven zone never falsely reports on. The cleanup wiring from #17 is kept: all_lights_off, both on_shutdown blocks, and each play_song_* still clear the master. TRADE-OFF: the wrapper is one pixel per wrapped light, so effects selected on All Lights render as five blocks rather than a 37-LED gradient. Effects on an individual zone are unaffected. Version 26.8.27.1 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Make All Lights a master over the zones instead of raw pixels
Update Since Deprecated
#21 built All Lights as a partition over the five zone lights, which wraps each zone in an AddressableLightWrapper. That wrapper refuses to write a zone whose own state is on, so All Lights could only drive zones that were already off, and it reports one pixel per wrapped light, so effects on it rendered as five blocks rather than a 37 pixel pattern. All 37 LEDs sit on one chain on GPIO3, so the chain itself is the all-lights light. Drop internal: true, name it All Lights, point the five zone partitions at it, and delete the master block. color_correct goes with it. Partitions substitute their own correction for every pixel they write and nothing ever wrote through the chain, so the 40% never reached an LED. Keeping it would cap All Lights alone at 40% while the zones stayed at 100%. Version 26.8.28.1 🤖 Generated with [Claude Code](https://claude.com/claude-code)
GPIO4 and GPIO5 are the Song Button 2 and Song Button 3 pins, and each warns twice at the top of every build because each is declared under deep_sleep's esp32_ext1_wakeup and again on its binary_sensor. The warning is about external pullups or pulldowns on a strapping pin. Both buttons run on the C6's internal pulldowns, so it does not apply. GPIO9's reset button already carries the same flag. No version bump: ignore_strapping_warning is read by the pin validator and never passed to codegen, so the compiled firmware is unchanged. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
H-3 already uses `channel_colors` on the LED chain, but both device YAMLs still declared min_version: 2025.11.0. `channel_colors` only exists from ESPHome 2026.8.0 (esphome#18474), so an adopter on an older ESPHome hits "Unknown option channel_colors" inside Core.yaml instead of a clear version error. Brings H-3 in line with the rest of the fleet, which moved to 2026.8.0 alongside the channel_colors migration. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Make All Lights the LED chain instead of a partition over the zones
…rnings Silence the strapping pin warnings on the GPIO4 and GPIO5 buttons
…colors Require ESPHome 2026.8.0 for channel_colors
🤖 Generated with [Claude Code](https://claude.com/claude-code)
# Conflicts: # Integrations/ESPHome/Core.yaml
Fix OTA manifest lambda for ESPHome dev
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 52 minutes. View limit details
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 |
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.
Version: 26.10.12.1
What does this implement/fix?
Merges beta into main for the 26.10.12.1 release. Changes include:
rgb_orderoption withchannel_colors, which requires ESPHome 2026.8.0+ (Update Since Deprecated #22)min_versionbumped becausechannel_colorsonly exists from that release; anyone building the YAML themselves needs to update ESPHome (Require ESPHome 2026.8.0 for channel_colors #25)Types of changes
Checklist / Checklijst:
If user-visible functionality or configuration variables are added/modified: