The CAST-1 got a new DAC component and WizMote support

The Apollo CAST-1 plays audio through a PCM5122 DAC. Its firmware drove that chip with a community ESPHome component from sonocotta. ESPHome 2026.6.0 added a PCM5122 component to core, written by RemCom, so the CAST-1 moved to it and added WizMote remote support in the same update.

Thanks to RemCom for writing the core component and maintaining it. Having the chip in ESPHome proper drops an external dependency.

The old component stopped loading on 2026.6.0

I’d been treating the move as cleanup I’d get to eventually. Then 2026.6.0 shipped and it stopped being optional. The sonocotta component calls cv.only_with_esp_idf, that helper got removed in 2026.6.0, and now the component won’t load at all. The CAST-1 firmware wouldn’t build once CI moved to the new ESPHome. The core component was the fix.

The core one is more bare-bones than the community one. analog_gain, volume_max, volume_min, mixer_mode, and enable_pin aren’t in it. So I trimmed the audio_dac config down to what it takes and moved the DAC enable line to a plain GPIO switch.

The new component boots muted

This one got me. I flashed it, started a track, and got nothing. Silent. But the logs were clean. The media player hit PLAYING, the FLAC stream was decoding at 48kHz, the ring buffer allocated, track titles showed up. Every layer said it was playing.

Clean logs and no sound meant the chip, not the streaming. The core component’s setup ends with set_mute_on(). It boots the chip muted and waits to be unmuted. The old component never did that, which is why it always just worked.

Nothing in the config was unmuting it. The i2s speaker isn’t tied to the audio_dac, so the media player never touches the mute register. One line fixed it: audio_dac.mute_off on the media player’s state change, so it unmutes the second something plays.

If you move a device to the core PCM5122 component and get silence with clean logs, that’s the reason. The boot log says it outright, the Audio DAC line prints Muted: YES.

The output got louder

Dropping analog_gain was a real change, not a cosmetic one. The firmware had been running the DAC’s analog output pad at -6dB. The core component sits at the chip default of 0dB, so it’s about 6dB louder for the same volume setting. There’s no knob for it in the core component, so for now that’s just where it is.

WizMote support

While I was in the firmware I added WizMote support. The WizMote is a cheap battery remote that talks ESP-NOW, and the CAST-1 already has the radio for it. You pair one by turning on a discovery switch and pressing a button, and it sticks across reboots.

The buttons:

• ON and OFF: play and pause
• Scene 1 and 2: previous and next track
• Scene 3 and 4: each fire a Home Assistant event, so you map them to a playlist or favorite in an automation
• Brightness up and down: volume
• Night: toggles the RGB light

Some of that landed where it did because of ESPHome. I wanted Scene 1 and 2 to scrub inside a track, rewind and fast-forward. ESPHome’s media player has no seek command. Play, pause, next, previous, volume, that’s the whole list. So scrubbing isn’t possible and those two became track skip. Routing 3 and 4 through Home Assistant events worked out better than a fixed action anyway, you can point them at a playlist, a favorite, a station, or a scene without reflashing.

The Ethernet variant took extra work. ESP-NOW runs on the WiFi radio. The WiFi CAST-1 follows whatever channel its WiFi is on. The Ethernet one has no WiFi to follow, so it scans channels until it hears the remote and then holds there.

What’s on beta

The DAC migration is merged to the CAST-1 beta branch. The WizMote support is in a pull request behind it. Both build against ESPHome 2026.6.0. I’ve run the DAC change and the WizMote on the WiFi hardware. The Ethernet channel scan validates but I haven’t put it on an Ethernet unit yet.