Experimental hardware project: this guide targets the 2021 Echo Show 5 Gen 2, known as cronos. It is not a generic Android-tablet procedure. Its unlock path can permanently brick the device if low-level firmware is mismatched. A cheap experimental device is acceptable; improvising boot-chain images is not.

The finished appliance

Echo Show 5 Gen 2 → LineageOS → VACA + Home Assistant Assist
                                  ↓
                       native Xena client (last)
local wake word → authenticated LAN bridge → Hermes → TTS reply

The project has three useful end states. Stop at any point that delivers enough value:

  1. Owned smart display: LineageOS, no Amazon login/Alexa dependency, and a Home Assistant room dashboard.
  2. Home Assistant voice display: View Assist Companion App (VACA) supplies wake word, dashboard and Home Assistant Assist integration.
  3. Xena appliance: a custom Android client and private LAN bridge provide push-to-talk first, then an always-listening local-wake-word Hermes experience.

Research status

A device-specific TWRP tree, an unofficial LineageOS 18.1 cronos release, and recent project reports establish that this is technically plausible. It is not official LineageOS support and the comprehensive conversion write-up is recent, so validate compatibility again against the exact device and installed build.

Reported LineageOS capability: touch, Wi-Fi, Bluetooth, speaker, microphone and brightness. The built-in camera is currently reported as non-functional. That does not affect external Home Assistant camera views.

Phase 0 — intake: preserve choices

Do this before normal Wi-Fi, updates or a personal Amazon login.

  1. Photograph rear label, PSU, screen condition and the exact software/device-information page.
  2. Confirm Echo Show 5 Gen 2 / 2021 / cronos. Do not apply this to Gen 1, Gen 3, or another Echo Show.
  3. Record the Fire OS build privately. Never publish serial numbers, MAC addresses or screenshots containing them.
  4. Confirm the seller has deregistered the device; factory-reset only if necessary.
  5. Test display, touch, speaker, microphone, buttons and power behaviour.
  6. Put the device on a constrained voice/IoT network that can reach Home Assistant and the future bridge, rather than broad management-network access.
  7. Recheck the current unlock material for the recorded build. Stop if tooling does not explicitly recognise it.

Exit gate: actual model/build recorded, basic hardware tested, seller linkage cleared, compatibility revalidated.

Phase 1 — unlock, recover, then install LineageOS

Non-negotiable rules

  • Never manually substitute an older or different preloader, LK, TEE, or other boot-chain image.
  • Anti-rollback fuses mean low-level downgrade mistakes can be permanent.
  • Do not begin without a proven recovery route and two offline backup destinations.
  • Treat the current cronos conversion notes as a research source—not a substitute for confirming the exact device/build.

Procedure

  1. Read the current device-specific unlock, recovery and anti-rollback documentation end-to-end.
  2. Build a private workstation folder containing only model/build-matched assets. Record source URLs and checksums locally.
  3. Confirm ADB/USB connectivity and recovery prerequisites before unlock work.
  4. Use only the version-aware cronos unlock path. If it detects an unknown build or asks for a manual firmware selection, stop.
  5. Once recovery/TWRP access exists, create every backup the validated procedure requires.
  6. Copy those backups to two physical locations and verify they are readable before continuing.
  7. Prove recovery/boot behaviour once before changing the OS.
  8. Verify the unofficial LineageOS archive checksum and model assertion, then flash only the matching cronos release.
  9. Test three cold boots plus Wi-Fi, touch, audio output, microphone, Bluetooth, brightness, buttons and launcher persistence.
  10. Record limitations. Do not rely on it for a critical alarm, security camera or safety function until it has earned trust.

Rollback rule: use TWRP and validated backups. Never attempt boot-chain downgrade experiments.

Phase 2 — Home Assistant smart display and Assist

Use View Assist and View Assist Companion App (VACA) after LineageOS is stable. VACA is an Android smart-display companion that provides dashboard display, Home Assistant device controls, wake-word support and per-device HA voice-assistant selection.

Procedure

  1. Install a lightweight launcher and prove it survives a reboot.
  2. Install VACA through its supported Home Assistant integration process.
  3. Create a 960 × 480, kiosk-style room dashboard:
    • temperature/humidity and useful alerts;
    • large light/climate controls;
    • one live camera maximum; use snapshots for camera grids;
    • no dense cards or expensive animations.
  4. Configure VACA home/dashboard routes. Make it the default launcher only after manual launches and reconnects work.
  5. Choose the Assist voice pipeline deliberately. Use local wake word and local STT/TTS where practical; otherwise document exactly which service receives audio/transcripts.
  6. Test ten real household commands plus screen sleep/wake, mic mute, Wi-Fi recovery and a complete device reboot.

Security: never embed a privileged HA long-lived token in an APK, public URL or dashboard YAML. Use the companion flow or a restricted identity.

Phase 3 — prove Hermes voice on the device

Hermes already supports Telegram voice messages, CLI push-to-talk and Discord voice channels. It does not currently provide a turnkey Android/Echo satellite protocol.

Before building custom software:

  1. Confirm Hermes gateway, STT and TTS configuration on the EliteDesk without changing global settings blindly.
  2. Install Telegram on the LineageOS Echo and test a voice note to Xena: record → transcribe → Hermes reply → spoken audio playback.
  3. Optionally test a private Discord voice channel for a more natural real-time conversation.
  4. Measure turn latency, mic volume, speaker quality and device responsiveness.
  5. Choose push-to-talk as the native-app V1 unless real use proves a wake word is essential immediately.

Exit gate: at least one reliable end-to-end spoken Hermes turn from the Echo, in the intended Hermes session/profile.

Phase 4 — build the native Xena appliance last

The custom app should be an owned Android client plus a private LAN voice bridge on the EliteDesk. It should not expose Hermes directly to the Internet or hard-code provider, Home Assistant, Telegram, Discord or privileged credentials in the APK.

V1: native push-to-talk

Press and hold → Android records bounded audio → authenticated LAN bridge
→ STT → Hermes conversation session → TTS → Echo playback
ComponentResponsibility
Android appXena state UI, microphone permission, press-to-talk, cancel/retry, playback and clear listening/speaking indicators.
LAN bridgePer-device authentication, audio limits, STT/TTS dispatch, Hermes session routing, temporary-file cleanup, redacted health logs.
HermesDedicated restricted appliance session/profile with deliberate tool and household-access policy.
Home AssistantOptional visual state/cards, not the required Hermes transport.

V1 acceptance criteria: a press/release voice turn succeeds; a failed network request recovers cleanly; unauthenticated requests are rejected; no secret is extractable from the client.

V2: local wake word and voice activity detection

Only begin once V1 is boringly reliable.

  1. Choose an on-device wake-word engine compatible with the installed Android version and Echo hardware.
  2. Keep idle microphone processing local. Wake word itself must not stream ambient audio to a service.
  3. Add voice activity detection/end-of-turn handling, visible listening state, cancel control and timeout.
  4. Preserve physical and software mic-mute behaviour; mute must always win.
  5. Test echo cancellation: Xena must not wake herself while speaking.
  6. Measure false accepts, false rejects, clipped endings and total latency during a week of ordinary household use.

V3: appliance polish

  • low-CPU listening/thinking/speaking states;
  • visual Home Assistant cards from a constrained data model;
  • quiet hours and per-room volume;
  • optional interruption/barge-in only if the audio stack behaves reliably;
  • diagnostics for app, bridge, STT, Hermes and TTS health—never raw private transcripts.

Privacy and operational rules

Amazon-independent does not automatically mean fully local. Keep a small decision record for each phase:

DataDecide and document
Wake wordLocal only.
AudioMaximum turn length, temporary-file deletion and retention policy.
STT/TTSLocal provider or named cloud provider.
Hermes/LLMModel/provider receiving the transcript.
BridgeLAN-only route, per-device token, TLS/authenticated reverse proxy, rate limit and update plan.
LogsHealth metrics only; secrets and raw transcripts redacted/minimised.

Practical troubleshooting

SymptomFirst check
Tool does not recognise firmwareStop. Record exact build; do not force a low-level image.
BootloopRecovery/TWRP access and verified backup integrity.
Dashboard resetsLauncher/VACA persistence and reduce dashboard complexity.
Quiet voiceRecord a sample; check Android permission/gain before blaming STT.
HA unavailableTest local DNS/network and HA endpoint; do not weaken HA authentication.
Hermes turn failsIndependently test bridge authentication, STT, Hermes session dispatch and TTS.
False wake upsCollect timestamped non-content metrics, tune locally, preserve mute.

Progress and next action

The live execution tracker is maintained in the KB repository at projects/echo-show-local-voice-appliance/PROJECT.md.

Current status: the device has been ordered; no device-side action has occurred.

Next action on arrival: photograph the label and exact Fire OS/device-version screen before connecting to normal Wi-Fi, accepting updates or using a personal Amazon account.