4. SYSTEM ARCHITECTURE — THREE TIERS

TIER 0 — ESP32 CONTROLLER (always-on, ~0.5-1W) — rev 3.6
└── Waveshare ESP32-S3-POE-ETH-8DI-8DO: 8 digital OUTPUTS (trigger external Bosch relay panel)
    + 8 DI (ignition/door/reverse wires) + LVD/thermal + BLE proximity + WOL; wired Ethernet.
    NO onboard relays (swappable Bosch panel does the switching). WROOM-32 retired. (start with 1 board)

TIER 1 — RASPBERRY PI 3 B+ (always-on, ~3-5W) — OWNED
├── Mosquitto MQTT broker (all devices connect here)
├── Wake coordinator: phone proximity + door events → WOL → OptiPlex
├── ffmpeg recording of the **Wolfbox dashcam only** (its own 5GHz hotspot) — NOT the perimeter cams
│      (rev 3.3: perimeter cams are recorded by the OptiPlex while awake — see §7.2. A Pi 3 B+ (1GB RAM,
│       USB-2-attached 100Mbit NIC) should not also carry multi-stream perimeter recording: it is the
│       wake-critical broker, and that path must not be starved. Keep its camera duty to the one Wolfbox feed.)
├── ESPresense phone proximity detection
├── Tailscale client
└── NO audio, NO mic, NO Porcupine — voice is entirely OptiPlex's domain

TIER 1 — DELL OPTIPLEX 5080 MICRO (in truck 24/7, hibernates when parked) — THE BOSS
├── i7-10700T CPU-only (no discrete GPU), 32GB RAM
├── Ollama (Qwen3 4B), Porcupine (wake word "Hey JARVIS"), whisper.cpp (STT), TTS (Piper/Kokoro)
├── PipeWire: S24 Ultra BT A2DP → OptiPlex → AUX → Uconnect; auto-ducts music on TTS
├── reSpeaker XVF3800 USB mic array → Porcupine → whisper.cpp → Qwen3 → TTS → Uconnect speakers
├── SH-C31G (CAN via USB), python-can
├── Cameras (Phase 1): records + restreams while awake (no parked 24/7 record)
├── Local-vs-Fireworks router: easy queries local, heavy reasoning → Fireworks API
└── Wakes via: door/proximity → Pi 3 B+ MQTT → WOL

[ TIER 1.5 — Pi 5 + Hailo-8L — ~1 YEAR OUT: becomes always-on camera appliance ]

4.1 Network (rev 3.4 — Cudy owned, likely the single box)

The Cudy LT18 runs OpenWrt, has WiFi 6, and OpenWrt can run Tailscale + subnet routing — so the Cudy probably does all three jobs (LTE internet + LAN router/WiFi + Tailscale), and the GL.iNet may not be needed at all.

Cudy LT18 (OWNED — Keepgo SIM, OpenWrt, WiFi 6, traffic-locked LTE,
           Tailscale SUBNET ROUTER advertising the truck LAN)
├── OptiPlex 5080 (192.168.1.50) — runs its OWN Tailscale client
├── Pi 3 B+ (192.168.1.40) — broker/PWA — runs its OWN Tailscale client
├── (PoE switch) → cameras (.101-108), Waveshare (.110)  ← reached via SUBNET ROUTE (no client)
├── WROOM-32 (.111, if deployed)                          ← reached via SUBNET ROUTE
└── WiFi → Phoenix (.120), S24 Ultra (own client)
   [ small unmanaged switch (~$15) or the PoE switch = the wired backbone if Cudy ports are few ]

Tailscale model (the key concept): being connected to the Cudy does NOT put a device on the tailnet. Two ways in: (a) the device runs its own Tailscale client (OptiPlex, Pi, phone — clean named 100.x addresses), or (b) a subnet router on the LAN advertises 192.168.1.0/24 so the dumb devices that can't run a client (cameras, ESP32, relay board) become reachable through it. Run both: subnet router on the Cudy for the dumb stuff + clients on the smart boxes. ⚠️ **Verify the Cudy can install the Tailscale opkg package** (vendor OpenWrt builds can be locked / short on flash — may need extroot). If it can't cleanly → that's the only reason to buy the GL.iNet (its selling point is one-click Tailscale + subnet router in the GUI). Security: a subnet router exposes the whole truck LAN to your tailnet — incl. the auth-less Mosquitto broker. Lock it with tailnet ACLs so only your devices reach it.

Static IPs on OptiPlex, Pi, Waveshare, cameras. Local works fully offline. Cudy LTE locked to: OpenRouter API (rev 3.34 — swapped from Fireworks) + Tailscale + security JPEG uploads. S24 Ultra on truck WiFi only — music via BT to OptiPlex, not through cell.

4.2 Display Strategy

NOW (rev 3.3): no dedicated tablet purchase — internet is the Cudy LT18 (not a tablet tether), and the dev screen is whatever's on hand (S24 Ultra browser, or a spare tablet you already own) → Chrome → Flask over the Cudy WiFi. SavvyCAN no longer runs "on a tablet via RDP to the Z440" (Z440 shelved) — see §8 for the rev-3 CAN-discovery host (SavvyCAN-Linux on the OptiPlex, or do discovery at home on the Dell Precision before install).

LATER — head unit (rev 3.33, FULL market survey + decision below).

Interface boxes (NAViKS/PAC/Lockpick): REJECTED. ~$300-400 for video-IN only — touch can't be captured from the 2014 QNX Uconnect (hardware wall, unsolved for a decade). At that price, a full-Android head unit (touch) is the better buy. Mayton AutoPro X also rejected (requires factory Android Auto, which a 2014 RAM lacks).

4.2.1 Head-unit decision (rev 3.33; purchase config locked rev 3.35) — ✅ Phoenix Automotive direct, S7865 8GB/128GB Android 14

rev 3.35 update — purchase locked. Bought direct from Phoenix Automotive (phoenixautomotiveinc.com), NOT via the AmericanTrucks/Navos channel — saves ~$267 and skips the AT-forced $150 Midas install. Actual cart total: $695.20 (regular $789.99 → sale, then code 2026 for ~12% off). Variant: S7865 8GB RAM / 128GB ROM / Android 14 / "2013-2018 w/ floor center console w/ Original Auto AC" / Silver-Chrome trim / NO 4G LTE (Cudy LT18 provides cell per §4.1, second cellular radio = wasted hardware). All rev-3.33 reasoning below still holds — the doc's $962 was a stale AT ceiling, manufacturer-direct is cheaper. See §9.4 for the OptiPlex layered-on-top CAN-write voice-control plan that this unit is designed to coexist with (Phoenix handles AC touchscreen baseline; OptiPlex adds voice control of HVAC via parallel B-CAN write).

The market splits into three camps (the organizing insight):

1. Name-brand "digital media receivers" — Alpine, Pioneer, Kenwood, Sony, JVC. ALL closed CarPlay/Android-Auto appliances. None runs open Android, none installs a browser, none takes touch to an external device. The "Android" in Android Auto only means it projects a phone, not that it runs Android. Switching brands = different audio/styling, not a different capability. (Stinger HEIGH10 is the same closed camp — no Play Store.)
2. Open-Android head units (Phoenix, Linkswell/Navos, Atoto, Dasaita, etc.) — run real Android + Play Store → install Chrome → native touch on the OptiPlex UI, no phone. The only camp that fits this build.
3. CarPlay AI Box dongle (Ottocast/Carlinkit, ~$150-250, Android 12/13) — the bridge: plug into a Camp-1 unit's USB/CarPlay, runs full Android, touch passes back through the CarPlay channel. But its video rides the compressed CarPlay pipe (soft + laggy) — wrong for a unit you live in 99% of the time. Only relevant if someone insists on a closed name-brand head unit.

Why a name-brand (e.g. Alpine Halo11) loses for THIS build: even though the Halo11 has an HDMI input (and "video in motion," no parking-brake issue) + iDatalink Maestro + great audio, it cannot show the OptiPlex UI with touch — HDMI-in is view-only (no touch back to the source), and the unit can't run a browser. Touch would require the flaky phone-over-Android-Auto sideload bridge (Google keeps breaking it). Paying ~$1,700 + ~$200 AI-box to degrade the everyday carputer UI through a compressed pipe is backwards. Name-brands win only on audio fidelity + build + factory integration — none of which is the 99% use (OptiPlex UI + streaming + touch).

The key money insight — HDMI-in is a LUXURY here, not a requirement. The §4.5/§9.2 dashboard is a Flask/WebSocket web app by design → it renders perfectly in any open-Android unit's native Chrome over the Cudy WiFi, with full touch. HDMI-in only matters for showing the raw OptiPlex desktop (non-web). Since the whole UI is web-based, the native-browser path covers the real need — and HDMI-in is the only reason the big Linkswell units cost ~$1,640-2,225 instead of ~$960.

Price ladder (AmericanTrucks = authorized "Navos" retailer → real warranty/support, unlike Amazon/eBay grey-market which Linkswell refuses to support directly):

✅ DECISION: Phoenix Automotive by Navos 13", 6GB/128GB, Android 13 — ~$962 from AmericanTrucks. Big vertical screen, newer Android than the Linkswell (A13 vs A11), runs the Flask UI in native Chrome w/ touch, retains factory backup cam + steering-wheel + climate. Saves ~$1,260 vs the XL — money that belongs in the carputer guts (battery, OptiPlex power, MPPT) per the buy-what-you-need-first rule.

• Only step up to the Linkswell XL 15.6" + $130 HDMI adapter (~$2,225) if you specifically want the 15.6" canvas + raw OptiPlex desktop on HDMI (view-only, voice-controlled) + 3 dedicated camera inputs + a serious audio build (pair its optical-out with a Navos DSP amp). That's an audiophile-tier budget, not a functional requirement.

Chip note: Phoenix "S7865" = Unisoc UIS7862S (the enthusiast-favorite car SoC — 2×A75+6×A55, biggest modding/firmware community, best app compat). Linkswell uses Qualcomm QCM6125 (~Snapdragon 665 — comparable, often more stable). For a thin client the OptiPlex drives, either is fine; favor RAM/Android-version over chip splitting-hairs.

⚠️ Gates before buying ANY unit (one is a real risk):

1. CANBUS coexistence — the #1 risk. Every Linkswell/Navos page warns it "may not be compatible with other aftermarket CANBUS devices… tuners, OBD devices." This truck has a tune and the build plans OBD/CAN reading (§8, OptiPlex on the SH-C31G). Confirm with the AT Sales Tech (610-990-4561) that the unit coexists with the tune + a CAN/OBD tap before ordering.
2. AC type — match Auto / Manual 4-speed / Manual 7-speed to the dash; send a photo of the OEM radio + A/C panel.
3. Internet — the unit goes online via the Cudy WiFi (§4.1); its own LTE/SIM is unneeded.
4. Audio-in path — Phoenix has no HDMI/AUX line-in (factory AUX often lost): OptiPlex audio (TTS/voice/media) reaches the radio via Bluetooth (aptX) or USB, not a wire. (The Linkswell route would carry audio over HDMI instead.) Decide this when wiring.

⚠️ Sourcing (corrected) — AmericanTrucks FORCES a $150 Midas install on this Phoenix item (real cost ~$1,112), and it's a special order, 2-3 wk lead; the AT listing's feature blurb is even wrong-copy (shows a Ford Mustang unit — fitment checker still passes, but confirm real specs with the AT Sales Tech). Two buy paths: (a) AT/Navos = better support but forced pro-install (brief Midas on the tune/CAN, or sort the CANbus box after — the head unit talks to the OptiPlex over WiFi, so the carputer integration is mostly decoupled from the dash install); (b) Phoenix Automotive direct (phoenixautomotiveinc.com, code 2026) = self-install + cheaper, but Phoenix's direct support is the spotty one the forums flag. For a hands-on builder who must control the CAN integration, direct + self-install likely fits better.

4.3 Multi-Screen Control (tablet + radio simultaneously)

Each screen is an independent browser client. One always-open kiosk browser per screen; voice navigates it via targeted WebSocket push — no new windows, no touch needed, no radio interaction.

Each screen registers with a name: ?screen=radio / ?screen=tablet
"Hey Truck, 4-camera view on the radio" → only radio switches
Tablet stays on gauges, untouched.
"on the radio" / "on the tablet" / "on the dash" = target selector

You can run gauges on the tablet while voice-switching the radio from reverse cam to a 4-cam grid — each addressed separately.

4.4 Tier Responsibilities & The Always-On Side (rev 3.4 — core design)

Organizing rule: "Does it need to be true while the OptiPlex is asleep?" Yes + beyond pin-level → Pi. Only matters while driving → OptiPlex. A hardware reflex → ESP32. Heavy reasoning / away-delivery → Fireworks / Hetzner.

Graceful degradation (every tier degrades DOWN, never up): the ESP32 keeps its safety reflexes (LVD, manual switches, direct WOL) independent of the Pi — so a dead Pi costs you the smart layer (alerts, status, schedules) but never battery protection or basic relay control. A dead OptiPlex costs voice/cameras/RAG but the Pi+ESP32 still run the truck's 24/7 side.

Why the Pi stays (and isn't redundant): its broker is featherweight, but it's the always-on host for the things that must work while the OptiPlex sleeps — the PWA, alert orchestration, the wake decision, logging. Compute is a non-issue (Mosquitto runs on a Pi Zero); the only real work is the reliability hygiene above. Pi 4 (4GB, ~$60) = FUTURE upgrade — its USB-2 100Mbit NIC + 1GB RAM are the weak points; upgrade when the 3 B+ shows strain under broker+PWA+Wolfbox, not before. (Keep the future Pi 5 + Hailo as a separate camera box — don't fold cameras onto the safety-bus Pi.)

4.5 Phone Control — the PWA on the Pi (rev 3.4)

Your S24 becomes the truck's remote. The Pi hosts a PWA (web app that "installs" to the S24 home screen — feels native, no app store, no maintenance):

• Status — battery %, door/light states, cab temp, last camera snapshot (fed from MQTT; the Pi is the broker).
• Relay toggles — tap "Rock Lights ON" → Pi publishes MQTT → ESP32 fires the relay. Works with the OptiPlex completely OFF — the path is Phone → Pi → ESP32, the 5080 isn't in it. This is the whole point: interact with the 24/7 side directly.
• "Wake the 5080" button — Pi fires WOL; once it boots (~20s) the phone jumps to the OptiPlex's rich UI (live cameras, voice, gauges, RAG).

Access — same page, two paths: on truck WiFi (Cudy) → Pi's local IP, instant, zero cell needed; away → over Tailscale at the Pi's 100.x (toggle lights / wake the truck from across town). Lock it down: PIN/password-gate the control actions; reachable only on truck-WiFi + tailnet, never public. (A simple PIN is enough for a local truck page — no need for full Authelia/SSO here. High-power relay actions still get the §9.2 confirmation gate.)

4.6 Wake vs Alert — two separate triggers (rev 3.4)

The single most important split on the 24/7 side: "wake me" and "alert me" are different events.

• WAKE the OptiPlex = you are approaching to drive → keyring BLE dongle (primary) / phone (backup). Gated so it doesn't fire on every event.
• ALERT to phone = a door/alarm fired → the event itself is the trigger, no proximity — you want it precisely when your phone is far away.

Keyring dongle > phone proximity (decided): a dedicated BLE tag (iBeacon/nRF, coin cell, months) has a fixed identifier + steady RSSI and is literally tied to the act of going to drive. Phone proximity is unreliable — Android randomizes its BLE MAC, battery-optimization kills background BLE, BT may be off. ~$5-10. Dongle primary, phone optional backup.

GPS does NOT sense your approach. The truck's GPS knows where the truck is (stationary when parked) — it can't tell you're walking up. The BLE dongle is what detects you. "Ready before you open the door" comes from dongle range + a shallow sleep state: parked <2hr the OptiPlex is in S3 (wakes 2-5s — see §5.4), so it's up before you reach the handle. GPS's role is the longer-range phone-geofence wake (your phone crosses a radius around the truck's parked spot → sends a wake; needs truck+phone online) plus find-my-truck / geo-stamp / offline clock. Dongle = offline approach-wake; GPS-geofence = the "I have signal" early-wake bonus.

Parked alert flow = wake-OptiPlex-per-event (chosen over an always-on camera, to protect winter solar):

door/alarm DI (ESP32) → Pi wake-coordinator classifies:
   ├─ dongle present  → "owner returning" → normal wake, NO alert
   └─ no dongle + door → "intrusion" → Pi fires TEXT alert via Hetzner immediately,
                          AND WOLs the OptiPlex → it grabs frames → pushes JPG via Hetzner → sleeps

Hetzner = store-and-forward alert relay, NOT a bus middleman (the owner's original design, and correct). The local MQTT bus stays 100% in the truck. But your phone can't receive a push straight from the truck — a server must hold the alert + JPG and retry until your phone ACKs (across cell dead zones). Self-hosting that on your Hetzner box (ntfy or similar) keeps the alerts + intrusion JPGs private. Tiered by cost: ESP32 text alert (~1W, always) → on-demand live-view/JPG via OptiPlex wake. (An always-on camera for automatic JPG-every-event is the ~15W tier — deliberately NOT chosen; see §5.2 winter margin.)

4.7 Displays & Media Routing — 5080 as media hub (rev 3.12)

Model: the OptiPlex 5080 is the media hub — ingest a source once, fan it out to many screens. "Brain in control, even if the brain is a group of sub-components." Companion sheet: **media-routing-5080hub.pdf** (sources → 5080/go2rtc → screens).

Two planes, kept separate. Control (lights, relays, gauges) = MQTT + Flask/PWA — local, instant, needs no internet. Media (video) = go2rtc restream — slight lag, parked use. Don't run control through the media path or vice-versa. (go2rtc is the restreamer already bundled with Frigate, §7.2 — zero new stack.)

Using the S23's UNLIMITED data (the key trick). The phone's hotspot/tether is capped (~5GB) — useless for video. The phone's on-device data is unlimited, so the phone itself must be the streamer, and you move the picture, not the data:

• Dumb display (HDMI / USB-C-in, e.g. the bed monitor): wired DeX (S23 USB-C → HDMI) — phone streams, screen shows it. Or it's a wired desktop head off the 5080.
• Smart device (5080 Linux, Phoenix Android, a tablet): needs a receiver/mirror. On the 5080, that's **scrcpy (open-source; USB-C or WiFi/ADB) — mirrors + controls the phone, on the phone's unlimited data. There is no official Samsung DeX app for Linux — scrcpy IS the Linux equivalent (or a USB HDMI-capture dongle). On the Phoenix**, a Miracast/AutoKit-style mirror app (no HDMI-in, so no wired DeX to it).
• ⚠️ Cast (Chromecast / YouTube "Cast") does NOT use the phone's unlimited — the receiver fetches the stream from the cloud over its own network. Skip it for this.

The fan-out. Ingest the S23 once via scrcpy → the 5080 becomes the distribution point for the phone's unlimited pipe → go2rtc re-publishes it (and the cameras, and local YouTube) as WebRTC to every browser screen. So 5080 + S23 → Phoenix works (restreamed over Cudy WiFi, parked) — the dash shows the phone's YouTube without touching the metered SIM.

Screens.

• Bed USB-C touch monitor — primary WIRED head (dock = charge + USB-C→Ethernet; undock = run it off the S23 via DeX, or use a tablet instead).
• Phoenix dash (Android) — networked browser/WebRTC; parked media + the control PWA. (Driving = no video; Android Auto blocks it anyway.)
• Removable tablet — PWA control + WebRTC media; wired-dock or WiFi/battery.
• S23 — PWA control + the media source.
• 5080 Micro wired video: 1× DP + 1× HDMI (+1 optional flex port) ≈ 2-3 wired heads; everything else is networked (browser), unlimited screens, bandwidth-bound.

Caveats. Latency stacks per hop (scrcpy + re-encode + WebRTC ≈ 0.3-1.5s) → great for watching parked, not twitch-interactive; control stays on the direct PWA (instant). Re-encode = CPU + watts (UHD 630 QuickSync helps) — a parked-movie load, mind deep-winter battery (§5.2). Carriers often throttle video resolution on "unlimited" (480/720p) even when data is uncapped; YouTube over DeX/scrcpy is DRM-fine.

Data split by who's present: phone on-device unlimited = media/bulk when you're at the truck (via scrcpy/DeX); Cudy/Keepgo SIM = always-on automation (Fireworks, Tailscale, alerts) when the phone isn't there. The Cudy can prefer the phone hotspot when in range and fall back to its SIM.

4.8 USB / Peripheral Port Map (rev 3.14)

The 5080 Micro has enough USB — the trick is the right allocation, not more ports. Standard layout: front 1× USB-C + 1× USB-A; rear 4× USB-A (2× 3.2 Gen1 + 2× USB 2.0) + DP + HDMI + RJ45 (+ optional flex port) ≈ 5 USB-A + 1 USB-C + built-in BT 5.2. (Reseller listings may label it "USFF" — the 5080 has no USFF variant; Dell makes only Tower / SFF / Micro. This unit is confirmed Micro by teardown — single SO-DIMM, 64GB max, 1.1L brick. Internal teardown notes: §9 RAM, §7.3 storage, §13 RTC.)

Allocation rule — critical/real-time on the board, tolerant on a hub:

• Direct to motherboard: CAN (SH-C31G) — real-time, never behind a hub · XVF3800 mic (USB audio) · S23 (scrcpy) — video bandwidth.
• **On ONE powered hub:** GPS dongle · KB/mouse dongle · BT dongle · external SSD — low-speed, tolerant.
• Cut the count: KB + mouse = one wireless combo dongle or Bluetooth (built-in BT 5.2 = 0 ports). And in daily use the truck is touch + voice + PWA — KB/mouse is service-time only, not a permanent port.

**Get a powered hub, not a dock.** Powered is the key word (a vehicle browns out bus-powered hubs); an industrial/DIN wide-temp hub fits the build. A dock is the wrong tool here: the 5080 has no Thunderbolt, so docks fall back to driver-heavy DisplayLink for extra video (flaky on Linux), and they funnel everything — including real-time CAN — through one USB-C = a single point of failure. You already have rear DP+HDMI+Ethernet natively. (Reserve the "dock" concept for the removable bed screen, where dock/undock is the actual job — see §4.7.)

BIOS for the parked-power build: DISABLE Deep Sleep Control — Deep Sleep cuts the 5VSB that Wake-on-LAN needs, and WOL from S4 hibernate is the parked-wake path (§5.4/§13); the small extra S4 standby draw is the accepted cost of WOL, and the deep-storage tier cuts power entirely via the ESP32 anyway (so standby draw is moot there). Also DISABLE Smart Power On (USB-wake) — not needed (you wake via WOL + the O3 power-pulse) and it risks spurious USB wakes draining the bank while parked. Enable WOL/PXE. (Earlier draft here mistakenly said enable Deep Sleep — corrected; that would kill WOL.)

Verify on the actual unit: (1) does the front USB-C do DisplayPort-Alt-Mode? Many OptiPlex Micro front-C ports are data/PD only — no video; if so, a USB-C touch monitor's video comes from DP/HDMI with touch on a separate USB-A (2 cables, not one). (2) BT — confirmed: Intel AX201 (Wi-Fi 6 + BT 5.2 + BLE) is installed → use the built-in BT for S24 A2DP audio and BLE proximity; drop the planned USB BT dongle (redundant; keep one only as a Linux-flakiness fallback). The front USB-C header is also a tidy spot for the SH-C31G CAN adapter if you're not using USB-C for a monitor/DeX.