How I Used AI to Audit 3 Years of Smart Home Tech Debt (And Built a System to Prevent It From Happening Again)

A journey from "help me understand my Home Assistant setup" to building a complete automation management system with CI/CD-style preprocessing

---

Three years ago, I started my Home Assistant journey the way most of us do: with enthusiasm, a handful of Zigbee bulbs, and absolutely no plan. Fast forward to January 2026, and I was staring at a 2,312-line automations.yaml file, wondering how it had all gone so wrong.

Then I discovered something that changed everything: AI-assisted home automation management.

The Wake-Up Call

It started with a simple question: "Why do I have three copies of the same automation?"

I had been adding smart devices incrementally for years. A motion sensor here, a TRV there, a few blinds, some presence detection. Each addition meant a new automation, usually copied from an existing one and tweaked. The mobile app made it easy to add things but impossible to see the big picture.

My Home Assistant had become a reflection of my own scattered decisions: 47 automations, 3,997 entities (1,637 of them disabled), duplicate integrations, references to a phone I had replaced two years ago, and a kitchen blinds automation that somehow ballooned to 636 lines of YAML.

Something had to change.

Enter Claude Code

I had been using Claude for coding tasks, but the idea of using it for home automation management seemed novel. Then I discovered the emerging ecosystem of MCP (Model Context Protocol) servers designed specifically for Home Assistant integration.

The landscape was surprisingly mature:

• ha-mcp with 82 tools for entity control, automation management, and system administration
• home-assistant-vibecode-agent designed specifically for Claude Code workflows with Git-based versioning
• AI Automation Suggester that scans your setup and proactively suggests new automations
• Home-LLM for fully local, privacy-conscious AI control

What struck me was the philosophy shift these tools represented. Instead of AI being a voice assistant that turns lights on and off, these tools positioned AI as a management layer - something that could audit, plan, and help maintain complex configurations.

The Audit Begins

I set up a Docker-based staging environment on port 8124, pulled my production config, and started asking Claude to analyze what I had built.

The results were sobering.

The Duplication Problem

My "Dan Presence" automation existed three times, all with the same ID. In Home Assistant, duplicate IDs mean only one actually executes - but I had no way of knowing which. The dishwasher notification automation? Two copies. "Both away" detection? Duplicated.

| Automation                  | Duplicates |
|-----------------------------|------------|
| Dan Presence                | 3x         |
| Dishwasher States           | 2x         |
| Both Away                   | 2x         |

The Ghost Device Problem

Remember that Pixel 6a I replaced? My configuration certainly did. The notify.mobile_app_pixel_6a service was referenced 31 times across automations and scripts. Every notification I thought was being sent was silently failing because the target device no longer existed.

The dishwasher finished notification. The washing machine alert. The heating status updates. All broken. All silently failing.

During one debugging session with Claude, I finally untangled the device history:

• The Pixel 6a was Liv's old phone (not mine, as I had assumed)
• My current phone is a Pixel 10 Pro XL
• Liv's current phone is a Pixel 9a

This discovery was crucial - I had been chasing the wrong device the whole time, and it explained why some notifications worked while others did not. The correct mapping should have been:

NOTIFY_LIV: notify.mobile_app_pixel_9a
NOTIFY_DAN: notify.mobile_app_pixel_10_pro_xl

But more on that token syntax later - it becomes the foundation of the solution.

The Over-Engineering Problem

The crown jewel of technical debt was my kitchen blinds automation: 636 lines of YAML handling:

• 15 different triggers
• Sun zone calculations
• Seasonal temperature factors
• Debug mode (still enabled in production)
• Edge cases for cloud cover, visitors, and manual overrides

It worked, technically. But it was unmaintainable, untestable, and I had no memory of why half the conditions existed.

The Integration Chaos

Building the GitOps Workflow

The solution that emerged was a GitOps-style workflow for Home Assistant configuration:

┌─────────────────────────────────────────────────────────────────┐
│                         Dev Machine                              │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                     Claude Code                          │   │
│  │  ┌─────────────┐  ┌──────────────┐  ┌──────────────┐    │   │
│  │  │   ha-mcp    │  │  Git Repo    │  │   hass-cli   │    │   │
│  │  │ (MCP Tools) │  │  (Version    │  │    (Bash)    │    │   │
│  │  └──────┬──────┘  │  Control)    │  └──────┬───────┘    │   │
│  └─────────┼─────────┴──────────────┴─────────┼────────────┘   │
│            │                                   │                 │
└────────────┼───────────────────────────────────┼─────────────────┘
             ▼                                   ▼
   ┌─────────────────────┐            ┌─────────────────────┐
   │  Docker Staging     │            │  Production HA      │
   │  localhost:8124     │            │  192.168.1.217      │
   └─────────────────────┘            └─────────────────────┘

The key insight was separating concerns:

1. Staging environment for safe experimentation
2. AI assistance for auditing and planning
3. Git versioning for tracking changes
4. Controlled deployment to production

This meant I could ask Claude to analyze my automations, suggest consolidations, and even generate new YAML - all without touching my production system until I was confident in the changes.

What I Learned About AI + Home Automation

Local vs Cloud LLMs

The research revealed an interesting split in the community. Privacy-conscious users gravitate toward local solutions like Home-LLM, which runs optimized models under 5B parameters on modest hardware (even a Mac Mini M4 works beautifully). Meanwhile, cloud options like Google Generative AI offer 14x better cost-performance than OpenAI for voice assistant use cases.

For management tasks, the cloud-based Claude Code with MCP integration proved invaluable. The ability to search, analyze, and suggest across thousands of entities requires context windows that local models struggle with.

The Discovery That Changed My Approach

The most useful insight came from analyzing the .storage/core.restore_state file. This file contains last_triggered timestamps for every automation and script. With a simple jq query, I could see:

Never triggered (dead code):

• automation.boiler_automation_heating_control_simple
• automation.utility_automation_heating_boost
• script.script_bedroom_stop_aircon

Not triggered in 12+ months:

• Garden lights scripts (28 months!)
• Christmas lights toggle (24 months)
• Various disabled automations superseded by newer versions

This data-driven approach to identifying dead code was something I never could have done manually. Claude could process this data, cross-reference it with entity registries, and tell me exactly what was safe to remove.

Dashboard Best Practices

The research also uncovered modern dashboard patterns I had missed:

• Sections View (HA 2024.3+) - drag-and-drop without YAML
• Areas Dashboard (HA 2025.4+) - auto-generates from your area configuration
• Mushroom Cards + Bubble Card for mobile-optimized interfaces

My current dashboard had bugs I never noticed: duplicate toggle buttons, wrong room entities (the Guest Room section was showing Office controls), and missing rooms entirely. The AI-assisted audit caught all of these.

The Cleanup Plan

The audit produced a prioritized cleanup plan:

Immediate (Critical Bugs)

• Remove duplicate automation IDs
• Fix empty trigger automations
• Migrate notifications from Pixel 6a to current device

This Week (Breaking Changes)

• Delete 578 orphaned mobile_app entities
• Remove duplicate Tuya/SmartLife integration
• Fix stale entity references

This Month (Simplification)

• Simplify kitchen blinds automation (636 lines to approximately 80)
• Consolidate garden light scripts into a single light group
• Standardize entity naming conventions

Estimated Impact

• Lines of code removed: approximately 1,500
• Orphaned entities removed: approximately 1,000
• Total effort: approximately 16 hours

From Audit to Architecture: The Automation Build System

The cleanup plan was useful, but it only solved the immediate problem. What about the next time I upgrade my phone? Would I be hunting through YAML files to update 31 references again?

This question led to what became the most interesting outcome of the entire project: an automation build system inspired by software development practices.

The DRY Principle for Home Automation

The core problem was repetition. Device service names like notify.mobile_app_pixel_6a were hardcoded everywhere. When the device changed, every reference broke. The solution was borrowed from software engineering: token substitution.

Instead of hardcoding device services, automations would reference tokens:

# Instead of this:
service: notify.mobile_app_pixel_6a
data:
  message: "Dishwasher finished"

# Write this:
service: \${NOTIFY_LIV}
data:
  message: "Dishwasher finished"

The tokens are defined in a single _tokens.yaml file:

# _tokens.yaml
NOTIFY_LIV: notify.mobile_app_pixel_9a
NOTIFY_DAN: notify.mobile_app_pixel_10_pro_xl
NOTIFY_ALL: notify.all_phones
PERSON_DAN: person.dan
PERSON_LIV: person.liv

The next time Liv upgrades her phone, I change one line. That is it. The 31-reference nightmare becomes a one-line fix.

Reusable Action Blocks

Token substitution was just the start. Claude and I identified patterns that repeated across automations: the same notification sequences, the same conditional checks, the same trigger configurations.

This led to reusable action blocks:

# _blocks.yaml
notify_both_critical:
  - service: \${NOTIFY_DAN}
    data:
      message: "\${MESSAGE}"
      data:
        priority: high
  - service: \${NOTIFY_LIV}
    data:
      message: "\${MESSAGE}"
      data:
        priority: high

notify_dan_only:
  - service: \${NOTIFY_DAN}
    data:
      message: "\${MESSAGE}"

Automations reference these blocks with a special syntax:

action:
  \$ACTION{notify_both_critical}:
    MESSAGE: "The dishwasher has finished"

The build script expands this into the full action sequence, with the message substituted in.

Organized by Category

With token substitution and reusable blocks in place, the next step was organization. Instead of one massive automations.yaml file, automations live in category directories:

automations/
├── _tokens.yaml           # Device and entity tokens
├── _blocks.yaml           # Reusable action/condition blocks
├── presence/
│   ├── dan_arrives.yaml
│   ├── liv_arrives.yaml
│   └── both_away.yaml
├── appliances/
│   ├── dishwasher.yaml
│   ├── washing_machine.yaml
│   └── dryer.yaml
├── heating/
│   ├── morning_boost.yaml
│   └── away_setback.yaml
└── lighting/
    ├── motion_triggers.yaml
    └── sunset_routines.yaml

The Build Script

A Python build script marshals everything back into the single automations.yaml that Home Assistant expects:

1. Load tokens from _tokens.yaml
2. Load reusable blocks from _blocks.yaml
3. Walk category directories, processing each automation file
4. Substitute tokens (\${NOTIFY_DAN} becomes the actual service)
5. Expand block references (\$ACTION{notify_both_critical} becomes the full action list)
6. Validate the result (no unresolved tokens, valid YAML structure)
7. Write the final automations.yaml

This is CI/CD for home automation. The source files are human-readable and DRY. The output is what Home Assistant needs.

Why This Matters

The build system transforms how I think about automation maintenance:

The system is also self-documenting. Looking at _tokens.yaml tells you exactly which devices and entities are used across all automations.

The Five-Phase Implementation Plan

With the audit complete and the build system designed, Claude and I developed a comprehensive implementation plan. The key insight was staging: certain things had to be fixed before others could begin.

Phase 0: Prerequisites (Blocking)

Nothing else could proceed until these were resolved:

• Fix broken automations - The duplicate IDs and empty triggers had to go first
• Migrate notify services - Update all 31 Pixel 6a references to current devices
• Audit entities - Document what exists before creating helper entities

This phase was marked as "blocking" because starting dashboard work with broken automations would just create more problems.

Phase 1: Foundation

With the critical bugs fixed:

• Create helper entities - Input booleans, counters, and input_text for the notification system
• Fix dashboard bugs - The Guest Room showing Office controls, duplicate buttons
• Quick action scripts - Consolidated scripts for common tasks

Phase 2: Tablet Dashboard

The first new dashboard targets our Fire HD 10 tablet mounted in the kitchen:

• Landscape layout optimized for wall-mounted display
• Bubble Card navigation with swipe gestures
• At-a-glance status for all major systems
• Quick actions prominently displayed

Phase 3: Mobile Dashboard

A separate dashboard optimized for phones:

• Portrait orientation
• Larger touch targets
• Simplified navigation
• Focus on most-used controls

Phase 4: Desktop Dashboard

For browser access:

• Multi-column layout using screen width
• More detailed status displays
• Administrative controls

Phase 5: Polish

Cross-cutting concerns:

• Test all dashboards on actual devices
• Code review of all automations
• Documentation update
• Final cleanup of orphaned entities

The Notification Center

One pattern that emerged from the planning was a proper notification system. Instead of fire-and-forget notifications that disappear if you miss them, we designed a slot-based notification center:

The Design

# Helper entities
counter.notification_unread: 0-99 badge count
input_text.notification_slot_1: 255 character limit
input_text.notification_slot_2: 255 character limit
# ... up to slot 10
input_text.notification_slot_10: 255 character limit

When a notification fires:

1. Increment counter.notification_unread
2. Find the oldest slot and overwrite it
3. Display the badge count on dashboards

Users can:

• Dismiss individual notifications
• Clear all notifications
• See history of recent notifications (up to 10)

This solves the problem of missing important notifications when away from the dashboard. The badge persists until you acknowledge it.

Why Slots Instead of a Database

Home Assistant's input_text helper has a 255-character limit, which seems restrictive. But the slot approach has advantages:

• No external database required
• Works entirely within Home Assistant
• Simple to implement and debug
• Automatic cleanup (oldest rotates out)
• Survives restarts without additional configuration

For a household notification system, 10 slots of 255 characters is plenty.

Setting Up Claude Code for Home Assistant

The tooling setup evolved significantly through the project. What started as Docker-based staging eventually moved to direct production access with proper safeguards.

The Final Stack

ha-mcp connected to production Home Assistant provides 82 tools:

• Entity control (turn things on/off, set values)
• Automation management (enable, disable, trigger)
• System administration (reload configurations, restart services)
• State queries (get entity states, attributes, history)

claude-skill-homeassistant adds deployment workflows:

• Safe reload sequences
• Validation before deployment
• Rollback procedures

Git submodule for configuration:

• Production HA config lives in Danm72/Homeassistant repository
• Mounted as submodule in the development project
• Changes tracked with full history

Direct Production Workflow

The original plan involved a Docker staging environment, but in practice the workflow simplified:

1. Claude reads current configuration via ha-mcp
2. Changes are made to files in the Git repo
3. Changes are validated locally (YAML syntax, schema)
4. Files are deployed to production via scp or Git push
5. Configuration is reloaded via ha-mcp
6. Changes are verified by checking entity states

The staging environment remains available for risky changes, but most work happens directly against production with Git as the safety net.

What 82 Tools Actually Means

Having ha-mcp connected means Claude can:

# Check if an automation is working
> "Is the dishwasher notification automation triggering?"
[Claude queries automation state, last_triggered, checks logs]

# Debug a problem
> "Why aren't the living room lights responding?"
[Claude checks entity states, automation traces, Zigbee network]

# Make changes safely
> "Disable the broken heating automation until I fix it"
[Claude disables automation, confirms state change]

This is fundamentally different from copying YAML snippets back and forth. Claude has actual visibility into the system state.

The Bigger Picture

What started as a tech debt cleanup project evolved into something more interesting: a vision for AI-assisted smart home management.

The tools exist today to have AI:

• Audit your configuration and identify problems
• Suggest new automations based on your entity ecosystem
• Generate YAML from natural language descriptions
• Validate changes before deployment
• Track and rollback problematic changes

This is not about voice assistants that turn lights on and off. This is about AI as a co-pilot for complex system management.

Practical Takeaways

If you are considering AI tools for your Home Assistant setup, here is what I learned:

Start with an audit, not new features. The most valuable AI assistance was not generating new automations - it was analyzing what I already had and finding problems. You cannot improve what you do not understand.

Use MCP servers for real integration. ha-mcp provides 82 tools that let Claude directly interact with your instance. This is fundamentally different from copying YAML back and forth - Claude can query state, check logs, and verify changes.

Treat device references as configuration, not code. Token substitution (\${NOTIFY_DAN} instead of notify.mobile_app_pixel_10_pro_xl) means device changes become single-line updates. This principle alone would have saved me hours of debugging.

Data-driven decisions work. The last_triggered timestamps in .storage/core.restore_state are pure gold. Let AI process this data to find dead code. I found automations that had not run in 28 months.

Version control everything. Git is not just for code. Your Home Assistant config deserves the same treatment. When something breaks, git diff tells you exactly what changed.

Plan in phases with dependencies. Phase 0 (prerequisites) exists for a reason. Trying to build new dashboards while automations are broken just compounds problems.

The iterative conversation matters. Some of the best insights came from clarifying questions. "Wait, whose phone was that?" led to understanding the entire notification problem differently.

What Comes Next

The project has evolved from "help me understand my setup" to a structured implementation plan:

Immediate (Phase 0):

• Migrating all 31 Pixel 6a references to current devices
• Removing duplicate automation IDs
• Fixing the empty trigger automations

Near-term (Phases 1-2):

• Implementing the token-based automation build system
• Creating the notification center with helper entities
• Building the Fire HD 10 tablet dashboard

Longer-term (Phases 3-5):

• Mobile and desktop dashboards
• Full automation reorganization by category
• Documentation and polish

The build system is the key investment. Once _tokens.yaml and the preprocessing script are in place, future device changes become trivial. The phone upgrade problem is permanently solved.

Reflections on AI-Assisted Home Automation

What surprised me most about this project was the iterative nature of discovery. The initial goal was simple: understand what I had built. But each session with Claude revealed new problems and new solutions:

• Session 1: "Why do I have three copies of this automation?"
• Session 3: "Wait, the Pixel 6a was Liv's phone, not mine"
• Session 5: "What if we never hardcoded device names again?"
• Session 7: "This is basically a CI/CD pipeline for YAML"

The AI did not just find problems - it helped design systems to prevent them from recurring. That shift from reactive debugging to proactive architecture is where the real value emerged.

Three years of accumulated decisions created a mess. A few weeks of AI-assisted work created not just a cleanup plan, but a fundamentally better way to manage the system going forward. The smart home of the future is not just automated - it is intelligently managed, version-controlled, and designed for change.

---

This blog post was written as part of a Home Assistant GitOps project. The research documents, audit findings, and tooling comparisons referenced are available in the project repository. Tools and Concepts Mentioned: MCP Servers:

• ha-mcp - MCP server with 82 tools for entity control and automation management
• home-assistant-vibecode-agent - Claude Code + Git integration
• claude-skill-homeassistant - Deployment workflows for safe configuration updates

AI Tools:

• Home-LLM - Local LLM for privacy-conscious Home Assistant control
• AI Automation Suggester - Proactive automation suggestions

Dashboard Components:

• Mushroom Cards - Clean, modern dashboard cards
• Bubble Card - Mobile-optimized navigation with swipe gestures

Concepts:

• Token substitution for device references (DRY automation management)
• Reusable action blocks with parameter substitution
• Category-based automation organization
• Slot-based notification center using input_text helpers
• GitOps workflow for Home Assistant configuration

---

→ Continue reading: Part 2: What actually happened when I implemented the plan