Your home,
as a control plane.

Open-source home automation built on Crossplane v2, with a generic device inventory on DRA. Every adapter is a provider, every room a namespace, every automation an Operation.

Crossplane v2Inventory with DRAGitOps

See examples How it works

living-room/strip-on.yamlbutton press → all light strips on

apiVersion: automation.homeplane.io/v1alpha1
kind: Rule
metadata:
  name: strip-on
  namespace: living-room
spec:
  event:
    buttonPressed:
      ref:
        name: button
      channel: 1
  do:
    - turnOn:
        selector:
          matchLabels:
            homeplane.io/type: lightstrip

Concepts you know, primitives you trust

If you have used ioBroker or Home Assistant, you already know the ideas. Homeplane maps each one onto a Kubernetes or Crossplane primitive.

Smart homeHomeplane

AdapterProvider

Device discoveryDRA ResourceSlice

RoomNamespace

Light, thermostat, buttonXRD + Composition

AutomationRule → Operation

Three layers, one API

Vendor details stay at the bottom. Rooms and automations only ever talk to vendor-neutral types.

LAYER 1

Inventory

Providers publish every device as a DRA ResourceSlice and report live state in the claim. One generic inventory across all vendors.

ResourceSlice

LAYER 2

Home API

Light, Thermostat, Cover, Button. One schema per device type, selected with CEL. Compositions pick the vendor.

XRD + Composition

LAYER 3

Automations

Typed Rules with events and actions. Every Rule runs as a Crossplane Operation, reviewed in Git and tested offline.

WatchOperation

Examples

Devices and automations are plain manifests. Pick one.

living-room/strip.yamlHome API

apiVersion: homeplane.io/v1alpha1
kind: Light
metadata:
  name: strip
  namespace: living-room
  labels:
    homeplane.io/type: lightstrip
spec:
  deviceSelector:
    cel: >-
      device.attributes["homeplane.io"].id == "31:79:F1:66:00:86:67:6D"

living-room/strip-on.yamlRule

apiVersion: automation.homeplane.io/v1alpha1
kind: Rule
metadata:
  name: strip-on
  namespace: living-room
spec:
  event:
    buttonPressed:
      ref:
        name: button
      channel: 1
  do:
    - turnOn:
        selector:
          matchLabels:
            homeplane.io/type: lightstrip

living-room/lights-off.yamlRule · schedule

apiVersion: automation.homeplane.io/v1alpha1
kind: Rule
metadata:
  name: lights-off
  namespace: living-room
spec:
  event:
    schedule:
      at: "23:00"
      timeZone: Europe/Berlin
  do:
    - turnOff:
        selector:
          matchLabels:
            homeplane.io/type: lightstrip

living-room/wall-follows.yamlRule · climate

apiVersion: automation.homeplane.io/v1alpha1
kind: Rule
metadata:
  name: wall-follows
  namespace: living-room
spec:
  event:
    setpointChanged:
      ref:
        name: wall
  do:
    - overrideSetpoint:
        roomRef:
          name: living-room
        until: nextSchedulePhase

Design principles

What makes a control plane behave like a home, not like a cloud account.

Last writer wins

Press the wall switch and the light stays on. Spec changes are applied when they change; physical changes are never reverted.

Cluster down ≠ house down

Critical paths keep a device-local fallback. The cluster orchestrates; it is never the only path.

One owner per field

Git owns configuration, Rules own actions, the climate pipeline owns setpoints. Nobody fights over a field.

GitOps native

Rooms, devices and automations are manifests, reviewed in pull requests and tested offline before they touch a radiator.