| name | homekit-automator |
| description | Full-featured Apple HomeKit smart home automation skill for macOS. Create, manage, and trigger complex home automations through natural conversation — lights, thermostats, locks, sensors, scenes, and more. Automations are registered as native Apple Shortcuts so they run reliably on schedule even when the AI agent isn't active. Use this skill whenever the user mentions smart home, HomeKit, home automation, Apple Home, lights, thermostat, locks, garage door, scenes, routines, or wants to control or automate anything in their house. Also trigger when the user mentions Shortcuts integration with home devices, energy monitoring, or asks about the state of devices in their home. This skill should be used even for simple queries like "turn off the lights" because it provides richer device context and error handling than raw commands.
|
| version | 1.2.0 |
| metadata | {"openclaw":{"emoji":"🏠","os":["macos"],"homepage":"https://github.com/and3rn3t/homekit-automator","requires":{"bins":["homekitauto"],"env":[]},"install":[{"kind":"brew","formula":"homekit-automator","bins":["homekitauto"]}]}} |
HomeKit Automator
A comprehensive Apple HomeKit automation skill that turns natural conversation into reliable
smart home control and scheduling. Built as a standalone macOS app with a native HomeKit bridge,
MCP server, and an automation engine that registers schedules as Apple Shortcuts.
Quick Reference
Read docs/architecture.md for the full system architecture and design decisions.
Read docs/mcp-tools.md for detailed MCP tool specifications and parameters.
Read docs/automation-schema.md for the automation definition format.
Read docs/shortcuts-integration.md for how Apple Shortcuts bridging works.
How This Skill Works
HomeKit Automator is a two-process macOS application:
- Main App — A SwiftUI menu bar app that manages the UI, settings, and helper lifecycle
- HomeKit Bridge — A Mac Catalyst helper that connects to Apple's HomeKit framework via
HMHomeManager and communicates over a Unix domain socket in ~/Library/Application Support/homekit-automator/
On top of this foundation, the skill provides:
- MCP Server (stdio) — 15 tools that Claude/OpenClaw can call for device control,
automation management, and home intelligence
- Automation Engine — Parses natural language intent (via the LLM) into structured
automation definitions, validates them against discovered devices (with Levenshtein fuzzy
matching for device names, characteristic writability checks, and value range enforcement),
evaluates conditions at runtime, and registers automations as native Apple Shortcuts
- CLI Tool (
homekitauto) — Direct terminal access to all capabilities
- Multi-Home Support — All commands accept a
--home flag to target a specific home
when the user has more than one HomeKit home configured
When to Use Each Tool
Device Discovery and Control
Use home_discover as the first tool call in any new conversation about the user's home.
It returns a complete map of rooms, devices, and capabilities. Cache this mentally for the
session — you don't need to call it again unless the user adds new devices.
Use device_control for immediate, one-off commands. The user says "turn off the kitchen
lights" — that's a device_control call, not an automation.
Use device_status to check the current state of specific devices or rooms. Good for
answering "is the garage door open?" or "what's the temperature in the bedroom?"
When querying temperature, use the units parameter (celsius or fahrenheit) to return
values in the user's preferred scale. The CLI equivalent is --units celsius|fahrenheit.
Use scene_trigger when the user wants to activate an existing Apple Home scene. Scenes
are pre-configured in the Home app — this skill can trigger them but not create new ones
(use automations for custom multi-device actions).
Automation Management
Use automation_create when the user wants something to happen automatically or repeatedly.
Key signals: "every morning," "when I leave," "at sunset," "on weekdays," or "set up a routine."
The LLM's job is to parse the user's intent into the automation schema (see
docs/automation-schema.md). Pass the structured JSON via the --definition flag
(not --json). The engine runs a full validation pipeline before accepting:
- Device existence check (with Levenshtein fuzzy match for near-miss suggestions)
- Characteristic support and writability verification
- Value range enforcement
- Cron expression parsing and validation
- Duplicate automation name enforcement
Use automation_list to show the user their existing automations. Present them in a clean,
readable format — name, trigger, what it does, whether it's enabled.
Use automation_edit to modify an existing automation. The user might say "change my morning
routine to start at 7:15 instead of 7:00" — find the automation by name, apply the change.
Use automation_delete to remove an automation and its corresponding Apple Shortcut.
Use automation_test to dry-run an automation — execute all its device actions immediately
without registering a Shortcut. Great for "let me try my bedtime routine right now."
automation_test now evaluates conditions at runtime before executing actions. If the
automation has conditions (e.g., "only if temperature is below 70"), the test checks those
conditions against live device state and reports whether they passed or were skipped.
Intelligence
Use home_suggest when the user asks for recommendations. This tool analyzes the device map
and current automations to suggest useful routines the user hasn't set up yet. The suggestion
engine includes seasonal awareness (e.g., heating suggestions in winter, fan/cooling in summer)
and pattern-based analysis (detecting repeated manual commands that could be automated).
For example, if they have motion sensors and lights but no motion-triggered lighting automation.
Use energy_summary for usage insights. This queries device states and automation history
to provide information about which devices are running, how often automations fire, and
potential optimizations. Pass --history to get week-over-week energy comparison data
for trend analysis.
Parsing Natural Language Into Automations
This is the core intelligence the skill provides. When the user describes an automation in
natural language, follow this process:
Step 1: Identify the Trigger
| User says | Trigger type | Parameters |
|---|
| "every morning at 7" | schedule | cron: 0 7 * * * |
| "on weekdays at 6:45am" | schedule | cron: 45 6 * * 1-5 |
| "at sunset" | solar | event: sunset, offset: 0 |
| "30 minutes before sunrise" | solar | event: sunrise, offset: -30 |
| "when I say bedtime" | manual | keyword: bedtime |
| "when the front door opens" | device_state | device, characteristic, value |
Step 2: Identify Conditions (if any)
Conditions are optional guards. Examples:
- "only on weekdays" ->
day_of_week condition
- "if it's after dark" ->
solar condition
- "unless the temperature is above 75" ->
device_state condition
- "only if I'm home" ->
occupancy condition (requires presence sensor)
Step 3: Identify Actions
Map each requested action to a device + characteristic + value:
- "turn on the kitchen lights" -> device: Kitchen Lights, characteristic: power, value: true
- "set brightness to 60%" -> device: (context), characteristic: brightness, value: 60
- "lock the front door" -> device: Front Door Lock, characteristic: lockState, value: locked
- "set the thermostat to 72" -> device: Thermostat, characteristic: targetTemp, value: 72
Actions can have delays between them: "turn on the lights, then after 5 minutes start the coffee maker"
Step 4: Validate Against Device Map
Before creating the automation, verify every referenced device exists and supports the
requested characteristics. The validation engine handles this automatically with these checks:
- Device not found — Uses Levenshtein distance to suggest similar device names.
If the user says "bedroom lamp" but the device is "Bedroom Light," the engine suggests it.
- Read-only characteristic — e.g.,
currentTemperature is read-only; suggest targetTemperature instead.
- Value out of range — e.g., brightness must be 0–100; the engine reports the valid range.
- Characteristic not supported — e.g., a basic switch doesn't have brightness.
If a device name is ambiguous ("the lights" when there are lights in multiple rooms),
ask the user to clarify.
Step 5: Confirm With the User
Present a clean summary before creating:
Here's what I'll set up:
**Morning Routine** (weekdays at 6:45 AM)
Conditions: temperature below 70°F
1. Kitchen Lights -> on, brightness 60%
2. Thermostat -> heat to 72°F
3. Front Door Lock -> unlock
4. [after 5 min] Coffee Maker -> on
This will be registered as an Apple Shortcut that runs automatically.
Want me to create this?
Always show conditions in the summary so the user understands when the automation will
and won't fire.
Step 6: Create and Register
Call automation_create with the structured definition via --definition. The engine
validates all devices, characteristics, value ranges, and cron expressions, then creates
the Apple Shortcut (checking for existing shortcuts with the same name first) and confirms
registration.
Handling Ambiguity
Smart home commands are often ambiguous. Handle these gracefully:
- "Turn off the lights" — If there are lights in multiple rooms, ask which room, or offer
"all lights." If the conversation has established a room context, use that.
- "Make it warmer" — Check current thermostat setting, suggest +2 degrees. If multiple
thermostats, ask which zone.
- "Set up a routine" — Ask what the routine should be called and what it should do. Offer
template suggestions based on discovered devices.
- Device not found — Suggest similar device names. Maybe they said "bedroom lamp" but the
device is named "Bedroom Light."
Error Handling
| Error | User-friendly response |
|---|
| Socket not connected | "HomeKit Automator doesn't seem to be running. Make sure the menu bar app is open." |
| Device not responding | "The [device] isn't responding. It might be offline or out of range." |
| Characteristic not supported | "The [device] doesn't support [action]. Here's what it can do: [list]." |
| Shortcut registration failed | "I couldn't register the automation as a Shortcut. Try opening the Shortcuts app and granting permission." |
| HomeKit unavailable | "HomeKit isn't available. Make sure you're signed into iCloud and have a Home set up in the Home app." |
| Device not found (with suggestion) | "I couldn't find 'Bedroom Lamp'. Did you mean 'Bedroom Light'?" (Levenshtein fuzzy match) |
| Read-only characteristic | "'currentTemperature' is read-only on the thermostat. Use 'targetTemperature' to set the desired temperature." |
| Value out of range | "Brightness must be between 0 and 100. You specified 150." |
| Duplicate automation name | "An automation named 'Morning Routine' already exists. Choose a different name or delete the existing one." |
| Cron parse error | "Invalid cron expression '60 7 * * *'. Minute must be 0–59." |
| Condition not met (during test) | "Condition not met: temperature is 73°F (expected below 70°F). Actions were skipped." |
Templates
When the user asks to "set up a routine" without specifics, offer these templates based on
their discovered devices:
- Morning — Lights on (warm, gradual), thermostat to comfort, unlock doors
- Bedtime — Lights off (or dim to nightlight), doors locked, thermostat to sleep temp
- Away — All lights off, doors locked, thermostat to eco mode
- Movie Night — Living room lights dim to 10%, other rooms off
- Guest Mode — Guest room lights on, front door unlocked temporarily
- Good Morning (weekend) — Similar to morning but later, gentler lighting
The home_suggest tool also generates seasonal suggestions (e.g., winter heating
schedules, summer fan/cooling routines) and pattern-based suggestions (detecting
repeated manual commands that could be automated). Use these to proactively recommend
automations even when the user hasn't asked.
Only suggest templates that are possible given the user's actual devices.
Multi-Home Support
When the user has multiple HomeKit homes (e.g., "Main House" and "Beach House"), all
commands accept a --home parameter to target a specific home. If not specified, the
default/primary home is used.
Examples:
home_discover with home: "Beach House" — discover devices in that home onlydevice_control with home: "Beach House", device: "Porch Lights" — control a
device in the Beach Houseautomation_create with home: "Beach House" — register automation to the correct home
Always ask the user which home they mean if the conversation is ambiguous and they have
multiple homes.
Temperature Units
The device_status and device_control tools accept a units parameter (celsius or
fahrenheit) for temperature values. The CLI equivalent is --units celsius|fahrenheit.
- When reading temperature: values are converted to the requested unit before display
- When setting temperature: the provided value is interpreted in the requested unit and
converted to the device's native unit (Celsius for HomeKit) before sending
- Default behavior: uses the system locale to determine the preferred unit
Always match the user's preferred unit. If they say "72 degrees" in the US, that's Fahrenheit.
If they say "22 degrees" in Europe, that's Celsius.
Energy History
The energy_summary tool supports a --history flag that returns week-over-week energy
comparison data. This includes:
- Total device on-time for the current vs. previous week
- Automation execution counts with trend direction (up/down/stable)
- Per-device usage deltas highlighting which devices are consuming more or less
- Actionable insights like "Thermostat ran 23% more this week — consider lowering target temp"
Use this when the user asks about energy trends, usage changes, or wants to optimize their
home's efficiency over time.
Condition Evaluation
When automation_test is called on an automation with conditions, the engine evaluates
each condition against live device state before executing actions:
- Time conditions — checked against current system time
- Day-of-week conditions — checked against current day
- Device state conditions — queries the actual device value from HomeKit
- Solar conditions — checks current time against sunrise/sunset
If any condition is not met, the test reports which conditions failed and skips action
execution. This lets the user verify their conditions are correctly configured.
Example output when a condition blocks execution:
Condition check: Living Room Thermostat currentTemperature < 70
Current value: 73°F — condition NOT MET
Actions skipped (1 of 1 conditions failed)
Configuration
The skill stores its configuration at ~/Library/Application Support/homekit-automator/:
config.json — Active home, device filters, preferencesautomations.json — Local automation registry (source of truth for what's been created)device-cache.json — Cached device map (refreshed on each home_discover call)
Prerequisites
- macOS 14.0 (Sonoma) or later
- Apple Home app configured with at least one home and device
- iCloud signed in (HomeKit requires it)
- Apple Developer account (for HomeKit entitlement during development signing)
- Shortcuts app available (ships with macOS)
