Configure the WizMote from Home Assistant (per-button selects + blueprint)#35
Merged
Conversation
Add a select per WizMote button (On, Off, Night, Brightness Up/Down, Button 1-4) so the action is chosen in HA, no YAML editing. Options: Nothing / Play / Pause / Play-Pause / Next / Previous / Volume Up/Down / Toggle Light / Send HA Event. Defaults match the previous fixed mapping. process_wizmote_button now looks up the pressed button's select and runs a shared run_wizmote_action sub-script. "Send HA Event" fires esphome.cast1_wizmote_event with the button label in the payload, so any button can be wired to a playlist/scene/etc. in a HA automation. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
WalkthroughReplaces the fixed WizMote button-to-action mapping in ChangesWizMote Configurable Button Actions
Sequence DiagramsequenceDiagram
participant HA as Home Assistant
participant Blueprint as cast-1-wizmote Blueprint
participant Device as CAST-1 ESPHome Device
participant WizMote as WizMote Remote
rect rgba(100, 149, 237, 0.5)
note over HA,Device: Sync on startup/reload
HA->>Blueprint: homeassistant start / automation_reloaded
Blueprint->>Device: select.set_option (9 buttons)
Device-->>Blueprint: options updated
end
rect rgba(144, 238, 144, 0.5)
note over WizMote,HA: Runtime button press
WizMote->>Device: ESP-NOW button press
Device->>Device: process_wizmote_button → run_wizmote_action
Device->>HA: fire esphome.cast1_wizmote_event(button label)
HA->>Blueprint: trigger on cast1_wizmote_event
Blueprint->>HA: execute custom per-button action input
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Lets users wire any "Send HA Event" button to an HA action (playlist, scene, script) without editing automations by hand. One action selector per button; triggers on esphome.cast1_wizmote_event. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
YAML parsed the bare On/Off input names as booleans, so HA rejected the import. Quote all names. Also relocate the blueprint to a top-level Blueprints/ directory and point source_url at the new path. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
So testers can confirm they flashed this build. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
The event delivers the button as a number, so the string comparisons in the choose never matched and no action ran. Cast it with | string. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
HA's template engine coerces the numeric button "3" to the int 3 when it stores the pressed variable, so a variable-level | string is undone and 3 == '3' stayed false. Move | string into each comparison where the cast survives, so the numeric buttons match. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Replace the template choose with one event trigger per button (event_data filter + trigger id) and condition: trigger. HA matches the raw event value instead of a Jinja-coerced variable, so the numeric buttons can't break, it validates at load instead of failing silently, and quoting the button values avoids the on/off YAML-boolean trap. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Each button now has its own Action dropdown (same 10 options as the device) plus a custom action, grouped in collapsible sections. On HA start and on save, the blueprint pushes each pick down to the matching WizMote select on the CAST-1 via select.select_option, so the device page no longer needs touching - the blueprint is the source of truth. Local media actions still run on-device; "Send HA Event" runs the button's custom action. Needs a CAST-1 device picker; no firmware change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Match the BTN-1 blueprint pattern: filter by manufacturer ApolloAutomation and the CAST-1-W / CAST-1-ETH models so the picker only lists CAST-1s instead of every ESPHome device. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Adds a "Default: <action>" hint to every button so the shipped behavior is visible even after someone changes the dropdown. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Blueprints/cast-1-wizmote.yaml`:
- Around line 223-257: The blueprint triggers matching on event_type
esphome.cast1_wizmote_event only filter by the button field in event_data,
causing all CAST-1 instances to respond to any remote press in multi-device
setups. First, modify the ESPHome WizMote integration
(Integrations/ESPHome/wizmote.yaml around line 309) to include a device or
source identifier in the event payload. Then, update all the trigger definitions
in this blueprint that specify event_data with button values to also include a
filter condition on the source/device identifier field to scope the triggers to
the selected device only.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9e873747-bebe-47b1-82a5-d60117a20173
📒 Files selected for processing (3)
Blueprints/cast-1-wizmote.yamlIntegrations/ESPHome/Core.yamlIntegrations/ESPHome/wizmote.yaml
Comment on lines
+223
to
+257
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "on" } | ||
| id: "on" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "off" } | ||
| id: "off" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "night" } | ||
| id: "night" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "brightness_up" } | ||
| id: "brightness_up" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "brightness_down" } | ||
| id: "brightness_down" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "1" } | ||
| id: "button_1" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "2" } | ||
| id: "button_2" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "3" } | ||
| id: "button_3" | ||
| - trigger: event | ||
| event_type: esphome.cast1_wizmote_event | ||
| event_data: { button: "4" } | ||
| id: "button_4" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Blueprint WizMote event triggers (button-only matching):"
rg -n -C2 'event_type:\s*esphome\.cast1_wizmote_event|event_data:\s*\{ button:' Blueprints/cast-1-wizmote.yaml
echo
echo "ESPHome WizMote event payload fields:"
rg -n -C3 'homeassistant\.event|event:\s*esphome\.cast1_wizmote_event|data:|button:' Integrations/ESPHome/wizmote.yamlRepository: ApolloAutomation/CAST-1
Length of output: 4878
Scope WizMote event handling to the selected device.
Blueprint triggers (lines 232–266) match only the button field in event_data. The ESPHome WizMote integration (Integrations/ESPHome/wizmote.yaml, line 309) emits events with only button in the payload and no device/source identifier. In multi-device setups, multiple CAST-1 blueprint instances will all react to a single remote press. Add a device/source identifier to the event payload and gate these triggers by that source field.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Blueprints/cast-1-wizmote.yaml` around lines 223 - 257, The blueprint
triggers matching on event_type esphome.cast1_wizmote_event only filter by the
button field in event_data, causing all CAST-1 instances to respond to any
remote press in multi-device setups. First, modify the ESPHome WizMote
integration (Integrations/ESPHome/wizmote.yaml around line 309) to include a
device or source identifier in the event payload. Then, update all the trigger
definitions in this blueprint that specify event_data with button values to also
include a filter condition on the source/device identifier field to scope the
triggers to the selected device only.
Rename the file (source_url updated to match) and replace the description blob with scannable emoji-labeled lines. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Lead line, a Features list, and a plain-language explainer of "Send HA Event" with examples (Music Assistant playlist, toggle a room's lights, run a scene). Emojis only on the bullets, not the section headers. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Clearer phrasing: defaults you can override to suit your needs, override from the dropdown, and "Send HA Event" to set up a custom action. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Merge the "ships with a default" and "override from the dropdown" bullets into one, since they said the same thing. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
bharvey88
changed the title
Contributor
Author
|
this has been tested and is ready to merge to beta @TrevorSchirmer |
Lives in ApolloAutomation/Blueprints (CAST-1/CAST-1-WizMote.yaml, PR #16); this PR is now firmware-only. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
7 tasks
Contributor
Author
|
works great merging to beta! |
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.
Version: 26.6.19.3
What does this implement/fix?
Adds full Home Assistant control over the WizMote, configurable two ways.
On the device — one
selectper button (WizMote On / Off / Night / Brightness Up / Brightness Down / Button 1 / Button 2 / Button 3 / Button 4), allentity_category: config,restore_value: true, each offering:process_wizmote_buttonlooks up the pressed button's select and runs a sharedrun_wizmote_actionsub-script. Defaults match the previous fixed mapping (On=Play, Off=Pause, 1=Previous, 2=Next, 3/4=Send HA Event, Bright +/-=Volume, Night=Toggle Light), so behaviour is unchanged out of the box. Send HA Event firesesphome.cast1_wizmote_eventwith the pressed button in the payload ({ button: "3" }).From a blueprint — a Home Assistant automation blueprint that turns the buttons into a single config surface lives in the Blueprints repo: ApolloAutomation/Blueprints →
CAST-1/CAST-1-WizMote.yaml(ApolloAutomation/Blueprints#16). Each button gets an Action dropdown (the same 10 options) plus a custom action; on HA start and on save the blueprint writes the picks down to the device's selects, so users never need to open the device page. This PR is the firmware side only (per-button selects +cast1_wizmote_event); the blueprint ships separately in that repo.Validated with
esphome configon both variants on esphome 2026.6.1.Types of changes
Checklist / Checklijst:
If user-visible functionality or configuration variables are added/modified:
🤖 Generated with Claude Code