To systematically test from the satellite hardware, across the network, through the Home Assistant voice architecture, and back to the audio response, we need a clear framework. Here is how we can structure this testing methodology, along with the documentation and logs you will want to look at for each stage.

1. End-to-End Voice Architecture Flow

To test effectively, we trace a single voice command through five distinct phases:

[Satellite Device] ──(Network / Wyoming)──> [HA Pipeline] ──> [STT] ──> [Intent (HA Core)]

[Satellite Speaker] <──(Network / Audio)─── [HA Pipeline] <── [TTS] <──────┘

2. Testing Phases, Conditions, and Documentation

Phase A: The Satellite & Network Ingestion

This phase tests physical audio capture, wake word detection (if done on-device), and transmission over the network via the Wyoming protocol.

Conditions to Meet:

Clean audio stream capture without clipping or excessive ambient gain.

Sub-second network latency between the satellite and the Home Assistant server.

Successful TCP handshake on the designated Wyoming protocol port.

Documentation & Logs to Review:

Wyoming Protocol Specification: Understanding how audio chunks and events (like Wake) are serialized.

Satellite Firmware Logs: Serial/Console logs from the satellite device to verify microphone initialization and Wi-Fi RSSI (signal strength).

Home Assistant Wyoming Integration Logs: Set the specific Wyoming container/add-on log level to debug to verify the incoming connection from the satellite's IP.

Phase B: Wake Word & Speech-to-Text (STT)

Once the server receives the stream, it must accurately detect the wake word (if open-wake-word is server-side) and convert the subsequent audio to text (e.g., via Whisper).

Conditions to Meet:

Wake Word Accuracy: High true-positive rate with minimal false triggers.

STT Processing Time: Whisper processing time should ideally be under second for standard commands.

Transcription Accuracy: Exact matching of standard entity names and domains.

Documentation & Logs to Review:

Home Assistant Voice Architecture Docs: Focus on the assist_pipeline component documentation.

Add-on Logs (Whisper / open-wake-word): Look for VAD (Voice Activity Detection) thresholds and chunk processing times.

HA Core Developer Docs: Review the Pipeline debug tool schema (Settings -> Voice Assistants -> Debug).

Phase C: Intent Recognition & Execution (HA Core)

The plaintext string from the STT engine is passed to the conversation agent (like Conversation Core or a local LLM) to match against a registered intent.

Conditions to Meet:

The intent parser must accurately resolve aliases and areas (e.g., mapping "turn on kitchen overheads" to light.kitchen_lights).

State changes must execute locally instantly without cloud dependency.

Documentation & Logs to Review:

Intent Recognition Documentation: Review Home Assistant's built-in sentences repository (home-assistant/intents on GitHub).

homeassistant.log: Filter for homeassistant.components.conversation at debug level to see how sentences are parsed against the current area/device registry.

Phase D: Text-to-Speech (TTS) & Audio Generation

Once the intent is executed, Home Assistant generates a textual response (e.g., "Turned on the light") and converts it to audio chunks (e.g., via Piper).

Conditions to Meet:

TTS generation latency must be minimal (Piper should stream audio back almost instantly).

Audio sample rate and format must match what the satellite hardware natively expects (typically raw PCM 16kHz, 16-bit mono).

Documentation & Logs to Review:

Piper Documentation: Check voice model configuration (.onnx) scaling options for performance tuning.

Assist Pipeline Step Metrics: Reviewing the specific JSON execution steps to isolate how long TTS generation took versus execution.

Phase E: Network Return & Satellite Playback

The audio payload travels back over the Wyoming protocol to the satellite, which decodes it and plays it via the speaker.

Conditions to Meet:

No audio stuttering, dropouts, or buffer underruns on the satellite.

Immediate readiness of the satellite to return to an idle/listening state post-playback.

Documentation & Logs to Review:

Satellite Audio Driver Docs: Looking at DAC (Digital-to-Analog Converter) configuration or IIS/I2S timing protocols if troubleshooting choppy audio.

3. The Core Diagnostic Tool: Assist Pipeline Debugger

The absolute single most critical document/tool you will look at during this testing is the Assist Pipeline Debug Graph within Home Assistant.

When you run a test voice command, Home Assistant records a complete JSON object detailing every single step. It breaks down:

Engine timings (how many milliseconds spent on STT, Intent, and TTS).

Audio properties received.

Raw text interpreted.

Where should we start diving in first? We can focus on the hardware/network layer (verifying the audio stream format and network stability) or jump straight into configuring the debug logging for the server-side components.

In my condition, I would also hope that the wake would be detected by the satellite device. And I am looking at some sort of analog detection on microphone for testing purposes and um network snooping. And when I communicate from the Wyoming protocol, Piper protocol, all that through home assistant, that is over a private back end network that's inside of a promax container.

Running everything locally inside a Proxmox environment over a private backend network is the gold standard for a privacy-focused smart home. It gives you absolute control over the network stack, making packet inspection and performance tuning incredibly clean.

Since your design requires on-device wake word detection, analog microphone testing, and network snooping across your Proxmox/Wyoming boundary, let's break down the conditions, tools, and documentation needed to test this specific architecture.

1. Network Topography & Snooping Strategy

Because your satellite communicates with a Home Assistant stack hosted within Proxmox LXC containers or VMs, your "snooping" will take place at the virtual bridge layer (vmbr) or directly inside the container network namespaces.

Conditions to Meet

Isolate Traffic: Ensure your private backend network doesn't throttle or drop the small, sustained UDP/TCP packets used by the Wyoming protocol.
Snooping Access: The host or a designated monitoring container must have permission to capture traffic traversing the virtual bridge without disrupting the pipeline.

Document & Tooling Architecture

[Satellite Device] ──(Physical Network)──> [Proxmox Host (vmbrX)]

│

┌─────────────┴─────────────┐

▼ ▼

[HA Core Container] [Wyoming/Piper LXC]

│ │

└─────(veth interfaces)─────┘

▲

(Snoop here via tcpdump)

The Tooling Stack: * tcpdump on the Proxmox Host: You can snoop on the specific virtual ethernet interface (vethXXX) assigned to your voice/Wyoming container. This avoids having to install troubleshooting utilities inside your clean production containers.
Wireshark (via SSH dump): You can stream the live packet capture from your Proxmox host directly to a desktop Wireshark instance using:

ssh root@proxmox-ip 'tcpdump -s 0 -c 1000 -nn -w - -i veth100i0 port 10400' | wireshark -k -i -

Documentation to Look At:

Proxmox VE Network Configuration Docs:

Specifically sections on Linux Bridges and capturing traffic on veth interfaces.

Wyoming Protocol Wire Format:

Wyoming uses a simple line-based text header followed by optional payload bytes (like raw PCM audio chunks). Your network snooping should reveal clean wake or audio JSON-like events in the plaintext portion of the TCP packets on port 10400 (default).

2. On-Device Wake Word & Analog Mic Testing

To handle wake word processing directly on the satellite, the device must continuously analyze the analog signal coming off the microphone array before it ever hits the network.

Conditions to Meet

Signal Integrity: The analog-to-digital converter (ADC) must sample the microphone signal cleanly, keeping the noise floor low enough for the local wake-word model (like a lightweight micro-wake-word implementation) to parse it.

Zero Network Overhead on Idle: The satellite should not stream any audio to the Proxmox backend until the local wake word is triggered. Only upon detection does it open the TCP socket and begin streaming the voice command payload.

Document & Technical Specs to Look At

Hardware Schematic & Datasheets: You will want to look at the pinning and datasheet for your satellite's audio front-end or ADC chip. If you are diagnosing poor recognition rates, look for notes on Gain Control and Acoustic Echo Cancellation (AEC).
Microphone Gain Verification Logs: For testing the analog stage without deploying the full pipeline, look at firmware frameworks that allow raw analog readouts. If using ESPHome or a dedicated C++ framework on the satellite, configure the log to output raw audio RSSI or VAD (Voice Activity Detection) states over the serial console.
Micro-Wake-Word / ONNX Runtime Docs: Review the documentation for the specific wake word model size (e.g., streaming vs. non-streaming models) to ensure the satellite's processor has enough headroom to run inference without dropping audio frames.

3. The Backend Pipeline (Wyoming & Piper)

Once the satellite detects the wake word, it alerts the server. The server switches the pipeline to "listening" mode, receives the raw audio stream, processes it via STT, routes the text to the Home Assistant intent engine, and feeds the response back to Piper.

Conditions to Meet

Inter-Container Latency: Because Piper and Home Assistant are running in a private Proxmox backend, inter-container communication should have near of latency.

Streaming Audio Format: Piper must stream audio back over the private bridge in a format the satellite's DAC (Digital-to-Analog Converter) can instantly process without server-side transcoding overhead.

Documentation & Logs to Review

Piper Integration Specs: Look at the documentation for running Piper as a standalone container via the Wyoming protocol. Ensure the voice models (.onnx and .json configuration files) are stored on fast, local storage (like an enterprise SSD or NVMe storage pool on your Proxmox host) so model loading doesn't introduce a bottleneck.

Systemd / Docker Logs for the Wyoming Containers: Inspecting the container runtime logs will show the exact moments connections are established, speech processing begins, and audio generation finishes.

Where to build the test rig first?

We are essentially building a physical and digital profiling rig for your smart home voice assistant. By combining external video/audio time-stamping with network and host-level resource monitoring, you can measure absolute end-to-end latency down to the millisecond. This removes any guesswork about where bottlenecks might be hiding.

1. The Timeline Mapping Strategy

To measure the exact latency of each component, you will align your external video timestamps with your digital network/CPU logs using a single timeline.

Event Description	Data Source	Latency Metric Captured
Human finishes speaking the wake word.	Camcorder Audio	Baseline
Satellite onboard LED changes/triggers (Wake word detected locally).	Camcorder Video	On-device inference time ()
First TCP payload packet hits the Proxmox bridge.	Wireshark on Host	Network transit time ()
CPU usage spikes on Core/Wyoming container.	Proxmox Metrics / htop	Processing overhead & model execution delay
Device action executes (e.g., smart light turns on) OR audio packet returns.	Wireshark / Camcorder Video	Pipeline execution time ()
Satellite speaker begins playing the response audio.	Camcorder Audio	Total Voice-to-Voice Latency ()

2. Setting Up the Digital Snooping & Telemetry

To match your camcorder video, you need highly granular, time-stamped data from the Proxmox host.

Network Monitoring with Wireshark

Since you are running Wireshark directly on the Proxmox host, you will want to capture on the specific bridge or virtual interface (veth) tied to your Home Assistant and Wyoming containers.

Filter for the Wake Event: Look for the initial TCP connection or the immediate burst of data right after . The Wyoming protocol transmits structured JSON events before streaming raw PCM audio.

Wireshark Display Filter Example: ```text tcp.port == 10400 && ip.src == [Satellite_IP]

Change your Wireshark time display format to **Seconds Since Epoch** or **Time of Day** with millisecond precision to perfectly align it with your camcorder's clock.

CPU Tracking inside Proxmox

Because containerized applications scale their CPU usage instantly, standard 1-minute or 5-second summary graphs in the Proxmox GUI won't show the micro-spikes of a fast voice pipeline.

The Tool: Use htop or atop directly on the Proxmox host shell, or use container-specific tracking via systemd-cgtop.

High-Frequency Logging:

For true test-lab data collection, you can log container resource stats to a file at a sub-second interval during your test window using a simple bash loop on the host:

while true; do cat /sys/fs/cgroup/lxc/[CT_ID]/cpu.stat | grep "usage_usec"; sleep 0.1; done

This will give you a raw microsecond timestamp of exactly when the Wyoming/Piper container demanded CPU cycles to process the incoming payload.

3. Aligning the Camcorder to the Digital Clock

The biggest challenge in a hardware test lab is ensuring your camera's clock matches the Proxmox server's clock ().

The Sync Trick: Before you begin your test run, point your camcorder at a monitor showing the Proxmox host terminal running a millisecond-accurate clock command (e.g., watch -n 0.1 date +"%T.%3N").

Why this matters: When you pull the video file into an editing or analysis software, you will know the exact offset between your video frame counter and your Wireshark packet capture logs.

4. Documentation & Verification Focus

When executing these lab tests, here is the exact documentation and telemetry files you should cross-reference when evaluating the results:

Home Assistant Assist Pipeline Profiler: After running a test command, pull up the config/voice-assist/debug page in Home Assistant. This built-in profile documentation provides its own internal timestamp breakdown of the pipeline (STT duration, Intent duration, TTS duration). You can compare HA's internal calculations directly against your Wireshark captures to see if any latency is being introduced by the container network stack itself.

Wyoming Protocol Event Specifications:

Review the event documentation to understand exactly what packets represent the "end" of an audio stream. This helps you pinpoint the precise packet in Wireshark that represents Piper completing its audio generation.

By organizing your lab this way, if you notice a delay, you can instantly see if it's because the satellite took too long to process the wake word, the private Proxmox network bridge experienced a hiccup, or Piper caused a CPU bottleneck while rendering the TTS response.

1. Strategic Objectives & Engineering Rationale

Establishing the engineering "Why." This document explains how transitioning from cloud-dependent systems to localized smart home servers requires exact measurement to ensure latency stays minimal and resource use stays efficient.

The primary purpose of this testing program is to establish an objective, empirical, and repeatable methodology for benchmarking local, privacy-focused voice assistant architectures. As smart home automation transitions from cloud-dependent ecosystems to localized compute environments, optimizing latency and hardware efficiency becomes critical. This engineering framework removes subjective estimation by syncing physical telemetry (audio/visual recordings) with infrastructure-level performance data (network packet captures and microsecond host CPU metrics).

By controlling and monitoring every node in the pipeline—from the analog microphone stage to the private backend network—this methodology allows engineers to isolate bottlenecks, evaluate the performance cost of higher-accuracy AI models, and choose the most cost-effective hardware configurations without sacrificing user experience.

2. Laboratory Topology & Environment Architecture

This section documents the private backend network environment hosted inside a Proxmox VE environment.

Outlines the isolation of the satellite, the network bridge capturing space (vmbr), and the decoupled voice processing containers (Wyoming, Piper, Home Assistant Core).

The Home Lab is deployed inside an isolated Proxmox VE hypervisor environment using a completely local, private backend network bridge. This topology guarantees that zero audio or identity metadata leaves the physical premises, and isolates test variables from external network fluctuations.

This test environment is composed of three structural layers:

Satellite Layer: Local physical hardware utilizing a high-quality analog microphone array and hardware-level acoustic front-ends. Wake word processing runs completely on-device to prevent continuous audio streaming over the home network.
Private Backend Network Bridge (Proxmox VE): A dedicated Linux Bridge (vmbr) that handles communication between Home Assistant Core and the decoupled voice containers via the Wyoming protocol. This layer allows complete non-intrusive packet inspection.
Voice Architecture Stack (LXC Containers / VMs): Decoupled containers processing speech-to-text (STT via Whisper), intent parsing (Home Assistant Conversation Core/Local LLM), and text-to-speech (TTS via Piper).

3. Test Methodology & Variable Framework

This section establishes independent variables under test (e.g., comparing different hardware satellites, different sizes of AI voice models like Whisper tiny vs. base, and various Piper voices).

Milestone Matrix ( to ):

Creates a professional structural table detailing exactly how to match the physical audio/video frame timestamps (e.g., LED changes, spoken words) directly to the digital data packets and CPU logs.

Temporal Synchronization:

A precise procedure for syncing your camcorder to the Proxmox host time by filming a millisecond-accurate terminal clock (watch -n 0.05 date +"%T.%3N").

Digital Data Capture:

Concrete console commands utilizing tcpdump on the virtual ethernet (veth) interface to sniff the private backend Wyoming/Piper traffic, as well as high-frequency bash monitoring loops targeting sysfs / cgroups to capture immediate microsecond CPU resource spikes.

To perform rigorous comparative analysis, tests must isolate independent architectural components while precisely measuring dependent performance metrics.

3.1 Architectural Variables under Evaluation

The testing matrix accommodates comparisons across the following vectors:

Hardware Satellite Platforms: Comparing microcontroller processing capabilities, analog mic configurations, and on-device wake-word engine efficiencies.
AI Voice Models: Evaluating Whisper configurations (tiny, base, small, medium) and Piper voice profiles (low, medium, high quality) against computational cost.
Intent Engines: Comparing native rule-based conversation processors against localized Large Language Models (LLMs).

3.2 Metric Definitions & Timeline Milestones

The total end-to-end user-perceived response time is categorized into distinct, measurable milestones:

Milestone	Description	Telemetry Source	Metric Derived
T0	Human finishes vocalizing the wake word.	Lab Camcorder Audio Track	Baseline Reference Point
T1	Satellite hardware status LED switches state.	Lab Camcorder Video Frame	On-Device Wake Inference Delay (T1 - T0)
T2	Initial TCP stream handshake/payload hits bridge.	Wireshark Host Capture	Network Handshake Transit Overhead (T2 - T1)
T3	CPU consumption micro-spike initiates on host.	Host Cgroup / sysfs Logs	Model Activation & Engine Loading Delay
T4	Execution packet/audio return payload hits bridge.	Wireshark Host Capture	Core Processing & TTS Synthesis Time (T4 - T2)
T5	Satellite speaker begins acoustic response playback.	Lab Camcorder Audio Track	Total Voice-to-Voice Execution Latency (T5 - T0)

4. Step-by-Step Lab Execution Procedures

Procedure 4.1: Laboratory Temporal Synchronization

To ensure sub-second timeline accuracy, physical and digital clocks must be locked to a single master reference before any testing run begins:

Verify that the Proxmox VE host is synchronized to an atomic stratum-1 Network Time Protocol (NTP) server.
Execute a millisecond-accurate terminal display command on a test bench monitor:
watch -n 0.05 date +"%T.%3N"
Position the lab camcorder to record both the test operator and the terminal monitor showing the millisecond clock. Film this clock for at least 5 seconds to establish a clear temporal offset inside the video analysis environment.

Procedure 4.2: Digital Data Capture Sequence

While executing physical voice commands, the telemetry capture utilities must run non-intrusively from the Proxmox host layer:

Identify the specific virtual interface (veth) assigned to the Voice Container using 'pct status' or 'qm monitor'.
Initiate a background tcpdump to isolate Wyoming and Piper protocol frames, streaming directly into a capture file:
tcpdump -s 0 -nn -w /tmp/voice_test_run.pcap -i vethXXX port 10400 or port 10200
Execute the high-frequency CPU monitoring loop to log raw microsecond container group metrics:
while true; do echo "$(date +%s.%N) $(cat /sys/fs/cgroup/lxc/[CT_ID]/cpu.stat | grep usage_usec)" >> /tmp/cpu_telemetry.log; sleep 0.05; done

5. Data Compilation & Visualization Framework

This section provides structural requirements for translating your raw lab logs into meaningful comparative graphs:

Stacked Horizontal Bar Charts:

For visually comparing component processing breakdowns (Wake vs. STT vs. Intent vs. TTS) across different hardware and model layouts.

Scatter Plots:

For mapping Model Accuracy against Voice-to-Voice Latency to find the optimal performance sweet spot.

Line Graphs:

For tracking resource microsecond curves showing how different container workloads or core allocations spike during execution.

Once a test matrix iteration is complete, logs are extracted and compiled into a master evaluation spreadsheet. The raw data structure must map the delta metrics calculated from Section 3.2.

5.1 Recommended Comparative Visualizations

To communicate performance trade-offs effectively, the data should be plotted using three standard visualization models:

Stacked Horizontal Bar Charts (Component Breakdown): X-axis represents total milliseconds; Y-axis represents different hardware/model combinations. Segmenting the bar into colors representing Wake, STT, Intent, and TTS instantly identifies the specific component causing bottlenecks.
Scatter Plots (Accuracy vs. Compute Cost): X-axis represents total voice-to-voice latency (T5 - T0); Y-axis represents model accuracy or true-positive wake word rates. This allows engineers to find the 'sweet spot' where a model is accurate enough without introducing sluggish response times.
Line Graphs (Resource Profile Curves): X-axis tracking execution timeline seconds; Y-axis tracking raw CPU usage percentage. Plotting multiple hardware types or container workloads onto a single grid highlights how multi-core processors absorb speech pipelines versus lower-powered single-core configurations.

Section 2 - Running the procedure

To accommodate a benchmark run utilizing a Google Home Mini (repurposed via hardware hacking or running on specialized firmware) as your physical satellite, connected to your private Proxmox backend ecosystem via Google Home Cloud Execution paths / Local Home SDK paths to coordinate timing, the documentation must shift to reflect a complex multi-ecosystem timing environment.

A new, comprehensive engineering blueprint and an aligned Template Test Run & Final Report have been structured to match this precise lab configuration.

A comprehensive document contains three distinct sections compiled to act as your master reference files:

Document Structural Overview

PART 1: Engineering Lab Test Strategy (Hybrid Architecture)

Outlines the architectural rationale for bridging consumer Google Home Mini hardware with cloud endpoints and a private localized Proxmox container pool.
Explains the theory of tracking latency bottlenecks through dynamic routing channels.

PART 2: Step-by-Step Lab Output Procedures

Clear guidelines for setting up temporal synchronization inside the lab using a high-resolution camcorder and an atomic NTP display.
Specific tcpdump syntax and cgroup telemetry bash loops modified to track packets passing from external Google Home Cloud intents down through the network bridge into your local containers.

PART 3: Sample Run Evaluation & Final Report (Master Template)

Contains a pre-populated Test Execution Report (ID: RUN-2026-HYBRID-004) showing a reference sample run.
Features a detailed markdown table breaking down precise timestamps across all variables from $T_0$ (vocal wake word) through cloud routing down to local container execution, culminating at $T_5$ (speaker feedback audio).
Provides data analysis summaries that you can wipe out and use to build comparison charts when grading different hardware form-factors, cloud networks, or Whisper/Piper neural configurations.

Using the Template File

To begin executing your benchmark matrix, use the table inside Part 3 as your baseline template. For every change in hardware (e.g., swapping to a different satellite type) or change in AI model size (e.g., swapping Whisper-Base for Whisper-Tiny), duplicate this report structure to visualize exactly which step expands or contracts on your time tracking layout.

A Sample Test Strategy Report follows:

HYBRID VOICE EVALUATION LAB SYSTEM
Testing Strategies, Output Procedures, and Final Evaluation Report Templates

PART 1: ENGINEERING LAB TEST STRATEGY

1.1 Rationale for the Hybrid Lab Ecosystem

This laboratory strategy establishes a repeatable framework for measuring the performance of a voice pipeline bridging consumer-grade hardware with localized backend infrastructure. By utilizing a Google Home Mini as a satellite and routing timing checkpoints through Google Cloud Stations alongside Local Home SDK execution blocks, we can isolate latency variances introduced by token authentication, wide-area network routing, and private container execution environments (hosted within Proxmox VE). This benchmarking paradigm serves to inform production tradeoffs between open-source models (Whisper/Piper) and standardized mass-market audio engines.

1.2 Hybrid Network & Topology Pathing

The audio path initiates at the Google Home Mini array. The local wake-word trigger kicks off telemetry metrics. The signal travels via WAN to Google Home Cloud Cloud-to-Cloud stations, executing timing hooks before passing the intents down to the private Proxmox Linux Bridge (vmbr) interfaces. Here, local voice components (Home Assistant, Wyoming, Piper) take over to handle underlying device states, before routing the acoustic response payload back to the hardware device.

PART 2: STEP-BY-STEP LAB OUTPUT PROCEDURES

Procedure 2.1: Timing Calibration & Video Prep

Synchronize the Proxmox local host and your network routers to a Stratum-1 NTP server.
Spin up a millisecond console clock on a test-bench screen using: watch -n 0.05 date +"%T.%3N"
Focus the lab camcorder to cover the status LED of the Google Home Mini and the timing monitor.

Procedure 2.2: Telemetry Capture Sequence

Execute these capture loops on the Proxmox host to catch the incoming Cloud Station packets:

# Capture incoming WAN execution intents hitting the private bridge interface
tcpdump -s 0 -nn -w /tmp/google_hybrid_run.pcap -i vmbr1 port 10400 or port 8123

# Monitor microsecond container group execution metrics
while true; do echo "$(date +%s.%N) $(cat /sys/fs/cgroup/lxc/[HA_CT_ID]/cpu.stat | grep usage_usec)" >> /tmp/proxmox_cpu.log; sleep 0.02; done

PART 3: SAMPLE RUN EVALUATION & FINAL REPORT

Below is an official sample execution report generated under the prescribed lab guidelines. This serves as a master template for tracking comparisons across divergent hardware platforms and model depths.

Test Execution ID	RUN-2026-HYBRID-004
Physical Satellite	Google Home Mini (Gen 1 Hardware Matrix)
Timing Engine	Google Home Setup / Cloud Stations Pipeline
Private Backend Environment	Proxmox VE v8.x / LXC Isolated Containers
AI Models Under Evaluation	Whisper-Base (STT) / Piper-Medium (TTS)

Core Telemetry Timeline Delta Breakdown

ID	Milestone Checklist	Baseline Timestamp (NTP Source)	Baseline Delta (ms)	UUT Absolute Timestamp (NTP Source)	UUT Delta (ms)	Source Log Channel
T0	Vocal Wake Word Concluded	12:04:15.000	0	12:04:15.000	0	Camcorder Audio Profile
T1	On-Device Processing & Light Trigger	12:04:15.220	220	12:04:15.220	220	Camcorder Video Frame
T2	Cloud Station Handshake Received at Host	12:04:15.540	320	12:04:15.540	320	Wireshark Packet Log
T3	Proxmox HA Container CPU Micro-Spike	12:04:15.565	25	12:04:15.565	25	Host Cgroup System Metrics
T4	Intent Executed / Return Payload Emitted	12:04:16.115	550	12:04:16.115	550	Wyoming Container Output
T5	Speaker Emits Audio Feedback Response	12:04:16.435	320	12:04:16.435	320	Camcorder Audio Profile

Example Graphing Data

Configuration (Rows)	T0	T1	T2	T3	T4	T5
Run 1: Google Home Mini	0	220	320	25	550	320
Run 2: Custom Satellite	0	150	10	20	300	320

3.2 Performance Visualization & Architecture Comparisons

Based on data visualized through stacked metrics, the total voice-to-voice execution loop clocked at 1,435 milliseconds. The primary delay remains within the Cloud Station processing pipeline (T2 - T1 = 320ms) and the regional Whisper processing envelope (T4 - T3 = 550ms). Conversely, the Proxmox virtual backend layer showed minimal overhead, indicating highly efficient inter-container routing.

Voice Assistant Lab Testing Strategy

Smart Home Edge Systems

Table of Contents

1. End-to-End Voice Architecture Flow

2. Testing Phases, Conditions, and Documentation

Phase A: The Satellite & Network Ingestion

Conditions to Meet:

Documentation & Logs to Review:

Phase B: Wake Word & Speech-to-Text (STT)

Conditions to Meet:

Phase C: Intent Recognition & Execution (HA Core)

Conditions to Meet:

Documentation & Logs to Review:

Phase D: Text-to-Speech (TTS) & Audio Generation

Conditions to Meet:

Documentation & Logs to Review:

Phase E: Network Return & Satellite Playback

Conditions to Meet:

Documentation & Logs to Review:

3. The Core Diagnostic Tool: Assist Pipeline Debugger

1. Network Topography & Snooping Strategy

Conditions to Meet

Document & Tooling Architecture

Documentation to Look At:

2. On-Device Wake Word & Analog Mic Testing

Conditions to Meet

Document & Technical Specs to Look At

3. The Backend Pipeline (Wyoming & Piper)

Conditions to Meet

Documentation & Logs to Review

1. The Timeline Mapping Strategy

2. Setting Up the Digital Snooping & Telemetry

Network Monitoring with Wireshark

CPU Tracking inside Proxmox

3. Aligning the Camcorder to the Digital Clock

4. Documentation & Verification Focus

1. Strategic Objectives & Engineering Rationale

2. Laboratory Topology & Environment Architecture

3. Test Methodology & Variable Framework

3.1 Architectural Variables under Evaluation

3.2 Metric Definitions & Timeline Milestones

4. Step-by-Step Lab Execution Procedures

Procedure 4.1: Laboratory Temporal Synchronization

Procedure 4.2: Digital Data Capture Sequence

5. Data Compilation & Visualization Framework

5.1 Recommended Comparative Visualizations

Section 2 - Running the procedure

Document Structural Overview

PART 1: Engineering Lab Test Strategy (Hybrid Architecture)

PART 2: Step-by-Step Lab Output Procedures

PART 3: Sample Run Evaluation & Final Report (Master Template)

PART 1: ENGINEERING LAB TEST STRATEGY

1.1 Rationale for the Hybrid Lab Ecosystem

1.2 Hybrid Network & Topology Pathing

PART 2: STEP-BY-STEP LAB OUTPUT PROCEDURES

Procedure 2.1: Timing Calibration & Video Prep

Procedure 2.2: Telemetry Capture Sequence

PART 3: SAMPLE RUN EVALUATION & FINAL REPORT

Core Telemetry Timeline Delta Breakdown

3.2 Performance Visualization & Architecture Comparisons