@khalido/home 0.1.2 → 0.2.0

package/src/connectors/hue/index.ts

@@ -5,6 +5,8 @@ import { type Finder, lostDetail, relocator } from "../../discover.ts";
 import {
   envName,
   filePath,
+  type DeviceRecord,
+  deviceRecords,
   type Integration,
   type Part,
   type Status,
@@ -14,20 +16,38 @@ import { bunPinnedFetch, type HueClient, hueClient } from "./client.ts";
 import { hueEvents, isRejectedKey } from "./events.ts";
 import type { HueEvent } from "./schemas.ts";
 import {
+  type GroupView,
   groups,
   type HueSnapshot,
+  type LightView,
   lights,
   reduce,
   snapshotFrom,
 } from "./state.ts";
 
+export { HUE_BRIDGE_ROOT_CA } from "./ca.ts";
+export {
+  colorToXy,
+  type Gamut,
+  kelvinToMirek,
+  mirekToKelvin,
+  type Rgb,
+  type XY,
+  xyToHex,
+} from "./color.ts";
 export {
   bunPinnedFetch,
+  CONFIRM_MS,
+  type HueApplied,
+  type HueRequest,
+  type HueWriteOptions,
+  type LightChange,
   type HueClient,
   HueError,
   type HueOptions,
   hueClient,
   pair,
+  pairWhenPressed,
 } from "./client.ts";
 export type { HueEvent, Resource } from "./schemas.ts";
 export {
@@ -50,18 +70,22 @@ export const configSchema = z.looseObject({
   key: envName.describe(
     "env name holding the application key from `home pair`",
   ),
-  ca: filePath.describe("Signify's root CA (PEM), relative to the config file"),
+  ca: filePath
+    .optional()
+    .describe(
+      "a root CA (PEM) to trust instead of Signify's two, which the package carries; relative to the config file",
+    ),
 });
 
 /**
- * Hue settings for a home. Leave out `fetch` in Bun and it pins to `ca` and `bridgeId`; in Node pass a pinned one.
+ * Hue settings for a home. Leave out `fetch` in Bun and it pins to `bridgeId` and `ca` (Signify's roots, `HUE_BRIDGE_ROOT_CA`, when left out); in Node pass a pinned one.
  * `find` (mDNS, matched by `bridgeId`) finds the bridge again after three failed reconnects; `idleMs` is the stream's watchdog.
  */
 export type HueConfig = {
   host: string;
   bridgeId: string;
   key: string;
-  ca: string;
+  ca?: string;
   fetch?: typeof fetch;
   clock?: Clock;
   find?: Finder;
@@ -189,6 +213,7 @@ export function hue(
           if (isRejectedKey(error))
             return update({
               status: "unavailable",
+              reason: "auth",
               detail: "the bridge rejected the key; pair again",
               state: snapshot,
             });
@@ -215,6 +240,68 @@ const view = (s: HueSnapshot) => ({
   })),
 });
 
+/** A light, room or zone in a line: "Kitchen: on · 40%", "Desk: on · 40% · 2700 K", "Strip: on · 80% · #ff8800", "Kitchen: off", or the name alone when the bridge hasn't said. */
+export const hueText = (v: {
+  name?: string;
+  id: string;
+  on?: boolean;
+  brightness?: number;
+  kelvin?: number;
+  hex?: string;
+}) => {
+  if (v.on === undefined) return v.name ?? v.id;
+  const parts = v.on
+    ? [
+        "on",
+        v.brightness === undefined ? "" : `${Math.round(v.brightness)}%`,
+        // A colour light showing a white reports both; the white is what it is showing.
+        v.kelvin !== undefined ? `${v.kelvin} K` : (v.hex ?? ""),
+      ]
+    : ["off"];
+  return `${v.name ?? v.id}: ${parts.filter(Boolean).join(" · ")}`;
+};
+
+/** A Hue light, or a room or zone, as a home device: `detail` is its `LightView` or `GroupView`. */
+export type HueHomeDevice =
+  | DeviceRecord<"hue", "light", "on" | "off", LightView>
+  | DeviceRecord<"hue", "group", "on" | "off", GroupView>;
+
+/** Every light, then every room and zone. A light's `available` is its Zigbee link; a group's `members` are its lights. */
+export function hueHomeDevices(
+  part: Part<HueSnapshot> | undefined,
+): HueHomeDevice[] {
+  const s = part?.state;
+  if (!s) return [];
+  const on = (v: { on?: boolean }) =>
+    v.on === undefined
+      ? {}
+      : { state: v.on ? ("on" as const) : ("off" as const) };
+  return deviceRecords<HueHomeDevice>(part, [
+    ...lights(s).map((l): HueHomeDevice => ({
+      connector: "hue",
+      id: l.id,
+      name: l.name ?? l.id,
+      kind: "light",
+      ...(l.reachable === undefined ? {} : { available: l.reachable }),
+      ...on(l),
+      asOf: s.asOf,
+      text: hueText(l),
+      detail: l,
+    })),
+    ...groups(s).map((g): HueHomeDevice => ({
+      connector: "hue",
+      id: g.id,
+      name: g.name ?? g.id,
+      kind: "group",
+      ...on(g),
+      asOf: s.asOf,
+      text: hueText(g),
+      members: g.lightIds,
+      detail: g,
+    })),
+  ]);
+}
+
 export const manifest: Manifest<HueSnapshot> = {
   name: "hue",
   title: "Philips Hue",
@@ -241,21 +328,16 @@ export const manifest: Manifest<HueSnapshot> = {
     {
       name: "HUE_CA_FILE",
       example: "/path/to/hue-root-ca.pem",
-      what: "until HUE_BRIDGE_ROOT_CA ships in src/connectors/hue/",
+      optional: true,
+      what: "a root CA to trust instead of Signify's two, which the package carries",
     },
   ],
   files: ["ca"],
   /** "3 lights on", then "Kitchen: on · 40%" per room and zone. */
   lines({ state }) {
     if (!state) return [];
-    const { lightsOn, rooms } = view(state);
-    return [
-      `${lightsOn} lights on`,
-      ...rooms.map(
-        (r) =>
-          `${r.name}: ${r.on ? `on${r.brightness === undefined ? "" : ` · ${Math.round(r.brightness)}%`}` : "off"}`,
-      ),
-    ];
+    const { lightsOn } = view(state);
+    return [`${lightsOn} lights on`, ...groups(state).map(hueText)];
   },
   record: ({ state }) => (state ? view(state) : {}),
 };

package/src/connectors/hue/schemas.ts

@@ -6,6 +6,7 @@ import { z } from "zod";
 // all are optional and unknown fields pass through, so a schema change degrades, never throws.
 
 const ref = z.object({ rid: z.string(), rtype: z.string() });
+const xy = z.looseObject({ x: z.number(), y: z.number() });
 
 /** The resource kinds this library reads. */
 export const KINDS = [
@@ -27,6 +28,31 @@ export const Resource = z.looseObject({
   metadata: z.looseObject({ name: z.string().optional() }).optional(),
   on: z.looseObject({ on: z.boolean() }).optional(),
   dimming: z.looseObject({ brightness: z.number() }).optional(),
+  // A light's colour and the triangle of colours it can show; absent on a white light. A shape this doesn't expect
+  // reads as absent, so one odd light never fails the whole read.
+  color: z
+    .looseObject({
+      xy: xy.optional().catch(undefined),
+      gamut: z
+        .looseObject({ red: xy, green: xy, blue: xy })
+        .optional()
+        .catch(undefined),
+    })
+    .optional()
+    .catch(undefined),
+  // mirek is null while the light shows a colour; the schema is this light's own range.
+  color_temperature: z
+    .looseObject({
+      mirek: z.number().nullable().optional(),
+      mirek_schema: z
+        .looseObject({
+          mirek_minimum: z.number().optional(),
+          mirek_maximum: z.number().optional(),
+        })
+        .optional(),
+    })
+    .optional()
+    .catch(undefined),
   children: z.array(ref).optional(),
   services: z.array(ref).optional(),
   group: ref.optional(), // scene: the room or zone it belongs to

package/src/connectors/hue/state.ts

@@ -1,3 +1,4 @@
+import { type Gamut, mirekToKelvin, type XY, xyToHex } from "./color.ts";
 import type { HueEvent, Resource } from "./schemas.ts";
 
 /** Every resource on the bridge by id, from the last full read plus every event since. `asOf` is local time it was last known fresh. */
@@ -56,9 +57,17 @@ export type LightView = {
   on?: boolean;
   brightness?: number;
   reachable?: boolean;
+  /** White temperature in kelvin, while the light shows a white; its range is `kelvinRange` (warmest, coolest). */
+  kelvin?: number;
+  kelvinRange?: [number, number];
+  /** The colour it shows: the bridge's `xy`, and `hex` for a screen (the hue at full brightness). Colour lights only. */
+  xy?: XY;
+  hex?: string;
+  /** The colours it can show. Present on a colour light, so its presence says "takes a colour". */
+  gamut?: Gamut;
 };
 
-/** Every light, with on, brightness and reachability. */
+/** Every light, with on, brightness, reachability, and its white temperature and colour where it has them. */
 export function lights(s: HueSnapshot): LightView[] {
   const zigbee = ofType(s, "zigbee_connectivity");
   return ofType(s, "light").map((l) => {
@@ -69,10 +78,27 @@ export function lights(s: HueSnapshot): LightView[] {
       on: l.on?.on,
       brightness: l.dimming?.brightness,
       reachable: link ? link.status === "connected" : undefined,
+      ...colorOf(l),
     };
   });
 }
 
+/** A light's temperature and colour fields, only those the bridge reported. */
+function colorOf(l: Resource): Partial<LightView> {
+  const out: Partial<LightView> = {};
+  const ct = l.color_temperature;
+  if (typeof ct?.mirek === "number") out.kelvin = mirekToKelvin(ct.mirek);
+  const { mirek_minimum: min, mirek_maximum: max } = ct?.mirek_schema ?? {};
+  if (min !== undefined && max !== undefined)
+    out.kelvinRange = [mirekToKelvin(max), mirekToKelvin(min)];
+  if (l.color?.xy) {
+    out.xy = l.color.xy;
+    out.hex = xyToHex(l.color.xy);
+  }
+  if (l.color?.gamut) out.gamut = l.color.gamut;
+  return out;
+}
+
 /** A room or zone as a row shows it, with its grouped light's state. */
 export type GroupView = {
   id: string;

package/src/connectors/printers/README.md

@@ -1,6 +1,6 @@
 # Printers
 
-AirPrint printers, found by mDNS and read over IPP on the local network. `iot_class`: **local_polling** (one Get-Printer-Attributes per printer every 120 s). Built read-only; **untried on a live printer** (the Brother KO has did not answer mDNS on 2026-10-14, see Live findings).
+AirPrint printers, found by mDNS and read over IPP on the local network. `iot_class`: **local_polling** (one Get-Printer-Attributes per printer every 120 s). Built read-only; first read of a live printer 2026-11-10 (see Live findings).
 
 Try it: `home printers`
 
@@ -34,7 +34,9 @@ Everything, until a real printer answers: the request bytes (the codec is checke
 
 ## Live findings
 
-None yet. 2026-10-14 (Bun 1.4.3): `home discover` (two passes) and `home printers` found no `_ipp._tcp` or `_ipps._tcp` instance on the network, so the Brother was not advertising (off, asleep, or on another network).
+**2026-11-10, from a Pi (Bun 1.4.4, 0.1.2; chota-bot's session).** `home discover` found the Brother by mDNS and `home printers` read it: "Brother HL-L2350DW series: idle · BK 80% · A4 ready". So discovery, the request, the default path, a real `marker-levels` and `media-ready` work on this model. Still unverified from the list above: `printer-uuid` against TXT `UUID`, a sleeping printer waking, `printer-alert`, and the macOS local-network prompt.
+
+2026-10-14 (Bun 1.4.3): `home discover` (two passes) and `home printers` found no `_ipp._tcp` or `_ipps._tcp` instance on the network, so the Brother was not advertising (off, asleep, or on another network).
 
 ## Sources
 

package/src/connectors/printers/index.ts

@@ -11,7 +11,13 @@ import {
   lostDetail,
   rescanDelay,
 } from "../../discover.ts";
-import type { Integration, Part, Status } from "../../home.ts";
+import {
+  type DeviceRecord,
+  deviceRecords,
+  type Integration,
+  type Part,
+  type Status,
+} from "../../home.ts";
 import type { Manifest } from "../../manifest.ts";
 import { poller } from "../../poll.ts";
 import { getPrinterAttributes, printerUrl } from "./client.ts";
@@ -19,6 +25,7 @@ import { attributesOf } from "./codec.ts";
 import {
   type Printer,
   printerKey,
+  type PrinterStatus,
   printerText,
   type PrintersState,
   type Reading,
@@ -383,3 +390,38 @@ export const manifest: Manifest<PrintersState> = {
     ];
   },
 };
+
+/** A printer as a home device: `state` is the printer's own (`idle`, `printing`, `stopped`, `offline`); `detail` its `Printer`. */
+export type PrinterHomeDevice = DeviceRecord<
+  "printers",
+  "printer",
+  PrinterStatus,
+  Printer
+>;
+
+/** Every printer, by name. One that has stopped answering is not `available`, and keeps its last values. */
+export function printersHomeDevices(
+  part: Part<PrintersState> | undefined,
+): PrinterHomeDevice[] {
+  if (!part?.state) return [];
+  return deviceRecords(
+    part,
+    printerList(part.state).map((p): PrinterHomeDevice => ({
+      connector: "printers",
+      id: p.uuid,
+      name: p.name,
+      kind: "printer",
+      ...(p.state === undefined ? {} : { available: p.state !== "offline" }),
+      ...(p.state === undefined ? {} : { state: p.state }),
+      // An offline printer's values are from when it last answered, not from this check.
+      ...(p.state === "offline"
+        ? p.lastSeen === undefined
+          ? {}
+          : { asOf: p.lastSeen }
+        : { asOf: p.asOf }),
+      text: printerText(p),
+      ...(p.room ? { room: p.room } : {}),
+      detail: p,
+    })),
+  );
+}

package/src/connectors/spotify/README.md

@@ -18,7 +18,7 @@ Soloist is Spotify's own headless Spotify Connect client (Linux arm64, armv7, x8
 
 - Each resolves `{ state, confirmed }`: after Soloist accepts (`command_result`), it waits up to 2 s for the event that shows _this caller's_ change (the volume sent, `paused` or `playing`, a new track URI, the context or track played, a position near the seek, the shuffle or repeat set, the track in `upNext`), then gives the state. No such event: `confirmed: false`, the state as it stands. A write merged into a later one confirms only if its own change shows; a write of what is already so confirms at once; a drop ends the wait. `next` also confirms on idle (end of queue) or a restart, `prev` on a restart from 5 s or more in.
 - A volume reported within 1 of the request confirms, since Soloist rounds it (phone steps are sixteenths).
-- **While inactive** (`state.active: false`), Soloist accepts `set_volume` and drops it, three times live. `setVolume` is refused unsent with code `inactive`; `duck` runs `fn` over the music with `music: "untouched"`. `activate()` fixes it, but makes a new audio stream, so the volume can jump to the level last saved (62 to 40, live). `play` while inactive goes active first (a `play` alone didn't take live; going active first is untested). `resume` doesn't: it worked inactive, and `interrupt` relies on that.
+- **While inactive** (`state.active: false`), Soloist accepts `set_volume` and drops it, three times live. `setVolume` is refused unsent with code `inactive`; `duck` and `interrupt` run `fn` over the music with `music: "untouched"`: "playing" while inactive is the account playing on another speaker, which a pause would stop. `activate()` fixes it, but makes a new audio stream, so the volume can jump to the level last saved (62 to 40, live). `play` while inactive goes active first (a `play` alone didn't take live; going active first is untested). `resume` doesn't: it worked inactive, and `interrupt` relies on that.
 - Errors are `ConnectorError` with `code`: `offline`, `waiting`, `inactive`, `refused` (Soloist's `error`), `timeout` (3 s), `invalid` (bad input, nothing sent).
 - One write lane, 100 ms apart (a guess). `volume`, `seek`, `shuffle`, `repeat` merge to the last; `play`, `pause`, `resume` share a slot, so the last wins; each `next`, `prev`, `queue` is its own. Queries go through the lane too, at most 1 s each, since Soloist's `error` names no command.
 - `setRepeat` is two commands in the docs' order (clear the other mode, then set this one), 600 ms apart: back to back, `off` from `track` stayed on `track` live, and 600 ms apart worked. If the second is refused, repeat may be left off.
@@ -28,14 +28,14 @@ Soloist is Spotify's own headless Spotify Connect client (Linux arm64, armv7, x8
 
 **`duck(fn, { to })` and `interrupt(fn)`** turn the music down, or pause it, around `fn`, then put it back. Both resolve `{ value, music, why? }`, `music` one of:
 
-- `untouched`: not playing or buffering, not connected, (duck) the volume unknown or already at `to` or below, or the lowering or pause failed, so `fn` ran over it.
+- `untouched`: not playing or buffering, not connected, not the active device, (duck) the volume unknown or already at `to` or below, or the lowering or pause failed, so `fn` ran over it.
 - `restored`: put back as it was.
 - `kept`: someone changed it meanwhile (resumed, skipped, set the volume), or the pause or lower volume never showed. Theirs stays.
 - `failed`: the restore failed or was never reported; it may be left quiet or paused.
 
 The restore runs even if `fn` throws: the error is `fn`'s, and a failed restore goes to `detail`. `duck` restores the earlier volume even above `maxVolume`. One aside at a time: never call one inside another's `fn` (it waits forever), and put two announcements in one `fn`. With Cast: `speaker.duck(() => cast.announce("Kitchen", clip), { to: 20 })`. Cast's own `announce` restores what a Cast device was playing; these are for Soloist's output.
 
-**Reading it.** `speakerState` takes the Part; `spotifyText` and `positionMs` take its `state`. `speakerState(part)`: `offline`, `connecting`, `waiting`, then Soloist's status (`idle`, `playing`, `paused`, `buffering`, or its own string); signed in with no status yet is `idle`. `spotifyChanges(before, after)`, for `onChange`, gives events in this order: `offline`, `online`, `waiting`, `picked`, `started` (from idle), `resumed` (from paused), `paused`, `stopped`, `track`, `stalled`, `recovered`. Buffering counts as playing. Nothing on the first report, so a restart announces nothing; no volume or queue events. Playback events during an aside carry `own: true`; connection, sign-in and stall events never do. `track` waits for the track's name, which Soloist can send a few seconds after the track (seen live); one that never gets a name never fires. One press on a phone can fire track, resumed, stopped, started and track over 3 s, sometimes with a 0.8 s `waiting`, and the order varies: anything announcing these should wait a few seconds. `state.volume` isn't the level that will play until `active` (it reads `--initial-volume`).
+**Reading it.** `speakerState` takes the Part; `spotifyText` and `positionMs` take its `state`. `speakerState(part)`: `offline`, `connecting`, `waiting`, `elsewhere` (Soloist says playing but isn't the active device: the music is on another Spotify device and this one is silent; `playingElsewhere(state)` is the test), then Soloist's status (`idle`, `playing`, `paused`, `buffering`, or its own string); signed in with no status yet is `idle`. `spotifyChanges(before, after)`, for `onChange`, gives events in this order: `offline`, `online`, `waiting`, `picked`, `started` (from idle), `resumed` (from paused), `paused`, `stopped`, `track`, `stalled`, `recovered`. Buffering counts as playing. Music elsewhere is silence here: leaving is `stopped`, arriving is `started` then `track`, and its tracks, pauses and stops meanwhile fire nothing (a resume there after a pause there fires one `stopped`: paused while inactive reads as Soloist says, so the resume looks like music leaving). Soloist doesn't say where it is; `spotifyElsewhere(snapshot)` from `@khalido/home` names the Cast devices playing that track in Spotify, and `homeDevices` puts them in the speaker's line (matched by name, built snapshots only, untried live), and is empty for a phone. Nothing on the first report, so a restart announces nothing; no volume or queue events. Playback events during an aside carry `own: true`; connection, sign-in and stall events never do. `track` waits for the track's name, which Soloist can send a few seconds after the track (seen live); one that never gets a name never fires. One press on a phone can fire track, resumed, stopped, started and track over 3 s, sometimes with a 0.8 s `waiting`, and the order varies: anything announcing these should wait a few seconds. `state.volume` isn't the level that will play until `active` (it reads `--initial-volume`).
 
 **Stalls** ([#5](https://github.com/spotify/soloist/issues/5): playback stops mid-track, often the first after idle, while Soloist still says `playing`). While playing, one `get_state` every 20 s (`stallCheckMs`, code only; 0 turns it off).
 
@@ -68,6 +68,24 @@ Writes through this connector, and what a live read hasn't shown. In particular:
 
 ## Live findings
 
+**2026-11-11, Raspberry Pi 5, Bun 1.4.4, on 0.1.3** (chota-bot's session; `maxVolume: 40` watching, writes from the CLI in another process). Two gaps in the cap, not fixed:
+
+- From inactive and paused at 60, `play`: lowered to 40 within 2 ms of going active, `playing` at 40, then 60 again 90 ms after `playing`, and it played at 60. The cap takes its first confirmed lowering as done, so nothing lowered it again, and `anomaly` still said "lowered it". Soloist puts its own level back after `playing`.
+- The connector started while the speaker was already active and paused at 60: `play` resumed at 60, nothing lowered it, no anomaly. This is the documented "not on resuming from pause while active".
+- A volume set by hand (35) held through pause and play, so the put-back belongs to activation, not to pause.
+
+**2026-11-10, Raspberry Pi 5, Bun 1.4.4, on 0.1.2, through this connector** (chota-bot's session, KO listening).
+
+- Confirmed with `maxVolume: 60`, the speaker active and playing: `activate`, `setVolume(50)`, `setVolume(90)` (came back 60), `seek`, `setShuffle`, `setRepeat("context")` and `("off")` (about 2.1 s each), `queue` (first in `upNext`), `play` of a playlist URI. `duck(fn, { to: 20 })` around a Cast announce: 20 inside, `music: "restored"`, 60 after, 5.2 s in all.
+- **The level can jump above the cap on a pause, not only on a start.** One-shot CLI, cap 60: `volume 45` read 45, `play` 45, then `pause` read 62 and the next `play` 62 (62 was the level before the test). Nothing lowered it: a pause is not a start signal, and each CLI command is a new process.
+- **That jump did not repeat, and it is not WirePlumber.** A second pass the same day, the speaker already active: 60, `volume 45`, `pause`, `play`, `volume 60`. Soloist's number and the stream's live level (`wpctl get-volume`) matched at every step (0.60, 0.45, 0.45, 0.45, 0.60), WirePlumber 0.5.8 never wrote a saved entry for the stream in `stream-properties`, and the stream kept its id across pause and play. The run that jumped had just been made active with `activate`, minutes after the account was casting from a phone, which points at the account side. One case each way.
+- **`active: false` with `status: "playing"`:** the account playing on another speaker. `speakerState` said `playing`, `spotifyText` printed it as this speaker's, and `spotifyChanges` fired `resumed`, with the box silent. Since 2026-11-11 all three read it as `elsewhere`, and the stall watch skips it; not yet seen live.
+- Through chota-bot's wrapper, later the same day: `play` of a playlist confirmed in 241 ms, `next` in 134 ms, `pause` in 17 ms; `duck` to 15 and `interrupt`, 2.5 s each, both `restored`. `play()` with the music paused on a Cast speaker: confirmed in 1.3 s, playing on the box at the same position.
+- **`interrupt` paused music that was on another speaker** (found in chota's switch): it checked `playing` and not `active`. Fixed after 0.1.2.
+- `positionMs` around a duck and an interrupt read 2 s, 2 s, 3 s, 5 s, then 4 s after a pause: it can step back a second.
+- A consumer's test with a fake socket: a write goes out behind the connector's own queries (`get_state`, `get_queue`), up to about 1 s on a fresh socket, so "the command was sent" can't be checked straight after the call.
+- Not run: the first-play cap from idle (the box never went active), stall events.
+
 **2026-11-09, Raspberry Pi 5, Bun 1.4.4, Soloist 1.3.10.51, PipeWire and WirePlumber 0.5.8, on 0.1.1** (chota-bot's session; writes with KO's OK).
 
 - Confirmed: pause, resume, next, prev, seek, shuffle, repeat to context and track, queue, all under 900 ms. `interrupt` restored the music.

package/src/connectors/spotify/changes.ts

@@ -14,11 +14,24 @@ export function stallText(s: Stall | undefined): string | undefined {
   return s.tried ? `${what}; tried ${s.tried}` : what;
 }
 
-/** The speaker in one word, to switch on. `offline`: not reached (or no part); `waiting`: running, nobody has picked it. A status Soloist sends beyond its four passes through. */
+const PLAYING = new Set(["playing", "buffering"]);
+
+/**
+ * Soloist says playing while it is not the account's active device: the music is on another Spotify device (a phone,
+ * another speaker) and this one is silent (live, 2026-11-10). Soloist doesn't say which. Unknown `active` is not elsewhere.
+ */
+export const playingElsewhere = (s: SpotifyState | undefined): boolean =>
+  s?.active === false && PLAYING.has(s.status ?? "");
+
+/**
+ * The speaker in one word, to switch on. `offline`: not reached (or no part); `waiting`: running, nobody has picked it;
+ * `elsewhere`: the account's music is playing on another Spotify device, not this one. A status Soloist sends beyond its four passes through.
+ */
 export type SpeakerState =
   | "offline"
   | "connecting"
   | "waiting"
+  | "elsewhere"
   | "idle"
   | "playing"
   | "paused"
@@ -32,6 +45,7 @@ export function speakerState(
     return "offline";
   if (part.status === "connecting") return "connecting";
   if (part.state?.loggedIn === false) return "waiting";
+  if (playingElsewhere(part.state)) return "elsewhere";
   return part.state?.status ?? "idle"; // signed in, nothing reported yet: nothing is playing
 }
 
@@ -57,12 +71,12 @@ export type SpotifyEvent = { own?: true } & (
   | { type: "track"; track: Track }
 );
 
-const PLAYING = new Set(["playing", "buffering"]);
-
 /**
  * The events between two reports, for `onChange`'s `before` and `after`: `offline` and `online`; `waiting` (signed out) and
  * `picked` (someone picked the speaker); `started` (from idle), `resumed` (from paused), `paused`, `stopped` (to idle), then
- * `track` for a new track, once it has a name, then `stalled` and `recovered` (Soloist issue #5). Buffering counts as playing. No `before`, or one
+ * `track` for a new track, once it has a name, then `stalled` and `recovered` (Soloist issue #5). Buffering counts as playing.
+ * Music on another Spotify device (`playingElsewhere`) is not playing here: it moving away is `stopped`, it arriving is `started`
+ * then `track`, and nothing fires for its tracks meanwhile. No `before`, or one
  * with no state (createHome's placeholder before the first report, as at a restart): nothing, since nothing was seen to change. No volume or queue events: read the state.
  */
 export function spotifyChanges(
@@ -87,8 +101,11 @@ export function spotifyChanges(
     events.push({ type: "waiting" });
   if (b?.loggedIn === false && a?.loggedIn === true)
     events.push({ type: "picked" });
-  const from = b?.status;
-  const to = a?.status;
+  // What this speaker itself is doing: music on another device is silence here.
+  const here = (s?: SpotifyState) => (playingElsewhere(s) ? "idle" : s?.status);
+  const from = here(b);
+  // Still inactive after playing elsewhere: a pause or stop there is the other device's, not this one's.
+  const to = playingElsewhere(b) && a?.active === false ? "idle" : here(a);
   const playingNow = to !== undefined && PLAYING.has(to);
   const playingThen = from !== undefined && PLAYING.has(from);
   if (playingNow && !playingThen)
@@ -98,7 +115,13 @@ export function spotifyChanges(
     add({ type: "stopped" });
   // Soloist's first report of a new track can have no name yet (seen live): the event waits for it.
   const named = (p?: SpotifyState) => !!p?.track?.name;
-  if (a?.track && named(a) && (a.track.uri !== b?.track?.uri || !named(b)))
+  const heard = playingElsewhere(b) && playingNow ? undefined : b; // a track that was on another device is new here once it plays here
+  if (
+    a?.track &&
+    named(a) &&
+    !playingElsewhere(a) &&
+    (a.track.uri !== heard?.track?.uri || !named(heard))
+  )
     add({ type: "track", track: a.track });
   if (a?.stalled && !b?.stalled)
     events.push({ type: "stalled", stall: a.stalled });
@@ -112,14 +135,20 @@ export function spotifyChanges(
   return events;
 }
 
-/** The speaker in a few words: `Kitchen speaker: playing "Song" by Band · 35%`, or `…: waiting for someone to pick it`. */
-export function spotifyText(s: SpotifyState): string {
+/**
+ * The speaker in a few words: `Kitchen speaker: playing "Song" by Band · 35%`, `…: waiting for someone to pick it`, or,
+ * for music on another Spotify device, `…: silent · "Song" by Band is playing on another Spotify device` (no volume: it isn't this speaker's playing level).
+ * `on` names where, when the caller knows (`spotifyElsewhere`): `… is playing on Front room speaker`.
+ */
+export function spotifyText(s: SpotifyState, on: string[] = []): string {
   const who = s.deviceName ?? "Soloist";
   if (s.loggedIn === false) return `${who}: waiting for someone to pick it`;
   const t = s.track;
   const what = t
     ? `${t.name ? ` "${t.name}"` : ` ${t.uri}`}${t.artists.length ? ` by ${t.artists.join(", ")}` : ""}`
     : "";
+  if (playingElsewhere(s))
+    return `${who}: silent ·${what || " music"} is playing on ${on.length ? on.join(", ") : "another Spotify device"}`;
   const parts = [
     `${s.status ?? "status unknown"}${what}`,
     s.volume === undefined ? "" : `${s.volume}%`,

package/src/connectors/spotify/index.ts

@@ -1,10 +1,21 @@
 import { z } from "zod";
 import { asOf, type Clock, realClock } from "../../clock.ts";
 import { ConnectorError, errorText } from "../../connector.ts";
-import type { Integration, Part, Status } from "../../home.ts";
+import {
+  type DeviceRecord,
+  deviceRecords,
+  type Integration,
+  type Part,
+  type Status,
+} from "../../home.ts";
 import { writeLane } from "../../lane.ts";
 import type { Manifest } from "../../manifest.ts";
-import { spotifyText, stallText } from "./changes.ts";
+import {
+  type SpeakerState,
+  speakerState,
+  spotifyText,
+  stallText,
+} from "./changes.ts";
 import {
   commandFrame,
   fold,
@@ -32,6 +43,7 @@ export {
 } from "./client.ts";
 export {
   type SpeakerState,
+  playingElsewhere,
   speakerState,
   type SpotifyEvent,
   spotifyChanges,
@@ -411,6 +423,7 @@ export function spotify(
       (error) => {
         capping = false;
         if (error instanceof ConnectorError && error.code === "offline") return; // the status says it
+        if (capUntil !== window) return applyCap(); // a new start while it went: this failure doesn't speak for that one
         capped = true; // refused or unanswered: not again this window
         note = `lowering the volume to ${cap} failed: ${errorText(error)}`;
         publish();
@@ -733,6 +746,9 @@ export function spotify(
         async () => {
           const no = notPlaying();
           if (no) return no;
+          // "playing" while inactive is the account playing on another speaker (live, 2026-11-10): a pause would stop that one.
+          if (inactive())
+            return "it is not the active device, so the music playing is on another speaker";
           track = state.track?.uri;
           try {
             shown = (await actions.pause()).confirmed; // a pause that never shows still runs fn: what interrupts matters more
@@ -821,6 +837,7 @@ export function spotify(
       !st ||
       state.aside === "repair" ||
       (state.track?.uri === st.track &&
+        state.active !== false && // moved to another device: no longer this speaker's stall
         (state.status === "playing" || state.status === "buffering"))
     )
       return;
@@ -855,7 +872,12 @@ export function spotify(
     a.track === b.track &&
     b.atMs - a.atMs >= gap &&
     Math.abs(b.ms - a.ms) < 1000;
-  const playing = () => isOpen() && state.status === "playing" && !state.aside;
+  // Not while inactive: "playing" then is another device's music, and a repair's seek or pause would land on it.
+  const playing = () =>
+    isOpen() &&
+    state.status === "playing" &&
+    state.active !== false &&
+    !state.aside;
 
   /** One look while playing: a fresh position, then frozen, overrun, recovered or fine (Soloist issue #5). */
   const checkStall = async () => {
@@ -901,6 +923,7 @@ export function spotify(
     const ours = () =>
       isOpen() &&
       state.status === "playing" &&
+      state.active !== false &&
       state.track?.uri === track &&
       state.stalled?.track === track &&
       (!state.aside || state.aside === "repair");
@@ -999,3 +1022,32 @@ export const manifest: Manifest<SpotifyState> = {
       ? [spotifyText(state)]
       : [],
 };
+
+/** The Soloist speaker as a home device: `state` is `speakerState`'s word; `detail` its `SpotifyState`. */
+export type SpotifyHomeDevice = DeviceRecord<
+  "spotify",
+  "speaker",
+  SpeakerState,
+  SpotifyState
+>;
+
+/** The one speaker, once Soloist has said something. Its name is Soloist's `--device-name`, the one phones show. */
+export function spotifyHomeDevices(
+  part: Part<SpotifyState> | undefined,
+): SpotifyHomeDevice[] {
+  const s = part?.state;
+  if (!s || (s.loggedIn === undefined && s.status === undefined)) return [];
+  return deviceRecords<SpotifyHomeDevice>(part, [
+    {
+      connector: "spotify",
+      id: "spotify",
+      name: s.deviceName ?? "Soloist",
+      kind: "speaker",
+      available: true,
+      state: speakerState(part),
+      asOf: s.asOf,
+      text: spotifyText(s),
+      detail: s,
+    },
+  ]);
+}

package/src/connectors/up/index.ts

@@ -291,6 +291,7 @@ export function up(config: UpConfig): Integration<UpSnapshot, "up"> & {
           if (error instanceof UpError && error.status === 401)
             return update({
               status: "unavailable",
+              reason: "auth",
               detail: "Up rejected the token",
               state: last,
             });

package/src/connectors/weather/README.md

@@ -62,7 +62,7 @@ Plain `fetch` cannot read `ftp://` (Bun 1.4.2: "protocol must be http:, https: o
 
 **Open-Meteo** (`open-meteo.ts`, [docs](https://open-meteo.com/en/docs)). One keyless JSON call per poll: `current` is 15-minutely model data (`interval: 900`), so it is read every poll, and the daily and hourly parts, from models that update hourly at best (6-hourly for IFS), are added to one call an hour. That call reads 48 hours from today's local midnight (`forecast_days=2`) for `hourly`; `sky.hours` is the 6 from the hour it was read. Open-Meteo gives local times and one `utc_offset_seconds`, and applies that offset to every time, across a daylight-saving change too (it returned 02:00 on the night Sydney skipped it; live, 2026-10-16), so `wall − offset` is right for all of them. `dayBlocks` labels each UTC hour in the real zone. 96 calls a day at the default, against 10,000 free. No `models` parameter: [Open-Meteo's BOM page](https://open-meteo.com/en/docs/bom-api) says BOM's open-data delivery is still suspended, and its `bom_access_global` answers only nulls. Radiation is the mean over the preceding interval. `precipitation` is the last 15 minutes, so `now.rainMm` stays empty rather than pretending to be since 9am. 1.3 s a call from Sydney, nearly all of it the TLS handshake with a server in Germany. Plain `fetch` of the JSON API, not the `openmeteo` SDK: the SDK forces FlatBuffers, reads variables by position, calls the global `fetch` (no injection for tests) and adds about 700 KB.
 
-**Google Weather** (`google.ts`, [docs](https://developers.google.com/maps/documentation/weather)). Built from the docs' example responses (`test/fixtures/weather/google-*.json`, the complete objects only; the docs elide the rest) and checked live against Sydney on 2026-10-13: `now`, `forecast` and `sky` in 1.19 s. `google({ key })` reads `forecast/minutes:lookup` every 15 minutes (its floor), `currentConditions:lookup` every 30 and `forecast/days:lookup?days=2` and `forecast/hours:lookup?hours=6` hourly, since Google documents nothing that changes faster. That is 192 calls a day, about 5,800–5,950 a month. Google bills each call as one Weather Usage event: 10,000 free a month, then $0.15 per 1,000 ([pricing](https://developers.google.com/maps/billing-and-pricing/pricing)). Any other use of the same key shares that quota. Whether the minute forecast bills as the same event is unverified: its docs page shows no price. Every slice is `modelled: true`: the docs never say it is observed. A day's rain chance is the higher of its day and night halves, its amount their sum; `currentConditionsHistory.qpf` is a rolling 24 hours, so it is not used as rain since 9am. A 400, 401 or 403 stops the source (`stop`), with no retry loop. The key goes in the query string and never into a message.
+**Google Weather** (`google.ts`, [docs](https://developers.google.com/maps/documentation/weather)). Built from the docs' example responses (`test/fixtures/weather/google-*.json`, the complete objects only; the docs elide the rest) and checked live against Sydney on 2026-10-13: `now`, `forecast` and `sky` in 1.19 s. `google({ key })` reads `forecast/minutes:lookup` every 15 minutes (its floor), `currentConditions:lookup` every 30 and `forecast/days:lookup?days=2` and `forecast/hours:lookup?hours=6` hourly, since Google documents nothing that changes faster. That is 192 calls a day, about 5,800–5,950 a month. Google bills each call as one Weather Usage event: 10,000 free a month, then $0.15 per 1,000 ([pricing](https://developers.google.com/maps/billing-and-pricing/pricing)). Any other use of the same key shares that quota. The key goes in the `X-Goog-Api-Key` header: all four lookups answered 200 that way, live against a public Sydney point on 2026-11-10 (Bun 1.4.4). A bad key and a bad latitude both come back HTTP 400 `INVALID_ARGUMENT`; only the key's error body carries `API_KEY_INVALID`, which is how the source tells `auth` from `config`, and no key at all is 403. Other key failures (expired, the API not enabled) are assumed to be 401, 403 or an `API_KEY_…` reason: unverified. Whether the minute forecast bills as the same event is unverified: its docs page shows no price. Every slice is `modelled: true`: the docs never say it is observed. A day's rain chance is the higher of its day and night halves, its amount their sum; `currentConditionsHistory.qpf` is a rolling 24 hours, so it is not used as rain since 9am. A rejected key or a refused request stops the source (`stop`, with `stopReason`), with no retry loop.
 
 **Google minute forecast** (`toRain` in `google.ts`, [docs](https://developers.google.com/maps/documentation/weather/minute-forecast)). `GET /v1/forecast/minutes:lookup` for a point returns `overallPredictionTimeframe` and 24 `segments` (6 hours) of 15 minutes, each with `type` (`NONE`, `RAIN`, `SNOW`, `HAIL`), `probability` 0–100, `qpf` in mm and `intensity`. Probed for Sydney CBD on 2026-10-15 (curl): HTTP 200 in 1.0 s, every segment dry; the first segment began 12 minutes before the forecast's start. Google calls it Experimental, so its failure is a `problem` on `rain` and never stops the other slices. The docs do not list its coverage by country, say nothing of how it is made, and allow keeping minute values for one hour at most: `rain` owns 15 minutes of age on top of one poll, so a stale slice is dropped, not served (with a `pollMinutes` above 45 the slice outlives that hour: keep it at 15), and the test fixture is invented values in the real shape. We keep the segments that start within 2 hours (`RAIN_HORIZON_MINUTES`). **`rainSoon(rain, at, windowMin = 120)` is the owner**: when the first wet stretch starts and ends, its chance, amount and weight, and `coveredMin`, how much of the window the forecast covers. A segment with no `type` is unknown, not dry. Next: if the minute forecast fails, fall back to the hourly rain chance (`forecast/hours:lookup` already carries `precipitation`; not read yet).