hello@jonwgeorge:~$
← syslog

home assistant is the brain, homekit is the face

blog7 min read

Home Assistant runs my house. Every integration, every automation, every weird sensor and every bit of logic lives there. But almost nobody in my house ever opens Home Assistant, and that includes me most days.

The interface we actually use is Apple's Home app, fed by Home Assistant's HomeKit Bridge integration. HA does the thinking. HomeKit is just the remote control.

This isn't a knock on Home Assistant's dashboards. It's a design decision: put the brains in the most capable system, and put the controls on the surface people already carry everywhere.

The short version

  • Nobody else has to learn anything. The Home app is already on every iPhone, iPad, Apple Watch and Mac in the house.
  • Native OS integration I can't build myself. Siri, Control Center, Lock Screen, widgets, Apple Watch, CarPlay. No dashboard gets all of that.
  • Remote access without exposing Home Assistant. An Apple TV acts as the home hub. My family can control the house from anywhere, and HA never has to face the internet for them.
  • One source of truth. Every device is integrated once, in HA, regardless of vendor. HomeKit only sees what I choose to show it.
  • Clean separation of concerns. Logic lives in HA. HomeKit is just presentation. If I break the presentation layer, the house keeps running.

Why not just use Home Assistant dashboards?

I like HA dashboards. I build them. For me, as the person who maintains the system, a good Lovelace dashboard is the best admin console there is.

But a dashboard is still an app you have to open. For everyone else in the house it's another login, another URL, another icon, another thing that looks different from everything else on their phone. "Open the Home Assistant app, go to the Upstairs view, scroll down, tap the card" loses to "Hey Siri, turn off the lights" every single time.

The household acceptance test for smart home tech is brutal and simple: if it's harder than a light switch, people won't use it. HomeKit passes that test because Apple already did the UX work, and has done it on every device my family owns.

What HomeKit gives me for free

These are the things I'd never bother building, or couldn't build, in a custom frontend:

  • Siri. Voice control on phones, watches and HomePods, with no extra voice pipeline to maintain.
  • Control Center and Lock Screen. Favorite accessories one swipe away, without unlocking the phone.
  • Apple Watch. Lock the door or open the garage from your wrist while your hands are full.
  • CarPlay. The garage door shows up automatically as you pull into the driveway.
  • Widgets and Shortcuts. Home controls show up wherever iOS lets you put them.
  • Notifications. Door unlocked, garage left open, doorbell rang. These go out as native iOS notifications with per-person settings that each person controls.
  • User management. I invite household members in the Home app. They get access without me creating HA accounts, managing passwords or worrying about admin rights.

Every one of those is a feature I'd have to build, secure and maintain if I wanted it in a custom frontend. With the bridge, I get them by exposing an entity.

Remote access without opening a port

This is the one that sold me.

With an Apple TV acting as the home hub, HomeKit handles remote access through Apple's end-to-end encrypted relay. My family controls the house from anywhere, and I don't have to:

  • port-forward Home Assistant,
  • put it behind a reverse proxy just for them,
  • hand out VPN profiles, or
  • give every phone a long-lived HA login.

I still have my own remote path into HA for administration. But for daily use, the attack surface the family depends on is Apple's, not something I bolted together on a Saturday.

HA stays the single source of truth

The real power of this setup is that HomeKit doesn't need to support a device for it to show up in the Home app. If Home Assistant can talk to it, I can expose it.

That covers Z-Wave, Zigbee, cloud-only integrations, local APIs, ESPHome boards, template entities, and anything I can model as a helper. Vendors that never shipped HomeKit support, or dropped it, still show up as first-class accessories.

It also means I integrate each device exactly once. I don't pair a lock to HomeKit and to HA and then deal with two systems fighting over state. HA owns the device; HomeKit is a view of it.

Logic lives in HA, not in the Home app

I keep HomeKit automations to an absolute minimum. Home Assistant's automation engine is far more capable: conditions, templates, traces, version-controllable YAML, and real debugging when something misfires.

When I want a one-tap or voice-triggered routine, I write it as an HA script and expose it to HomeKit. Scripts show up in the Home app as switches, so "Hey Siri, Goodnight" flips a switch in HomeKit, and HA runs the real sequence: locks, lights, thermostat setpoints, whatever the logic needs.

That keeps the rule simple: HomeKit triggers, Home Assistant decides.

How I configure the bridge

The most important principle is to curate what you expose. Don't dump every entity into HomeKit. Your family doesn't need 40 diagnostic sensors, firmware update entities and a power-monitoring plug in their Home app. Expose what a human would actually want to control or see.

A trimmed-down version of the pattern I use:

homekit:
  # Main bridge: day-to-day controls only
  - name: HA Bridge
    port: 21064
    filter:
      include_domains:
        - light
        - lock
        - cover
        - climate
        - fan
      include_entities:
        - script.goodnight
        - script.leaving_home
        - binary_sensor.front_door
      exclude_entities:
        - light.workbench_test_bulb
    entity_config:
      lock.front_door:
        name: Front Door

  # Cameras and doorbells get their own accessory-mode instance
  - name: Front Doorbell
    port: 21065
    mode: accessory
    filter:
      include_entities:
        - camera.front_doorbell
    entity_config:
      camera.front_doorbell:
        linked_doorbell_sensor: binary_sensor.front_doorbell_ring
        support_audio: true

A few lessons baked into that config:

  • Filter by domain, then add specific entities. Domains get you the bulk of controllable devices; explicit includes pull in the handful of scripts and sensors worth seeing.
  • Use accessory mode for cameras and TVs. They behave better as standalone accessories than behind a bridge, and HomeKit requires accessory mode for TV media players.
  • Split into multiple bridges when it makes sense. A HomeKit bridge tops out at 150 accessories, and separate instances mean re-pairing one category doesn't disrupt the rest.
  • Name things for humans. Set names in entity_config or in HA itself before pairing. Renaming after the fact works, but it's cleaner to get it right the first time.

The trade-offs

This setup isn't free. The rough edges, honestly:

  • Rooms don't sync. HA areas don't carry over to HomeKit rooms. You assign rooms once in the Home app, and it's a one-time chore you'll repeat for every new device.
  • Names can drift. If someone renames an accessory in the Home app, that name lives in HomeKit, not HA. Two places can disagree.
  • mDNS is fragile. HomeKit discovery depends on mDNS. If HA's IP changes, or your IoT devices are on a separate VLAN, you need a stable address and an mDNS reflector or the bridge will show "No Response."
  • Not everything maps. HomeKit has a fixed set of accessory types. Lights, locks, thermostats, covers, fans, switches and common sensors are great. Energy dashboards, complex media controls or arbitrary numeric sensors are a poor fit, and that's where HA dashboards still earn their keep.
  • No HomeKit Secure Video. Cameras exposed through the bridge stream fine, but you don't get HKSV recording. If that matters, a dedicated tool like Scrypted is the better route for cameras.
  • It's Apple-only. This works because everyone in my house is on Apple devices. A mixed Android household changes the math.

None of these are dealbreakers for me, but they're real, and it's worth knowing them before you commit.

Why not Matter?

Matter is the obvious "future" answer, and for new devices I care a lot about Matter support. But as a frontend strategy, the HomeKit Bridge is mature, stable, and already supports every entity I need to expose. Matter solves device interoperability; it doesn't change the fact that I want one brain (HA) and one face (Apple Home). When the tooling for exposing HA entities over Matter is as solid as the HomeKit Bridge is today, I'll revisit it. The architecture stays the same either way.

The takeaway

Smart home systems tend to fail in one of two ways: the backend is too limited, or the frontend is too annoying for anyone but the person who built it.

Running Home Assistant behind the HomeKit Bridge avoids both. I get the most capable automation platform available, and my family gets an interface that's already on their phones, works with their voice, and never asks them to learn anything.

The best smart home is the one people don't notice. For us, that means Home Assistant in the background and Apple Home in front.

-- jonwgeorge

comments

sign in with github to comment. comments are kept in github discussions.