Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed.
I already use AI to write Home Assistant automations because putting together long YAML files isn’t something I particularly enjoy. I’ve also connected Claude Code to Home Assistant, so I can ask it to check device states, control the lights, or run an existing routine. And the most logical next step is giving it access to my configuration so it can check the automations I already have.
I asked Claude Code to go through the whole config and look for mistake instead of stopping at configuration.yaml. The mistakes Claude caught are embarrassingly basic, especially for someone who already uses Home Assistant to run routines involving several devices. You can spend a lot of time figuring out how to build an automation and still overlook a simple assumption in the finished YAML.
I gave Claude the files behind my automations
The MCP connection only covers part of this
My Home Assistant’s configuration is spread across several files. configuration.yaml is the starting point, but it references separate files for automations, scripts, templates, and packages. If an automation also calls a script that contains the actual device actions, reading the automation alone doesn’t explain everything it does.
The MCP connection I already use gives Claude access to exposed entities through Home Assistant’s built-in Assist API. However, reviewing the YAML requires separate access to the files. You can provide a local copy of the relevant configuration or share the configuration directory with your computer, which lets Claude Code search through it without you pasting each file into a conversation.
I want Claude to follow those references and check how the existing configuration fits together. That includes whether an automation points to the right entity, whether its conditions match the intended behavior, and what happens when it runs again before the previous run finishes. Some of these questions require current entity information or an automation trace, which the YAML alone cannot provide.
When Claude comes up with a useful finding, it also needs to identify the relevant file and explain what the questionable line actually does. Otherwise, you get a list of suggested changes without enough information to judge them. I can then compare the explanation with Home Assistant’s documentation and review the proposed correction before changing the automation.
Some mistakes come down to a single word
Small details are easy to overlook
I often reuse an existing automation because that saves me quite a lot of work. It already has the structure, so I can change the devices and adjust the conditions instead of writing everything again. It’s also an easy way to leave an old entity ID somewhere in the YAML. You replace a sensor, update the parts you remember, and leave another reference pointing to the device you no longer use. That’s a useful job for Claude because it can search for those references across the files.
Even with the correct entity ID, you can get the state wrong. Home Assistant displays a door sensor as “Open” or “Closed,” so using open in a trigger sounds reasonable. However, that binary sensor’s actual states are on and off, so an automation waiting for "open" never gets the transition it expects. You only need to change one word, provided you check what the sensor actually reports first.
I also often miss this when testing. Click Run actions and the light switches on, which gives you a perfectly reasonable reason to think you’ve got the automation right. That button skips the trigger and top-level conditions, though.
Valid YAML can still do the wrong thing
The run mode changes what happens next
A motion-triggered light is a good example of how an automation can look correct and still behave differently from what you expect. Say you configure it to turn on the light, wait five minutes, and then turn it off. You probably want another five minutes whenever motion is detected again. However, if the automation uses the default single mode, another trigger during that delay is ignored. The original run continues, and the light switches off when its five minutes are up.
For that particular setup, restart makes more sense. A new qualifying trigger stops the current run and starts the sequence again, including the delay. You still need the sensor to report another qualifying transition, though. A sensor that stays on doesn’t produce a fresh off-to-on change just because you move around. You can change the mode to fix how the automation handles another trigger, but that doesn’t create one.
Claude Code also discovered what I was getting wrong in automations that wait for a state to remain unchanged. When you add something like for: "00:05:00", it means the state must hold for five minutes before the trigger fires. However, that wait resets if Home Assistant restarts or you reload the automations. If the routine needs to preserve a deadline through maintenance, you have to account for that separately.
Give your existing automations another look
If you already use Claude Code to write Home Assistant automations, it’s worth asking it to review the configuration you already have. Give it enough context to understand what each routine should do, because the files alone don’t explain every decision you make. Once Claude has relevant access, you'll realize you should have given your existing configuration this much attention sooner.