In the process of expanding my smart home setup, a few of the voices in my head decided to relocate somewhere more comfortable.

Everyone has their own takes on what “smart home” really means. Some picture it as a kind of living, thinking creature you can chat up or otherwise hang out with. Me, though? I’m going completely the other way: I figure the smarter the home, the less I have to fuss with it. What’s the point of a smart home if it needs a prompt just to flip on the lights? C’mon, I can handle a light switch on my own — doesn’t take a genius. In my book, a truly smart home should be as subtle as possible, quietly running the show without giving the orderlies any reason to drop by.

For “communication and interaction” at home, I’m all set with my wife, my dog, and my cat. The last thing I need is some server hanging overhead, driving me nuts and demanding my attention.

Still, there are moments when a smart home should speak up. Sure, it’s obvious when the smoke alarm goes off. But even something like a sprinkler warning — letting you know before it soaks you head to toe — can make life easier.

So at some point, it became necessary to give the house some simple audio alerts. After all, we’re not glued to its graphical control console 24/7, keeping an eye on every single event. We might miss something important otherwise.

So, bottom line… The project’s goal is to set up a bunch of simple devices with speakers and mics that can play media content at the level of basic voice announcements and, when necessary, handle simple voice commands. Absolutely not a “sound system” — we already have one of those. I’m talking about the simplest speaker-horns, like the ones you’d find at a train station. As bare-bones as possible. And they’d be spread all over every single room in the house:

The advantages of having a cluster of devices instead of just one big setup:

• Say goodbye to blasting one speaker at full volume just so it’s loud enough for someone in the backyard to hear. With distributed speakers, every space gets its own tailored sound.
• Each resident can fine-tune their personal speaker — voice, volume, and all that — just the way they want it.
• Selective targeting. For example, the heads-up that the lawn sprinklers are about to turn on really only matters to whoever’s out in the yard, not the person snoozing peacefully in their bedroom.
• Easy intercom connections between rooms. Let’s face it, we’re not all surgically attached to our cell phones, and trying to holler from the garage to the kitchen for wife’s attention doesn’t always work so well.
• Compactness. Obviously, a small low-power alert device takes up far less space than a single beefy PA system with a massive amp and speakers.

You could pick up some simple, not-too-pricey wireless speakers on Amazon or some other Alibaba-like site. They come in all shapes and sizes. Some can even be wrangled into working with Home Assistant — if you’re lucky. But I decided to take a more interesting and reliable route: build my own wireless speaker as a smart home component. Nothing too outlandish. It’s what I’d call an “early-to-mid-level” project in terms of complexity. It’ll be cheaper, and I won’t have to deal with any compatibility drama.

I started by hooking up an ESP32 to a DAC board based on the UDA1334A, which speaks I2S. Then I added a PAM8403-based amplifier. After that, I connected a pair of 2-inch, 4Ω-3W speakers:

And it worked like a charm. The DAC module’s output goes to the amp either through a built-in 3mm jack (option #2) or via the onboard analog output pins (option #1). All the modules in this example are chosen so they can run off the existing 5V supply in the system. That way, you don’t have to rig up any extra step-up or step-down converters.

Of course, nothing’s stopping you from tossing in a truck-sized Class-D amp, powering it straight from the nearest nuclear reactor, and blasting a city-wide announcement that there’s been a spike in methane level in your home’s bathroom atmosphere.

Pre-built firmware for this kind of setup is easy enough to find online, whether you’re running something like ESPHome or going for a standalone Arduino-style project. Just search by module names or I2S in the context of the ESP32. They generally all rely on standard libraries and some rock-solid, bare-bones code you can fit on a Post-it note. Here’s one of my favorite DIY YouTubers — he goes to absurd lengths in his “tutorial” videos — who covered this topic in excruciating detail ages ago:

I doubt I could add anything more to that.

The speaker setup I mentioned above works and plugs right into HA + ESPHome right out of the gate. Literally, you can just copy and paste snippets from the documentation as is. It’s that straightforward.

I was already thinking about how to quickly bundle all this into a single enclosure, when I randomly stumbled upon the exact same setup, but in the form of a single board called the ESP32-A1S Audio Kit:

It’s got everything right there: an ESP32, DAC, amplifier, control buttons, microphones, speaker outputs, line-in, line-out, and even microSD support for local media. In short, everything you need. Its cost ended up being about one and a half times more expensive than piecing together the same thing from separate components. But the beauty of it is that with this board, you don’t have to do a darn thing. Literally nothing! Just flash the firmware and build the enclosure. And since I would’ve had to build an enclosure one way or another, I decided to scrap the initial combo of modules in favor of the single ESP32-A1S Audio Kit.

Anyone looking to follow my lead can choose either path. The end result will be exactly the same, except for one tiny detail: in my first setup, I didn’t have microphones yet. I just hadn’t gotten around to that part of the project before I came across the ready-made A1S Audio Kit, which included them. But adding a microphone module to your parts collection is trivial. So, as I said, the outcome is the same. It’s just a matter of convenience (one board is easier to mount in a case than several), cost (the difference is literally just a few bucks), and time (since you have to wire the separate modules yourself).

In the end, the entire project boiled down to simply creating an enclosure. And I didn’t have to rack my brains over that, either.

No fancy artistry or technical trickery was required, so I just went with a “point the cursor and see where it goes” approach:

Mainly, the enclosure was designed to allow for at least some spacing for the speakers and to accommodate their size. So, inside it’s basically just a whole lot of empty space:

Despite how simple the structure is, the number of little parts did pile up a bit:

1. Bottom half of the enclosure.
2. Feet.
3. A decorative faceplate — purely for aesthetics. Its presence or absence makes no difference to how the device works.
4. Front panel.
5. A protective mesh for the microphones.
6. Control buttons.
7. A control panel. In theory, it could have been one piece with that part of the enclosure, but then I’d have to print it with support structures, which I fiercely hate for obvious reasons. It’s much easier to print it separately and just glue it in place.
8. Top half of the enclosure.
9. The ESP32-A1S Audio Kit board.
10. Speakers.
11. The same as #7 above, but without holes for the buttons and mics. It’s a separate element for the same reason as before.

As for the controls, honestly, they’re not super necessary:

1. Mute/Unmute
2. Vol. –
3. Vol. +
4. Voice Assistant

The first three volume buttons duplicate functions already available in the HA interface. In other words, you can just do it all manually or via automations right from the console. The “Voice Assistant” button isn’t really needed either, since you can configure activation with a magic phrase — “Hey, house!” or whatever…

At the moment, since I don’t actually need voice control of the home, this capability exists in the speakers but isn’t being used. On the interface side, I see that the activation button works, and on the server side the “voice assistant” wakes up and starts listening. It’s just that nothing else happens after that because the system doesn’t have any further instructions. I haven’t gotten around to exploring this part of HA’s functionality yet, so I still have no idea how it works. But it’s there, and it apparently does something.

Anyway, I implemented these controls mostly because the controller board already had them — six whole buttons. I struggled to even come up with basic uses for four of them. On the other hand, a device without any buttons at all goes against human nature. People need the illusion that their actions influence something, that they’re in control.

Before assembling everything, I had to make a small tweak — relocating the GPIO rail to the back of the board:

I did this purely to make room for an RGB LED — because, honestly, who doesn’t love a few extra lights?

Here’s what it currently indicates:

• Glows green when the device is powered on.
• Briefly flashes red to show it’s connected to Home Assistant.
• Turns blue when the “voice assistant” feature is activated.

Just like with the buttons, this illumination isn’t strictly necessary — you can easily do without it. But I love the lights. Plus, why let an unused GPIO go to waste?

At this stage, it’s also the most convenient time to flash the base firmware onto the board:

Later, the firmware can be configured and updated “over the air.” However, the very first flashing must be done via a direct USB connection to a computer or server. I didn’t add an external USB port to the device case, so for this task, the device will need to be disassembled.

The fabrication of the case parts started with the front panel:

It consists of a flat base panel, a decorative overlay, speakers, an RGB LED, and some fasteners. Out of these, only the base panel and the decorative overlay need to be custom-made. While it would have been possible to 3D print these parts — just like the rest of the case — I decided to take a different approach.

As it happens, I unexpectedly ended up with an “industrial” CO laser cutter in my garage. That’s a story for another time. The thing is, I didn’t particularly need it — it doesn’t see much use around here. Most of the time, it just sits in the garage collecting dust. But I hate having tools go to waste, so I try to put it to use wherever and whenever I can, even if it’s not strictly necessary. That’s exactly what happened here — I decided to laser-cut the panel and the overlay out of acrylic instead of 3D printing them:

For both parts, I recycled some old acrylic and jazzed it up with vinyl film — beige-gold for the panel, pearlescent for the overlay (don’t ask, my wife picked the colors).

For fans of industrial “craft-porn,” here’s the uncut and unsped-up footage of the laser cutting the decorative overlay. No edits, no time-lapses — just raw process.

All the necessary parts for the front panel are ready:

I temporarily assembled the front panel using nuts:

In the future, the bolts securing the speakers will screw directly into the case, eliminating the need for nuts.

Here I decided to experiment a little with the output signal power. The printer was still busy churning out case parts, and I needed something to keep myself occupied in the meantime.

The ESP32-A1S Audio Kit board comes with its own amplifier. According to the documentation, it provides 2W per channel for 4Ω speakers. That’s generally enough for typical household use within a single room (I even have to dial the volume down to 70-80%).

But the speakers I found stashed away in my supplies are rated for up to 3W at the same 4Ω. So why not crank things up a notch? I tried bypassing the onboard amp and used the board’s line-out with a PAM8403 module. It’s nothing groundbreaking — just a small boost to 3W per channel for my 4Ω speakers. But since I already had the parts, it was a quick and easy upgrade.

The ESP32-A1S Audio Kit doesn’t have a dedicated 5V output — only 3.3V. But 3.3V isn’t enough for the PAM8403; it needs 5V. Luckily, the board has two USB ports: one for power only and the other for full UART functionality. Regardless of which USB port you supply power to, both will output 5V. This means I can power the device from one USB port and use the other to feed 5V to the amplifier.

In the photo, the lower USB port is used for power input, while the upper one provides 5V to the amplifier. And, of course, the 3mm jack from the line-out goes to the amplifier as well:

The volume — oh, what a miracle! — got just a touch louder. Not that there was much else we could’ve expected, right? My unpretentious yet finely tuned musical ear didn’t take offense in the slightest, and from that point on, this very setup was the one chosen for production.

The best part is, we didn’t have to mess with the already-printing case at all. We can just drop the amplifier module inside and wrap it in some heat-shrink tubing — no big deal:

I also tried another amp — the PAM8610. It’s just as tiny, but this one needs a 12V supply, and let me tell you, this bad boy cranks up to 15W. The speakers I picked for the project started doing exactly what you’d expect at that power level: crackling and basically screaming, “I’m about to blow!”

So, I decided to stick with the PAM8403 for this project, so I don’t have to hunt down new speakers or rig an extra power supply. Still, I’ve tucked away the PAM8610 option in my mind. I might use it for some other loud-as-hell setups around the house. I’m gonna need more than one or two anyway. We’ll see…

While I was busy playing around with lasers and amps, the printer wrapped up the rest of the enclosure parts. Here’s what the full set of components for the loudspeaker rig looks like:

The printer is such a sweetheart. It’s doing all the heavy lifting, while I just twist a few screws and glue some parts together.

First up, I melt in the threaded inserts wherever they’re needed, in both the top and bottom halves of the enclosure:

The button panel gets fitted with a protective mesh for the mics and glued onto the top half of the enclosure:

Next, the controller board gets installed, and while I’m at it, I hook up all the necessary wiring:

The front panel with the speaker gets attached to one of the halves and wired up to the amp:

There’s not much going on with the lower half of the enclosure — just some feet and a decorative plug:

The space behind the speakers is stuffed with polyfill salvaged from old dog toys. We’ve got a practically endless stash of ’em, thanks to that monthly Bark-Box subscription:

With the polyfill and wires in place, you can close it all up with the second half of the enclosure:

And that’s basically it…

In the end, I cranked out two identical loudspeaker units:

One for my study room/workshop, and the other for the shared family room.

I’ll live with them for a bit and see if it was worth the trouble. After that, I can decide whether to bang out another five or so just like these, or maybe do something different. Or even figure out if I need them in the system at all.

For now, the funniest part is this: the system’s person-detection alert turned my dog into an automated guard. It ignores cars and all other movement. But if it recognizes a human, the house says, “Warning! Person detected in the front yard.”

Here’s the kicker: It once took the Dog a good couple of weeks to confidently offer a paw on command. But he picked up this new phrase in two days — two freaking days! And he learned it totally on his own, without even a single treat as a reward. Now he thinks it’s a command to leap up and tear off to the window near the door, barking like crazy. He probably thinks, “Great job, humans! No more window duty. I’ll nap until the robot yells.”

I’m convinced he picked it up so fast thanks to the polyfill from the dog toys stuffed inside these loudspeakers. The sound waves passing through that “dog-sourced” filler must pick up some sort of canine vibe that’s easier for him to understand. I can’t explain it any other way…

So, at least one family member gave this new house feature a roaring thumbs-up — er, paws-up.

Thinking of building something similar? Everything you need — from the parts list to configuration files — is right here. Dive in and start tinkering! Here’s the component layout diagram:

And the 3D-printable parts:

A sample ESPHome firmware config file:

# Substitutions
# ================================================================
# Substitutions allow defining reusable variables for values that are repeated
# across the configuration file.

substitutions:
  # Controller Configuration
  name:             'jh-echo'     # Unique identifier for the device in this configuration
  friendly_name:    'JHome Echo'  # User-friendly name for display in interfaces

  # Project Information
  project_name:     'JHome.NNVI'  # Unique identifier for the project
  project_version:  '6.0'        # Current version of the project configuration

  # Board Specifications
  board_master: 'ESP32-A1S'                 # Primary ESP32-based board model
  board_slave:  'ESP32 Audio Kit v2.2 A426' # Secondary ESP32-based board model for additional functionality

  # On-board Devices Configuration
  led_service_pin:  '22'                # GPIO pin assigned to the service indicator LED
  led_action_pin:   '05'                # GPIO pin assigned to the action indicator LED

  # I2C Bus Configuration
  i2c_sda_pin:      '33'                # GPIO pin for I2C data line (SDA)
  i2c_scl_pin:      '32'                # GPIO pin for I2C clock line (SCL)

  # DAC (Digital-to-Analog Converter) Pin Configuration
  dac_lrclk_pin:    '25'                # GPIO pin for DAC Left-Right Clock (LRCLK)
  dac_bclk_pin:     '27'                # GPIO pin for DAC Bit Clock (BCLK)
  dac_dout_pin:     '26'                # GPIO pin for DAC Data Output (DOUT)
  dac_din_pin:      '35'                # GPIO pin for DAC Data Input (DIN)

  # Headphone Jack Configuration
  hdp_state_pin:    '39'                # GPIO pin connected to headphone jack state detection

  # Amplifier Control
  amp_output_pin:   '21'                # GPIO pin controlling the amplifier power state (ON/OFF)

  # Button Configuration
  btn_1_pin:        '36'                # GPIO pin assigned to button 1 (Key 1)
  btn_2_pin:        '13'                # GPIO pin assigned to button 2 (Key 2)
  btn_3_pin:        '19'                # GPIO pin assigned to button 3 (Key 3)
  btn_4_pin:        '23'                # GPIO pin assigned to button 4 (Key 4)
  btn_5_pin:        '18'                # GPIO pin assigned to button 5 (Key 5)
  #btn_6_pin:        '05'                # GPIO pin assigned to button 6 (Key 6)



# Basic ESPhome Configuration
# ================================================================
esphome:
  # This section defines the basic configuration for the ESPHome device.
  name: ${name}                   # Device's name
  friendly_name: ${friendly_name} # Device's friendly name
  project:
    name: ${project_name}         # Project name from substitutions
    version: ${project_version}   # Project version from substitutions
  name_add_mac_suffix: false      # Prevent appending the MAC address to the name

  # Actions to perform on device boot
  on_boot:
    priority: -100
    then:
      - if:
          condition:
            binary_sensor.is_on: jack_status
          then:
            - output.turn_off: amp_output
          else:
            - output.turn_on: amp_output

esp32:
  # This section specifies the hardware platform and framework type for the ESP32 board.
  board: esp-wrover-kit            # ESP32 development board type
  framework:
    type: arduino                  # Arduino framework

# Network Configurations
# ================================================================
wifi:
  # This section configures the Wi-Fi settings for connecting the device
  # to a network or creating an access point for direct communication.
  ssid: !secret wifi_ssid           # Wi-Fi network name from secrets
  password: !secret wifi_password   # Wi-Fi password from secrets
  ap:
    ssid: ${friendly_name}          # Access Point (AP) mode SSID
    password: !secret ap_password   # Access Point (AP) mode password

# Enabling ESPHome Features
# ================================================================
api:
  # Enables integration with Home Assistant using the ESPHome API.
  encryption:
    key: !secret api_key            # Encryption key for secure communication

ota:
  # Configures Over-the-Air (OTA) updates to allow firmware updates.
  platform: esphome                 # Required platform for OTA
  password: !secret ota_password    # Password for OTA updates

captive_portal:
  # Provides a captive portal for easy Wi-Fi setup when no known network is available.

web_server:
  # Enables a local web server for device management and diagnostics.

logger:
  # Configures logging options to debug or monitor device activity.
  level: INFO                       # Set logging level to INFO for reduced verbosity

# Additional Features and Integrations
# ================================================================
# Uncomment the section below if you need Improv Wi-Fi setup
# esp32_improv:
#   authorizer: none                # Setup for Improv without authorization

dashboard_import:
  # Imports external configuration files from GitHub for easy reuse and updates.
  package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
  import_full_config: true         # Import full configuration from GitHub

# External Components
# ================================================================
external_components:
  # Configures additional components from external sources like GitHub.
  - source: github://mulcmu/esphome-es8388-a1s@nightdav-patch
    components: [es8388]
    refresh: 0s

es8388:
  # Initializes and configures the ES8388 audio codec component.



# GLOBAL VARIABLES
# ================================================================
globals:
  # Memory for volume level
  - id: mem_volume
    type: float
    restore_value: no
    initial_value: '0.5'



# SERIAL INTERFACES
# ================================================================
i2c:
  # I2C Bus Configuration
  id: bus_a
  sda: ${i2c_sda_pin}
  scl: ${i2c_scl_pin}
  frequency: 400kHz
  scan: true

i2s_audio:
  # I2S Audio Configuration
  i2s_lrclk_pin: ${dac_lrclk_pin}
  i2s_bclk_pin: ${dac_bclk_pin}
  i2s_mclk_pin: 0



# OUTPUTS
# ================================================================
output:
  # Service LED
  - platform: gpio
    id: led_service
    pin: ${led_service_pin}
    #inverted: true

  # Action LED
  - platform: gpio
    id: led_action
    pin: ${led_action_pin}

  # Amplifier Output
  - platform: gpio
    id: amp_output
    pin: ${amp_output_pin}



# MEDIA FUNCTIONS
# ================================================================
media_player:
  # I2S Audio Player
  - platform: i2s_audio
    id: mplayer
    name: "Player"
    i2s_dout_pin: ${dac_dout_pin}
    dac_type: external
    mode: stereo

microphone:
  # External Microphone
  - platform: i2s_audio
    id: mic1
    i2s_din_pin: ${dac_din_pin}
    adc_type: external
    channel: left
    pdm: false

voice_assistant:
  microphone: mic1



# BINARY SENSORS
# ================================================================
binary_sensor:
  # Connection status
  - platform: status
    id: status_connection
    internal: true

  # Headphones mode (Jack status)
  - platform: gpio
    id: jack_status
    pin:
      number: ${hdp_state_pin}
      inverted: true
      mode:
        input: true
    name: "Headphones mode"
    on_state:
      - if:
          condition:
            binary_sensor.is_on: jack_status
          then:
            - output.turn_off: amp_output
          else:
            - output.turn_on: amp_output

  # Key 2 - Mute
  - platform: gpio
    id: btn_mute
    pin:
      number: ${btn_2_pin}
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Mute"
    icon: mdi:volume-mute
    on_press:
      - if:
          condition:
            lambda: 'return id(mplayer).volume == 0.0;'
          then:
            - media_player.volume_set:
                id: mplayer
                volume: !lambda 'return id(mem_volume);'
          else:
            - lambda: 'id(mem_volume) = id(mplayer).volume;'
            - media_player.volume_set:
                id: mplayer
                volume: 0.0

  # Key 3 - Volume down
  - platform: gpio
    id: btn_vol_down
    pin:
      number: ${btn_3_pin}
      inverted: true
    name: "Vol. down"
    icon: mdi:volume-minus
    filters:
      - delayed_off: 10ms
    on_press:
      - media_player.volume_down: mplayer

  # Key 4 - Volume up
  - platform: gpio
    id: btn_vol_up
    pin:
      number: ${btn_4_pin}
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Vol. up"
    icon: mdi:volume-plus
    filters:
      - delayed_off: 10ms
    on_press:
      - media_player.volume_up: mplayer

  # Key 5 - Assistant
  - platform: gpio
    id: btn_assistant
    pin: 
      number: ${btn_5_pin}
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Voice assistant"
    icon: mdi:assistant
    filters:
      - delayed_off: 10ms
    on_press:
      - output.turn_on: led_action
      - voice_assistant.start:
    on_release:
      - output.turn_off: led_action
      - voice_assistant.stop:






# SENSORS
# ================================================================
sensor:
  # Signal strength
  - platform: wifi_signal
    id: info_signal
    name: "[network] Signal"
    icon: "mdi:information-box-outline"
    unit_of_measurement: "%"
    entity_category: diagnostic
    filters:
      - lambda: |-
          return min(max(2 * (x + 100.0), 0.0), 100.0);

  # Board temperature
  - platform: internal_temperature
    id: info_brd_temperature
    name: "[board] Temperature"
    icon: "mdi:information-box-outline"
    unit_of_measurement: "°C"
    entity_category: diagnostic
    update_interval: 1min



# BUTTONS
# ================================================================
button:
  # Restart button
  - platform: restart
    id: btn_restart
    name: "Restart"

  # Factory reset button
  - platform: factory_reset
    id: btn_factory_reset
    name: "Reset with Defaults"



# INTERVALS
# ================================================================
interval:
  - interval: 10s
    then:
      - if:
          condition:
            binary_sensor.is_on: status_connection
          then:
            - output.turn_on: led_service
            - delay: 100ms
            - output.turn_off: led_service
          else:
            - output.turn_on: led_service



# DIAGNOSTIC SENSORS
# ================================================================
text_sensor:
  # Wi-Fi Info
  - platform: wifi_info
    ip_address:
      id: info_IP
      name: "[network] IP"
      icon: "mdi:information-box-outline"
      entity_category: diagnostic
    ssid:
      id: info_SSID
      name: "[network] SSID"
      icon: "mdi:information-box-outline"
      entity_category: diagnostic
    bssid:
      id: info_MAC
      name: "[network] MAC"
      icon: "mdi:information-box-outline"
      entity_category: diagnostic

  # Board Master Info
  - platform: template
    id: info_brd_master
    name: "[board] Master"
    icon: "mdi:information-box-outline"
    entity_category: diagnostic
    update_interval: 1d
    lambda: |-
      return std::string("${board_master}");

  # Board Slave Info
  - platform: template
    id: info_brd_slave
    name: "[board] Slave"
    icon: "mdi:information-box-outline"
    entity_category: diagnostic
    update_interval: 1d
    lambda: |-
      return std::string("${board_slave}");

Note that I repurposed the GPIO from the unused button six (btn_6_pin) for the LED. In other words, for the RGB LED: G (green) is hardwired to the 3.3V power line, R (red) is tied to the board’s built-in LED (led_service_pin) that indicates connection status, and B (blue) is on led_action_pin, which I moved from the unused button.

To adapt it for your own setup, don’t forget to set the SSID/pass for your network, as well as the AP mode access and system-side access, including the API key (these lines are highlighted in the example above). I pull these values from a common secrets.yaml file shared by all my controllers (example shown):

wifi_ssid:      "MyWiFyck"
wifi_password:  "b0brkyrva"
ota_password:   "ol0lo"
ap_password:    "popya4sa"
api_key:        "mnoGAbuKoV_AFtarPESHiEsho="

Otherwise, you can pretty much leave everything as is.

Some notable features of the configuration:

• There’s built-in logic that cuts off the internal amplifier whenever a 3.5mm jack is plugged in. The board automatically checks if its own amplifier is in use or if it’s switched over to external.
• The Mute button saves the current volume when pressed. When you press it again, it restores that exact volume level. This works whether you press the physical hardware button on the device or call it remotely from the server.

This may not be super relevant to the finished version of the device as presented here, since it doesn’t have any external outputs, but I’m big on standardization—and who knows what I’ll use this same firmware config for in the future.

And, just to repeat: I haven’t tested the microphones in these examples. One of them (the left one) is initialized and recognized by the system, supposedly. Whether it’s actually picking up sound and sending it anywhere is another story… For now, I don’t need that feature and I’m not really interested in it, so I’m putting off testing until later. If and when I need it, I’ll update the article with more detailed info.

That’s the situation so far…