[Bug]: API endpoints returning 502/503 errors and failing to persist settings (v0.20.0)

[LeonGrim2024]

Before submitting

• I searched existing issues for the same problem.
• I removed credentials and private household data from this report.
• This is a bug in an advertised path, not a general support request.

Hauser version or commit

0.20

Installation path

Docker Compose from source

Environment

Ubuntu

Home Assistant version

last

Steps to reproduce

Describe the bug

I specifically opened an account on OpenAI because this feature looked great and I liked it the most — but unfortunately, it doesn't work at all...

After deploying ghcr.io/ralleur/hauser:v0.20.0 via Docker Compose with a valid household.json configuration, the frontend loads correctly, but multiple backend API endpoints consistently respond with 502 Bad Gateway or 503 Service Unavailable. Consequently, actions like saving API keys or utilizing AI modules fail entirely.

Endpoints affected:

/ambient-llm/v1/chat/completions (502 Bad Gateway)

/api/room-images/access/api-key (503 Service Unavailable)

/api/room-images/access (503 Service Unavailable)

Expected behaviour

API requests to /ambient-llm/v1/chat/completions and /api/room-images/* should successfully process, persist configuration to the /data volume, and return 200 OK without gateway crashes.

Actual behaviour

Endpoints consistently return 502 Bad Gateway and 503 Service Unavailable. Saving API keys or updating settings fails. Docker container logs show no incoming request trace during frontend attempts.

Redacted logs, screenshots or recordings

- Version: v0.20.0 (Docker deployment)
- Console errors:
  * /ambient-llm/v1/chat/completions -> 502 Bad Gateway
  * /api/room-images/access -> 503 Service Unavailable
  * /api/room-images/access/api-key -> 503 Service Unavailable

[ralleur]

Thanks for the report, and sorry it cost you an OpenAI account for a feature that then refused to run. Both errors are real, and both are fixed in v0.20.5.

503 on /api/room-images/access — the boundary was never set

Every room-image route sits behind a same-origin boundary, HMI_ROOM_IMAGE_AUTH_MODE. It has no default in code: without it the boundary counts as unconfigured and every room-image request answers 503 AUTH_BOUNDARY_MISSING, saving the API key included. The shipped compose.yaml and the Home Assistant App both set it, so the path we advertise worked while a hand-written Compose file did not. That is our gap, not your configuration.

The image now sets HMI_ROOM_IMAGE_AUTH_MODE=direct itself, so a Compose file of your own gets the picture wizard without extra variables. If you would rather not wait for the update, this fixes it on 0.20.0 too:

environment:
  HMI_ROOM_IMAGE_AUTH_MODE: direct

One thing to watch if you run Hauser behind a reverse proxy under a different hostname: room-image writes are same-origin, and a proxy that rewrites Host breaks that match. In that case list your public origin in HMI_ALLOWED_ORIGINS. A direct connection to the container needs nothing.

502 on /ambient-llm/v1/chat/completions — there is no model to reach

This one is not a crash. The ambient lines on the standby screen can come from a language model, and Hauser looked for an OpenAI-compatible endpoint at HMI_AMBIENT_HOST:HMI_AMBIENT_PORT, by default 127.0.0.1:18088. Hauser ships no model and starts none, so in any household but the author's there is nothing at that address and the proxy answered 502. The screen itself was never broken: the built-in generator had already written the lines.

Hauser now only asks when you name an endpoint. Without one the route answers 204, the client stops asking until the page reloads, and the console stays quiet. Both variables are documented in the configuration reference now.

Settings not persisting

Saving the API key is the POST /api/room-images/access/api-key from your list, so it persists once the boundary exists. If anything else still refuses to save on 0.20.5, tell me the endpoint and I will look again.

---

Generated by Claude Code