Logs & diagnostics

The hub writes structured logs as it runs — one line per meaningful event, built to answer four questions fast: what triggered this, what target did Rhythm pick, did it dispatch or skip, and where did the time go?

Reading a log line

Every line carries a category (the target), a level, and a handful of fields — the room or node it acted on, how long it took, and a reason when something didn't succeed. Requests also carry a request_id so you can follow one action from the API call all the way to the bulb.

cmd  info  event=dispatch room_id=kitchen latency_ms=42 hub_type=hue
evt  info  event=button room_id=office action=step_up command_id=...
conn warn  event=reconnect hub_type=hue reason=stream_closed

What the categories mean

• sys — startup, shutdown, periodic summaries
• http — API requests and their timing
• evt — incoming buttons, motion, and hub events
• cmd — actions on rooms and the commands sent to your lights
• conn — connection health and reconnects to a hub
• room_sync — discovery and room/device sync
• pair — pairing and unpairing
• triage — the device-review workflow

Levels run error → warn → info → debug → trace. A healthy hub is quiet at info: state changes and one summary per cycle, not a line per room.

Turning up the detail

If you run the open-source server yourself, two environment variables control the logs:

RUST_LOG=debug           # how much to log (per-target filters allowed)
RHYTHM_LOG_FORMAT=json   # full | compact | json output

RUST_LOG=debug is the usual setting when you're chasing a problem; json format is the friendliest to paste into a tool or share with support.

What is never logged