Disclosure: I work for Apollo Automation. The CAST-1 is one of our devices and this is firmware I work on.
The Apollo CAST-1 plays audio through a PCM5122 DAC. Our 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 we moved the CAST-1 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 for us.
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. Our 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 what we had. 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 our 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. We’d 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 our 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.