Skip to content

Initial Firmware - #1

Merged
TrevorSchirmer merged 3 commits into
mainfrom
beta
Sep 30, 2026
Merged

TrevorSchirmer merged 3 commits into
mainfrom
beta

Conversation

@TrevorSchirmer

@TrevorSchirmer TrevorSchirmer commented Sep 30, 2026 •

Copy link
Copy Markdown
Member

Version: 26.9.21.1

Very initial firmware with minimal time meant to be a starting point for working with the hardware

Checks:

  • Documentation Updated
  • Build Number Incremented In Core.yaml

Summary by CodeRabbit

  • New Features
    • Added Apollo CAST-PRO-1 support with Ethernet/Wi-Fi failover, Bluetooth proxy controls, firmware-channel updates, audio playback, and line-in routing.
    • Added I2S microphone and speaker support, including full-duplex audio and S/PDIF output.
    • Added WizMote pairing, discovery, and configurable button actions.
    • Added beta firmware builds and downloadable firmware artifacts.
  • Changes
    • Replaced the AIR-1 ESPHome configuration with CAST-PRO-1 support.
    • The I2S audio media-player configuration now directs users to the speaker media-player component.

TrevorSchirmer and others added 3 commits September 28, 2026 13:37
Port the CAST-1 firmware to the CAST PRO board:
- New pinout: W5500 on 11/12/13/10 (INT 5, RST 21), I2S WS 7, BCLK 14,
  MCLK 17, DOUT 9, DIN 15, SPDIF on 16
- Optical (SPDIF) output alongside the PCM5122, chosen with an
  "Audio Output" select through a router speaker
- PCM1808 line in on the same I2S port as the DAC, run full duplex at
  48 kHz stereo in 32-bit slots, with a "Line In" switch that mixes it
  into the selected output
- Vendored i2s_audio (ESPHome 2026.9.0 + full duplex from
  esphome/esphome#16882, with timing and format fixes); see
  components/i2s_audio/README.md
- Rename CAST-1 to CAST_PRO-1 across configs, OTA manifests and workflows
@coderabbitai

coderabbitai Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

ApolloAutomation is on CodeRabbit Free, which includes PR summaries. Ask your admin to upgrade for code reviews.

  • Ask an admin to upgrade

Open in CodeRabbit

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 3314986c-5b0a-466d-ab73-25ac56a879c5

📥 Commits

Reviewing files that changed from the base of the PR and between 464ac89 and 2ae2e36.

📒 Files selected for processing (30)
  • .github/PULL_REQUEST_TEMPLATE.md
  • .github/release-drafter.yml
  • .github/workflows/autoassign.yml
  • .github/workflows/build-beta.yml
  • .github/workflows/build.yml
  • .github/workflows/ci.yml
  • .github/workflows/label-check.yml
  • .github/workflows/weekly.yml
  • Integrations/ESPHome/.gitignore
  • Integrations/ESPHome/AIR-1.yaml
  • Integrations/ESPHome/CAST_PRO-1.yaml
  • Integrations/ESPHome/Core.yaml
  • Integrations/ESPHome/components/i2s_audio/README.md
  • Integrations/ESPHome/components/i2s_audio/__init__.py
  • Integrations/ESPHome/components/i2s_audio/i2s_audio.cpp
  • Integrations/ESPHome/components/i2s_audio/i2s_audio.h
  • Integrations/ESPHome/components/i2s_audio/media_player/__init__.py
  • Integrations/ESPHome/components/i2s_audio/microphone/__init__.py
  • Integrations/ESPHome/components/i2s_audio/microphone/i2s_audio_microphone.cpp
  • Integrations/ESPHome/components/i2s_audio/microphone/i2s_audio_microphone.h
  • Integrations/ESPHome/components/i2s_audio/speaker/__init__.py
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_spdif.cpp
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_spdif.h
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker.cpp
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker.h
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker_standard.cpp
  • Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker_standard.h
  • Integrations/ESPHome/components/i2s_audio/speaker/spdif_encoder.cpp
  • Integrations/ESPHome/components/i2s_audio/speaker/spdif_encoder.h
  • Integrations/ESPHome/wizmote.yaml
💤 Files with no reviewable changes (1)
  • Integrations/ESPHome/AIR-1.yaml

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.


Walkthrough

This PR replaces the AIR-1 ESPHome target with CAST-PRO-1 firmware, adds device networking, audio, and WizMote configuration, and introduces a local full-duplex I²S component. It also adds beta firmware publishing and updates GitHub pull-request, CI, and release automation.

Changes

Pull Request and Release Automation

Layer / File(s) Summary
Pull request and release metadata
.github/PULL_REQUEST_TEMPLATE.md, .github/release-drafter.yml
A pull request template adds contributor prompts and checklists. Release Drafter settings define release names, categories, entry formatting, and release-body content.
Pull request assignment and label checks
.github/workflows/autoassign.yml, .github/workflows/label-check.yml
The auto-assignment workflow changes its trigger and assignee. A separate workflow calls the reusable label-check workflow.

CAST-PRO-1 Firmware

Layer / File(s) Summary
Device target and network setup
Integrations/ESPHome/.gitignore, Integrations/ESPHome/AIR-1.yaml, Integrations/ESPHome/CAST_PRO-1.yaml, Integrations/ESPHome/Core.yaml
The AIR-1 configuration is removed and a CAST-PRO-1 target is added. Core configuration defines device identity, network setup, platform components, and boot behavior.
Device controls and status entities
Integrations/ESPHome/Core.yaml
Core configuration adds persisted state, device buttons and switches, and status and diagnostic sensors.
Network recovery and device scripts
Integrations/ESPHome/Core.yaml
Core configuration adds Wi-Fi recovery and release routines, OTA source selection, status reporting, and a test script.
WizMote pairing and button actions
Integrations/ESPHome/wizmote.yaml
The new package adds MAC pairing, discovery, packet filtering, channel scanning, and configurable actions for mapped button codes.
CAST-PRO-1 build and beta publishing
.github/workflows/build-beta.yml, .github/workflows/build.yml, .github/workflows/ci.yml, .github/workflows/weekly.yml
CI, weekly, and release builds target CAST-PRO-1. The beta workflow builds firmware and publishes a manifest and binary artifacts.

ESPHome I²S Audio

Layer / File(s) Summary
I²S configuration and shared component contract
Integrations/ESPHome/components/i2s_audio/README.md, Integrations/ESPHome/components/i2s_audio/__init__.py, Integrations/ESPHome/components/i2s_audio/i2s_audio.h
The component adds configuration validation, port assignment, code generation, and shared I²S interfaces. The README describes the full-duplex override.
Shared full-duplex channel runtime
Integrations/ESPHome/components/i2s_audio/i2s_audio.cpp
The component allocates paired RX/TX channels, starts TX with silence, attaches speakers to TX events, and handles channel events and release.
I²S microphone configuration and capture
Integrations/ESPHome/components/i2s_audio/microphone/*
The microphone integration validates ADC and PDM options, generates component settings, and implements capture, callbacks, and optional DC-offset correction.
Standard I²S speaker configuration and playback
Integrations/ESPHome/components/i2s_audio/speaker/__init__.py, Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker*, Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_speaker_standard*
The speaker integration adds configuration validation and standard I²S playback, buffering, volume, and task handling.
SPDIF encoding and speaker playback
Integrations/ESPHome/components/i2s_audio/speaker/i2s_audio_spdif*, Integrations/ESPHome/components/i2s_audio/speaker/spdif_encoder*
The SPDIF integration validates output settings, encodes PCM into SPDIF blocks, and manages playback, DMA events, and silence handling.
CAST-PRO-1 audio routing and controls
Integrations/ESPHome/Core.yaml
Core configuration connects line-in capture, media and announcement pipelines, output selection, DAC and SPDIF speakers, and audio-related automations.

Estimated code review effort: 5 (Critical) | ~120 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant CoreYaml
  participant ESPHomeBuildWorkflow
  participant GitHubRelease
  GitHubActions->>CoreYaml: Read firmware version
  GitHubActions->>ESPHomeBuildWorkflow: Build CAST-PRO-1 firmware
  ESPHomeBuildWorkflow-->>GitHubActions: Return firmware artifacts
  GitHubActions->>GitHubRelease: Publish manifest and binaries
  GitHubActions->>GitHubRelease: Update beta-fw tag to triggering commit
Loading
sequenceDiagram
  participant LineInSwitch
  participant LineInApply
  participant I2SAudioMicrophone
  participant Mixer
  participant AudioOutputRouter
  participant DACSpeaker
  participant SPDIFSpeaker
  LineInSwitch->>LineInApply: Apply line-in state
  LineInApply->>I2SAudioMicrophone: Start capture when enabled
  I2SAudioMicrophone->>Mixer: Send captured audio
  Mixer->>AudioOutputRouter: Supply mixed audio
  AudioOutputRouter->>DACSpeaker: Route DAC output
  AudioOutputRouter->>SPDIFSpeaker: Route optical output
Loading

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 2ae2e

The new remote-control path has unresolved sender-authentication guarantees, while beta firmware publication can expose incomplete or mixed releases after failures or overlapping runs. Discovery is disabled by default, commands are bounded, beta adoption is explicit, and HTTPS verification is enabled. These controls limit exposure but do not resolve the remaining risks.

Retained concerns

  • Medium · security · inferred: The new radio control boundary does not establish authenticated enrollment or replay-resistant commands in the available configuration. During explicitly enabled discovery, any unknown 13-byte sender can replace the paired MAC. Subsequently, command filtering uses MAC equality and volatile last-sequence equality. If upstream controls permit spoofing or replay, a nearby sender could invoke configured device actions; that exploitability remains unresolved.
  • Medium · reliability · observed: The new rolling beta delivery path publishes its manifest before independently replacing binaries, without workflow-level concurrency control or an atomic promotion step. Interruption or overlapping runs can expose inconsistent release contents. Binary uploads execute through find -exec without a release-level success check before the tag update, and moving the tag back does not restore overwritten assets. This weakens failure containment and recovery for firmware delivery, including security fixes, to beta devices.
Security review details

Security Blast Radius

  • inferred — The radio concern is bounded to reachable devices and their configured actions; downstream effects of the fixed Home Assistant event depend on consumer automations. Publication inconsistency can affect every device consuming the shared beta release, but does not by itself establish arbitrary firmware execution or exposure of Stable devices.

Security Findings and Attack Paths

  • inferred — A competing nearby sender could acquire ownership while discovery is enabled. Outside discovery, impersonation or replay would require defeating or lacking upstream sender and freshness enforcement. The local handler alone does not establish those guarantees, and no end-to-end unauthorized execution was verified.

Trust Boundaries and Controls

  • observed — Discovery starts disabled, automatic peer addition is disabled, commands require a configured sender MAC and valid length, and actions are predefined. Publication starts from beta pushes or manual dispatch, not a pull-request trigger; read-only defaults are elevated only for publishing. Firmware transport verifies TLS, but external initiation policy and independent artifact-authenticity enforcement remain unverified.

Resilience and Maintainability Implications

  • inferred — A successful rerun can repair rolling assets, but overlapping reruns can interleave replacements. Without an immutable previous release or release-level validation, operators cannot rely on the tag alone to identify coherent firmware or recover from an interrupted security update publication.

Hardening Proposals

  • proposed — Establish the upstream sender-authentication and replay contract explicitly. Where compatible with the remote protocol, bind enrollment to intentional confirmation and enforce freshness beyond equality with the last packet.
  • proposed — Serialize publication, upload firmware to immutable versioned locations, validate all assets before promoting the manifest, and retain the previous coherent release for rollback. Explicitly confirm what artifact integrity and authenticity the generated manifest and device updater enforce.
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.


I’m a rabbit; I hop by the sound,
Past new firmware paths neatly wound.
I tap out a beat,
Where the channels all meet,
Then nibble a leaf and lie down.

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

@TrevorSchirmer
TrevorSchirmer merged commit e32a1db into main Sep 30, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants