The app assumed it lived at the server root: its links were /static/...
and its fetches /api/..., which behind a proxy at /heos resolve to the
wrong place, so the page would load and nothing on it would work.
It now takes the prefix from X-Forwarded-Prefix, and everything it
generates -- stylesheet, icons, the manifest's start_url, every fetch --
follows. Nothing changes when it is served from its own port.
deploy/heos.conf is the Apache side, restricted to the local network by
default, since this controls the speakers and the vhost it hangs off has
a public certificate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The HEOS app is unpleasant to use for the four things that actually get
done in this house, so this is those four things on one screen: volume
for the Home 400 and the Living Room pair, joining either to the AVR,
splitting them off again, and picking the AVR's input.
The bridge's logic moves in mostly intact, split into a HEOS client, an
AVR client and a controller, with two grouping bugs fixed on the way:
* Merging a room into the AVR sent only the pair's leader pid, which
left the second Home 200 behind. Group targets now expand to every
member pid, and unmerging re-forms the pair rather than leaving two
lone speakers. The members are learned while the pair is visible and
remembered in members.json so a restart can still rebuild it.
* Volume for the pair used its gid, which stops existing the moment it
joins the AVR's group. It now falls back to the member players.
Both sockets are kept open rather than reconnecting per command, which
is what made every button press feel slow; the AVR connection doubles as
a listener, so input changes made with the physical remote show up too.
The original query-string endpoints still answer, so anything already
pointed at the bridge keeps working.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
franzzandClaude Opus 5