feat(cec): claimed-KVM Wi-Fi setup + fix the customer not seeing the technician's chat#42
Merged
Merged
Conversation
The KVM & Claiming card's Wi-Fi button was a "coming soon" placeholder.
Wire it to a real panel that reads and sets the appliance's own Wi-Fi
over the SAME mesh "sites" tunnel the Reboot uses — site_map to a
localhost port, then the KVM's web API, which the device authenticates
by mesh roster (no KVM login needed, exactly like the reboot POST to a
CheckToken-protected /api/vm/gpio).
- One flow spans both models: the connect request ({ ssid, password })
is identical on NanoKVM and NanoKVM-Pro; the status read is normalized
across the plain (`ssid`) and Pro (`wifi { … }`) shapes; the Pro-only
scan is a pure enhancement a plain NanoKVM simply 404s (manual SSID
entry always remains).
- Checks the web API's `code` field (responses are HTTP 200 even on
failure), and treats a dropped reply after connect as "sent, may take
a moment" rather than a hard error — Wi-Fi can be the KVM's own uplink.
- Disconnect is gated behind the in-app confirm (it can strand a
Wi-Fi-only KVM).
- Frontend-only: no new node/Tauri commands and no device changes; the
appliance already owns the Wi-Fi system and bypasses its login on the
mesh path. Demo-mode canned data keeps the browser preview explorable.
Verified with `pnpm check` (0 errors, 0 warnings) and `pnpm build`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017uti8uqD9JC5aVfTVSNppw
…'s replies The customer only ever saw a technician's chat lines via the best-effort live `cec://chat` event plus a single history fetch when the panel opens. A dropped emit, a node event-stream reconnect gap, or an event that lands before the panel has bound to the peer left that line lost to the customer forever — it was only appended live, never re-fetched — even though the node keeps the full transcript. The customer's OWN lines always showed (they're appended optimistically), which masked the gap and made it look one-directional. Make the node transcript the source of truth: re-sync the connected technician's history on a slow poll and on window refocus. To keep the re-sync safe to run repeatedly: - collapse a still-pending optimistic line the fetched transcript already carries (same side + text), so the sender's own bubble isn't doubled; - skip the write when nothing changed, so the poll doesn't churn the thread array and re-fire the panel's scroll-to-end effect. Connected-only and idempotent; a no-op in demo. The node relay itself (allmystuff v0.2.43, already bundled) carries tech<->customer chat both ways — this closes the client-side gap where a delivered line was never re-fetched, so no new AllMyStuff cut is needed. Verified with `pnpm check` (0 errors, 0 warnings) and `pnpm build`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017uti8uqD9JC5aVfTVSNppw
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR now carries two CEC customer-app changes.
1. Fix: the customer couldn't see the technician's chat replies
Symptom: the technician sees the customer's messages, but the customer sees none of the technician's.
Root cause (client-side): the customer only ever received a technician's lines via the best-effort live
cec://chatevent, plus a singleloadChatHistorywhen the panel opens. There was no re-sync after that. So any line whose live event was missed — a dropped emit, a node event-stream reconnect gap, or an event that landed before the panel bound to the peer — was lost to the customer forever, even though the node keeps the full transcript. The customer's own lines always showed because they're appended optimistically, which masked the gap and made it look one-directional.Not a version/pin issue:
allmystuff v0.2.43(already bundled by CECSupport 0.1.22) contains the full tech↔customer chat relay and the P2P send fix, so no new AllMyStuff cut is needed.Fix: make the node transcript the source of truth — re-sync the connected technician's history on a slow poll and on window refocus. The re-sync is made safe to run repeatedly:
Connected-only and idempotent; a no-op in demo. Files:
gui/src/store.svelte.ts.2. Feature: set a claimed KVM's Wi-Fi from the customer app
The KVM & Claiming card's Wi‑Fi button was a disabled "Soon" placeholder. This makes it real: once a customer has claimed a KVM, they can read and set the appliance's own Wi‑Fi from the app.
It reuses the exact mechanism the existing Reboot button relies on —
site_mapopens alocalhosttunnel to the KVM's own web UI, and the KVM server authenticates a tunneled request by mesh roster (WithMeshAuth), so its login is bypassed on the mesh path. No device‑side changes and no new node/Tauri commands.connectis identical ({ssid,password}); the status read is normalized across NanoKVM'sssidstring and the Pro'swifi{…}object; the Pro-only network scan is a pure enhancement a plain NanoKVM cleanly 404s (manual SSID entry always remains).codefield (responses are HTTP 200 even on failure); a dropped reply after connect is reported as "sent, may take a moment" rather than a false failure (Wi‑Fi can be the KVM's own uplink). Disconnect is gated behind the in‑app confirm.gui/src/ui/KvmWifiModal.svelte, plusgui/src/ui/KvmClaimCard.svelte,gui/src/store.svelte.ts,gui/src/types.ts.Verification
pnpm check(svelte‑check — 0 errors, 0 warnings) andpnpm buildboth pass — the repo's hard front‑end gates, exactly as CI runs them. The Tauri backend and device repos are untouched.🤖 Generated with Claude Code
https://claude.ai/code/session_017uti8uqD9JC5aVfTVSNppw