HydraIssues

The venue audio layer (#540) is delivered: hydraroar scale, hydraneck v0.13.0 classification + probe merge, hydravenues v0.6.0 audio assets. Three gaps remain:

1. Mesh routing: the hydraroar scale (pi-node-001) cannot reach venue subnets that ARE routed into the hydraguard mesh (10.0.5.1 sint-niklaas times out). Verify the pi's route into venue subnets (hydraguard allowed IPs / Brussels LAN routing) so the scale can probe routed venues. Until then room/model enrichment only works for venues with a reachable path.
2. cloud-seven LAN is unrouted (Citymesh MikroTik, no WG peer). Options: Citymesh route, a lightweight controller on that LAN, or moving the Sonos gear to the experiencenet VLAN. Fallback today: hydraroar CLI over cluster exec on cosmic-pretzel-98 (proven).
3. The 192.168.2.x Sonos household (3 players) at cloud-seven is still unmapped: no exec node reaches that VLAN and turbo-pancake-76 (192.168.3.15) is agent-down.

When 1 lands, hydraneck scans of routed venues fill room/model/household automatically (backoff retries hourly).

UPDATE 2026-08-26: the cloud-seven VLAN option is prepared as #554 (vendor-ready Citymesh request: move the three 192.168.2.x players onto the 11.0.6.x segment). #554 completes the audio map and enables body-side control; the mesh-routing item (point 1) stays open regardless.

UPDATE 2026-08-27: gap 3 is RESOLVED and out of scope: the 192.168.2.x household is the private residence Sonos on the FDG WiFi (annex, kitchen, living room), confirmed by the venue; it must stay as is and is not venue audio. #554 withdrawn accordingly. Remaining scope of this issue: gap 1 (mesh routing from the scale into routed venue subnets) and gap 2 narrowed to reaching the TWO venue Ports on 11.0.6.x from the scale (Citymesh WG route or a lightweight LAN controller); the CLI fallback on cosmic-pretzel-98 covers them meanwhile.

DIRECTION 2026-09-10: Turbo as the venue proxy

Owner decision: the preferred resolution for cloud-seven reach is hydrabiamp's Turbo worker as the in-venue proxy (the "lightweight controller on the LAN" option). Turbo maintains an outbound HTTPS long-poll to its central service, so no inbound port, no WireGuard route, no Citymesh dependency.

Shape: one Cloud 7 worker serving two upstreams: (a) hydrabiamp's Tesira TTP channel (its native job), (b) a scoped HTTP relay for hydraroar: probe/status/control requests addressed to venue-LAN audio devices (port 1400), submitted through the hydrabiamp command channel and executed by Turbo locally. hydraroar's scale calls the relay when a venue is marked unrouted, instead of timing out.

Work split: relay job type in hydrabiamp/Turbo (tracked with #681), a relay client in hydraroar behind venue config. The Citymesh WG-route ask stays open only as the fallback if Turbo does not land; the mesh-routing check for already-routed venues (sint-niklaas) remains item 1 regardless.