HydraIssues

Why

Venues have audio systems that no Hydra part models today. The neck maps the network. Heads and bodies carry their own audio. But venue speakers, like the Sonos install at Cloud Seven, are invisible to operators. We must make the audio layer of a venue visible, the same way the neck made the network visible.

Architecture (revised 2026-08-25: scale-first)

All venue audio behavior lives in one repo: hydraroar (github.com/cederikdotcom/hydraroar). hydranode stays a pure role assigner and gets no audio logic. Nothing installs on bodies.

• The hydraroar scale (hydraroar serve on a hydraskin node) is the normal path: it probes venue audio devices over routed unicast through the WireGuard mesh. Targets come from hydraneck client lists, so no multicast is needed.
• The CLI (hydraroar scan) is the fallback for venues whose LAN is not routed into the mesh: a one-off run on the venue's lan-exec node over cluster exec. No role, no permanent install. A venue leaves fallback when its LAN routes into the mesh, a lightweight controller lands on that LAN, or the audio gear moves to a routed VLAN.
• hydravenues links speakers as audio assets; future playback control = new hydraroar commands. (hydravoice stays the browser mic relay.)

What we mapped (2026-08-20)

Cloud Seven has 5 Sonos ZonePlayers in 2 households (full table and method: hydraroar/docs/runbooks/venue-audio.md). Household A on 11.0.6.x: Sonos Port "Bar" (11.0.6.30) and Sonos Port "Yoga" (11.0.6.31), both line-level Ports, PA amps likely behind them. Household B: 3 players on 192.168.2.x, a VLAN no exec node reaches.

Plan and status

Phase 0: hydraroar repo — DONE 2026-08-21

v0.1.0: scan (SSDP + describe + households), JSON contract, tests on captured payloads, runbook + testbook, tag CI to GitHub releases + releases.experiencenet.com.

Phase 2: serve mode and scale deployment — DONE 2026-08-25

v0.2.0 shipped and deployed:

• hydraroar serve: GET /api/v1/health (open, router probes), POST /api/v1/probe (bearer token via HYDRAROAR_TOKEN), same JSON contract as the CLI; scan logic shared in internal/scan.
• OCI image scaleregistry.experiencenet.com/hydraroar:v0.2.0 (amd64+arm64) built by CI.
• Scale live on pi-node-001 (exposed at 10.10.100.17:30080), labels user.hydra.domain=hydraroar.experiencenet.com + health_path; DNS A record to the edge; dynamic route + TLS came up automatically. https://hydraroar.experiencenet.com/api/v1/health → ok v0.2.0.

Smoke test (testbook scan-smoke.md) — all pass criteria met:

1. Public health: ok, v0.2.0.
2. Authed probe over the public domain: correct contract.
3. Probe without token: 401.
4. Routed-venue probe: 10.0.5.1 (sint-niklaas) times out from the scale — mesh routing from pi-node-001 into venue subnets is NOT yet verified; needs hydraguard routing work before the scale can probe routed venues (new finding, see gaps).
5. Cloud-seven fallback on cosmic-pretzel-98: downloaded the released hydraroar.exe (WDAC did not object), scan --no-discover --targets 11.0.6.30,11.0.6.31 returned Bar + Yoga (Sonos Port S23, gen 2) in one household, exit 0.

Phase 1: classify in hydraneck — OPEN

1. class + vendor on scanned clients (MAC OUI table + hostname patterns). Classes: audio, intercom, phone, av, network, security, building, other.
2. Venue detail: group unmanaged clients by class, Audio section with room/model/IP/online.
3. Venue list: per-class counts.
4. hydraneck calls the hydraroar probe API with its audio-class IPs and merges rooms + households into the venue picture.

Phase 3: make it clear in hydravenues — OPEN

5. Asset type audio with neck_client_mac linking (same pattern as neck_router_id). Live online dot, model, room on the venue page.
6. Audio tiers per venue live in hydraroar/docs/runbooks/venue-audio.md: none / venue-owned visible / integrated. cloud-seven = venue-owned visible.

Phase 4: control — separate issue, later

7. Playback via new hydraroar commands (Sonos S2 local UPnP AVTransport).

Gaps

• Mesh probing into venue subnets is unverified: from pi-node-001, 10.0.5.1 (sint-niklaas, a routed venue) times out. Either the pi's traffic does not route into venue subnets or the venue router filters it. Needs a hydraguard/routing check before the scale can serve routed venues.
• cloud-seven is unrouted (Citymesh MikroTik, no WG peer for us): the scale cannot reach 11.0.6.x (confirmed by probe). Options: Citymesh WG peer/route, a lightweight controller on that LAN, or moving the Sonos gear to the experiencenet VLAN. Until then: CLI fallback on cosmic-pretzel-98 (proven working).
• 192.168.2.x household (3 players) still unmapped; turbo-pancake-76 (192.168.3.15) is agent-down.

DELIVERED 2026-08-25 (all phases except control)

• Phase 1 SHIPPED in hydraneck v0.13.0 (deployed on 46.225.8.28): pkg/classify (hostname patterns + MAC OUIs), class/vendor on unmanaged clients, class_counts on the venues API, Audio stat on the dashboard, Audio Devices section on the venue page, roar probe merge with hourly backoff for unreachable venues, and a scanner mutex fixing a pre-existing map race. Live: cloud-seven class_counts = audio 5, intercom 6, phone 1, network 11, building 9, security 4, other 37; all 5 Sonos classified audio/Sonos.
• Phase 3 SHIPPED in hydravenues v0.6.0 (scale rebuilt on pi-node-003): neck_client_mac on assets with live status from the neck client list (safe on neck outage, survives edit-mode saves), class/room/model hints on unmanaged devices. Cloud-seven layout now has audio assets "Sonos Port Bar" (Cloud Bar) and "Sonos Port Yoga" (Yoga Room) linked by MAC.
• Verified end to end: neck server calls the roar probe with its config token (200, correct contract); venue layout round-trips the new field.
• Remaining reach gaps split to #550 (mesh routing to venue subnets, cloud-seven LAN options, 192.168.2.x household). Phase 4 control stays future work on hydraroar.