homekitify

Beta. TP-Link Kasa is hardware-verified; the other vendors are config-verified (validated against each plugin's schema, not yet on real hardware) and gated behind --beta. Published under the npm beta tag.

Scan your network, bridge your non-HomeKit Wi-Fi devices into Apple Home. One command, one QR scan, zero accounts.

npx homekitify@beta            # bridges hardware-verified vendors (Kasa)
npx homekitify@beta --beta     # also include the config-verified beta vendors

Lots of cheap smart devices — Kasa bulbs, LIFX, Shelly, WiZ, Wemo, Sonos — work great but have no Apple HomeKit support. Getting them into Apple Home today means a multi-hour manual slog: figure out what you own, learn that Homebridge exists, find the right plugin per brand, hand-write config, set up a boot service, then pair. homekitify collapses that into a ~30-second command for the devices that can be bridged locally — and tells you honestly which ones can't.

What it does

1. Scans your LAN (mDNS + ARP + per-vendor probes) — read-only, no sudo.
2. Identifies each device and the Homebridge plugin it needs.
3. Installs Homebridge + those plugins and generates working config.
4. Shows a QR code — scan it once in the Home app; the whole fleet pairs.

The single human step is that one QR scan. No usernames, no passwords, no API keys.

Supported devices (Light)

Zero-touch auto-discovery: TP-Link Kasa · WiZ · Shelly (Gen2+) · LIFX · Wemo · Sonos

Local, one quick step: Philips Hue (press the bridge button) · WLED (confirm IP)

Honestly not supported — and homekitify will tell you why instead of pretending:

• ☁️ Cloud-only devices (Govee, Tuya/Smart Life, Ring, Wyze, Meross) — need an account/API key.
• 🔒 White-label Tuya devices on BK7238/BK7236 chips — not bridgeable in software.

Tasmota and ESPHome are coming in Light+ (they need a broker / an encryption key, so they're not zero-config).

Commands

homekitify              # default: scan → install → configure → service → pairing QR
homekitify init         # same as bare `homekitify` (--yes to skip prompts, --no-service to skip boot service)
homekitify scan         # read-only LAN discovery + plugin classification (--json)
homekitify doctor       # environment + bridge health check
homekitify status       # is the managed bridge running?
homekitify logs [-n N]  # tail the managed bridge log
homekitify uninstall    # remove the managed service (keeps cache; --purge wipes)
homekitify pair-test    # isolated end-to-end pairing test (see below)

Trying the full flow safely (pair-test)

homekitify pair-test bridges your real local devices through the isolated sandbox bridge and shows a pairing QR. Pair it into a new, separate Apple Home (e.g. "Homekitify Test") — your real Home is never touched. When you press Enter it tears the bridge down and verifies your existing Homebridge is intact.

Status

Early development. The discovery engine, fingerprint map, install, and pairing flow are being built phase by phase. See docs/ for design notes.

Development

npm install
npm run build        # tsup → dist/cli.js
npm test             # L0 unit tests (mocked, no network, no Homebridge)
npm run lnp-check    # confirm this machine's node has LAN access

Safety: the test harness never touches your real Homebridge

If you already run Homebridge, homekitify's integration tests spin up a separate, isolated bridge (its own storage, plugin path, port, and identity) as a tracked child process. A hard preflight guard (src/sandbox/preflight.ts) aborts the run if any sandbox value could collide with a production install, and a health verifier confirms your live bridge is untouched before and after.

Privacy & telemetry

Telemetry is off by default. If you opt in (homekitify telemetry on), the only thing ever sent is anonymous vendor counts (e.g. {"kasa":2,"hue":1}) — never IP addresses, MAC addresses, device names, or any identifier, and only if a collector URL is configured. Toggle anytime with homekitify telemetry on|off|status.

License

Apache-2.0