Providers¶

Devices are added through providers (Settings → Add Provider). Each provider discovers its devices automatically. IP-addressable providers offer a Scan network button that finds devices on the LAN and fills in the address; cloud providers take an account token instead. A single provider can serve more than one device domain — Home Assistant alone surfaces lights, media, power, remotes, and sensors.

The table below is the full set of supported devices and how each connects.

At a glance¶

Provider	Category	Devices	Transport	Live updates	Credentials
Philips Hue	Light	Lights + motion accessories (motion/light/temperature sensors)	LAN (CLIP v2)	SSE push	Bridge IP + link-button app key
Govee	Light	Lights	Cloud API + LAN (UDP)	Poll (≈2 min)	API key and/or LAN interface
LIFX	Light	Lights	Cloud API + LAN (UDP)	Poll (≈2 min)	Account token and/or LAN interface
Nanoleaf	Light	Panels (Shapes, Canvas, Light Panels)	LAN (Open API, HTTP)	Poll (≈2 min)	Controller IP + power-button token
TP-Link Kasa	Power	Smart plugs / switches (pre-KLAP firmware)	LAN (port 9999)	Poll (≈2 min)	Plug IP
Onkyo / Integra	Media	Receivers + zones	LAN (eISCP)	Push	Receiver IP
Sonos	Media	Speakers	LAN (UPnP)	Push (events + poll)	Any player's IP
Smart TV	Media + Remote	TVs (Sony Bravia)	LAN (vendor HTTP API)	Poll	Auto-discovered IP + PIN pairing
Home Assistant	Integration	Lights · media · power · remotes · sensors · everything else (generic)	REST + WebSocket	WebSocket push	Base URL + long-lived token
Plex	Feed	None — a content feed ("recently added" library items for Boards)	LAN (HTTP API)	Poll (widget, ≈1 min)	Server URL + X-Plex-Token

Philips Hue¶

Category Light · Transport LAN, CLIP v2 over HTTPS to the bridge · Live Server-Sent Events push (changes appear instantly).
Setup Enter the bridge IP — or use Scan network (Bifrost finds the bridge via SSDP) — then press the bridge's physical link button when prompted to mint an application key.
Capabilities RGB color, color temperature, brightness, and dynamic effects (the bridge's CLIP v2 effects — candle, fire, sparkle, prism, …). Hue rooms and zones import as Bifrost Rooms, driven with native one-call group control. Hue motion accessories import as sensors — motion, light level, and temperature ride the same SSE stream, and a Hue room's sensors land in the linked Bifrost Room (feeding its occupancy).

Hue's ~10 req/s rate limit is handled with a per-bridge write pacer, so room-wide fan-outs don't drop commands.

Govee¶

Category Light · Transport Govee Cloud API and/or local LAN (UDP) · Live polling.
Setup Supply your API key (Govee Home app → Profile → About Us → Apply for API Key). Local LAN control is on by default — just turn on “LAN Control” for each device in the Govee Home app. (The LAN-interface field is advanced: leave blank for all interfaces / 0.0.0.0, set a specific IP only if multi-homed.)
LAN-preferred control — Bifrost controls each device over your local network whenever that device supports and has LAN Control enabled (faster, no cloud round-trip, no daily quota), and automatically falls back to the cloud for any device that isn't LAN-reachable. Only some Govee models support LAN, so this is decided per device. A host that can't reach the LAN (or has no API key) still works — it just uses whichever transport is available. The Devices page shows how each device is reached (a LAN/Cloud pill on the card, with detail in the expandable row).
Capabilities RGB color, color temperature, brightness, and effects = the device's dynamic light scenes — the built-in catalogue plus your own DIY scenes (often 100+ on a strip; the effects picker has search + categories for this). Effects are applied via the cloud. No native rooms.

LIFX¶

Category Light · Transport LIFX Cloud API and/or local LAN (UDP) · Live polling.
Setup Supply your access token (cloud.lifx.com/settings). Local LAN control is on by default (LIFX LAN is on by default on the bulbs — no per-device toggle needed). (The LAN-interface field is advanced: blank = all interfaces / 0.0.0.0.)
LAN-preferred control — plain colour/brightness/power goes over your local network whenever a bulb is reachable (faster, no quota, works during a cloud outage), falling back to the cloud for any bulb that isn't, and for effects (effects run via the cloud). The Devices page shows each bulb's LAN/Cloud connection. A host that can't reach the LAN (or has no token) still works on whichever transport is available.
Capabilities RGB color, color temperature, brightness, and firmware effects — off/breathe/pulse on every color bulb, move on multizone strips (Z/Beam), and morph/flame on matrix bulbs (Tile/Candle). LIFX groups import as Bifrost Rooms with one-call group control (cloud).

Nanoleaf¶

Category Light · Transport LAN, the Nanoleaf Open API (HTTP on port 16021) · Live polling.
Setup Click Scan network — the controller answers over mDNS (with its name) or the port sweep — or enter its IP address manually (find it in the Nanoleaf app, or on your router). Then pair: hold the controller's power button for ~5–7 seconds until the LED starts flashing, and pair (the same "press the button" flow as a Hue bridge). Pairing mints an auth token stored as the provider's credential; you can also paste a token you already have.
Capabilities RGB color (hue/saturation), color temperature (1200–6500 K), brightness, and effects — the controller's own effect list (e.g. "Northern Lights", "Windmill"). An effect is Bifrost's third light mode; brightness stays live while an effect plays (a brightness change never cancels the running effect). No native rooms.
De-dup The Open API exposes no MAC (only a serial), so a Home Assistant copy of the same panels isn't shadowed automatically (auto-shadowing is exact-MAC only) — shadow the HA duplicate manually from the Devices page if you run both.

TP-Link Kasa¶

Category Power · Transport LAN only — the legacy Kasa protocol (JSON over TCP port 9999); no cloud account, no credentials beyond the plug's IP · Live polling.
Setup Click Scan network (the same broadcast the Kasa app uses, plus a port sweep) or enter the plug's IP. One provider row per plug.
Limitation Plugs on KLAP firmware (2021+, or any plug that has been linked to a TP-Link cloud account) use an authenticated protocol Bifrost doesn't speak — they simply won't answer the scan. Older/never-cloud-linked plugs work as-is.

Onkyo / Integra¶

Category Audio · Transport LAN eISCP, one persistent socket per receiver · Live push — the receiver echoes every change on the open connection.
Setup Receiver IP — or Scan network (UDP discovery). Enable Network Standby on the receiver so Bifrost can power it on remotely.
Capabilities power, volume, mute, input/streaming-service selection (including NET services like Spotify / TIDAL / TuneIn), playback transport, and now-playing. A second output (zone 2) appears as its own device.

Onkyo receivers are the target for receiver binding — a TV or streamer can route its volume here, so "turn the TV up" controls the right box.

Sonos¶

Category Audio · Transport LAN UPnP · Live push (UPnP event subscriptions with a heartbeat-poll baseline).
Setup Any one player's IP — or Scan network. The rest of the household is discovered from it.
Capabilities power, volume, mute, transport, now-playing, Favorites (saved stations / playlists), and live sync grouping — grouped players collapse into one control. Each player imports as its own Room. Choose what to play from a Sonos app, then drive it from Bifrost's transport.

Newer integration

Sonos control, favorites, and grouping are implemented and addable; it's less battle-tested than the other providers, so report anything off.

Smart TV¶

Category Media + Remote · Transport the TV's own LAN HTTP API · Live polling.
Capabilities power (on/off, with the composite Wake-on-LAN/remote wake), volume, mute, transport, and a full remote (D-pad, navigation/media keys, app launch) — one TV surfaces as both a media device and a remote, unified into the AIO TV control.
Vendors Sony Bravia today (the ScalarWeb JSON API for state/power/audio + IRCC for key codes). The integration is a vendor-agnostic framework (BifrostSmartTv); more brands are added as self-contained vendor files.

Pairing a Sony Bravia (PIN)¶

Bravia control is authorised by a token you get through an on-screen PIN, so there's nothing to copy off a website. The TV and your Bifrost host must be on the same network. Scan network probes twice over: an SSDP multicast search plus an HTTP sweep of the local subnet that asks each host the (unauthenticated) ScalarWeb identity question — so the TV is found even when it dozes through the multicast probe, and in Docker without host networking.

1 — Allow control on the TV (one-time). The exact menu wording differs by model:

Google TV / Android TV Bravia (2015 and later): being on the same network is usually enough — the registration dialog (with the PIN) pops up the first time Bifrost pairs. If it never appears, enable the TV's IP/remote-device control under Settings → Network & Internet (look for Home network, IP control, or Remote device / renderer) and make sure the TV isn't in a store/restricted mode.
Older Linux Bravia (KDL-series): Settings → Network → Home Network Setup → IP Control — set Authentication to Normal and Pre-Shared Key and turn Simple IP Control On.

2 — Pair in Bifrost.

Settings → Providers → Add Provider, and choose Smart TV as the type.
Click Scan network and pick your TV — its IP auto-fills and the vendor (Bravia) is auto-selected. (Or type the TV's IP into the TV IP address field.)
Click Pair. Bifrost asks the TV to register Bifrost; the TV shows a 4-digit PIN on screen. (If the TV's IP-control Authentication is set to "None", it has no pairing service at all — Pair reports "No pairing needed" and you can add the provider without a token.)
Type that PIN into the field that appears and click Submit PIN. On success the Pairing token is filled in for you (✓ Paired with TV).
Give the provider a name and click Add. Bifrost discovers the TV as a media device and a remote (one physical box), and you control it from the unified TV fly-out.

Notes

The token is long-lived; you only re-pair if it's revoked (a TV factory reset, or Bifrost removed from the TV's list of registered remote devices).
"Pair" greys out until the TV IP is set. If pairing reports the TV is unreachable, confirm the IP and that step 1 is done.
Power-on uses the composite wake (Wake-on-LAN + the remote), so a TV in standby comes up even when its API is briefly unreachable.

Newest integration

The Smart TV framework and the Bravia vendor are new and the least hardware-tested — please report anything off.

Home Assistant¶

The high-class integration: one connection surfaces any Home Assistant integration as Bifrost devices across five domains from a single provider — lights, media (media players: TVs and speakers), power (switches, plugs, fans, helpers), remotes (Android TV / streamers), and sensors (motion, occupancy, contact, light level, temperature, humidity). HA Areas import as Bifrost Rooms.

Category Integration · Transport HA REST + a persistent WebSocket · Live WebSocket push — every domain stays live on one connection.
Setup HA base URL (e.g. http://homeassistant.local:8123) + a Long-Lived Access Token (HA → Profile → Security → Long-Lived Access Tokens → Create Token).
Capabilities lights pass through color / temperature / brightness and the entity's effect list; media players expose power / volume / mute / source / transport / now-playing and join-unjoin grouping; switches, plugs, and fans are on/off; remotes send keys, text, and app launches; sensors are read-only readings (presence kinds feed room occupancy). Named-content requests ("play Bob's Burgers on the bedroom TV") fall back to HA Assist.
Everything else — HA device types Bifrost doesn't natively model (climate, covers, locks, helpers, vacuums, …) still surface as generic "Other devices" on the Devices page, with controls derived live from the entity's state. A new HA device type appears there with no Bifrost change.

De-duplication¶

A physical device reachable both natively (Hue / Govee / Sonos / Onkyo) and through Home Assistant would otherwise import twice. Bifrost matches the two by hardware MAC and hides the HA copy under the native one — native always wins — so you control each device through its richest provider. (When HA exposes a capability the native provider lacks, that capability gets built natively rather than deferring to the hidden HA copy.)

Plex¶

A feed source, not a device provider: it surfaces no controllable devices. Adding a Plex Media Server powers the Boards "Recently added" widget — a poster shelf of the newest items in a library of your choosing (new episodes of one show roll up into a single tile).

Category Feed · Transport LAN HTTP against your own server · Live the widget polls about once a minute (the hub caches, so many kiosks cost one upstream read).
Setup the server URL (e.g. http://192.168.1.10:32400) + your account token — click Link, enter the 4-character code at plex.tv/link from any signed-in device, and the token fills in by itself. (Prefer doing it by hand? Pasting an X-Plex-Token still works: open any library item in Plex Web → ⋯ → Get Info → View XML, and copy the X-Plex-Token value from that page's URL.)
Privacy the token stays on the hub, encrypted like every credential; posters are proxied through the hub so the browser never talks to Plex directly.

Adding & extending¶

Every IP-addressable provider supports Scan network auto-detect; cloud providers take an account token.
Adding a new provider type is intentionally mechanical — implement the provider trait, register one factory line, and write tests — so the supported set grows over time.