AI Automation Suggester turns a Home Assistant snapshot into YAML

The under-automated house is the actual problem

AI Automation Suggester is a custom Home Assistant integration written in Python that reads your Home Assistant setup and proposes automations for it. The problem it targets is not a missing device but an under-automated house: every new entity multiplies the number of possible interactions, turning a smart home into a pile of manual switches and half-written YAML. The people it is for are Home Assistant users who own capable hardware but never get around to wiring it up, and who find translating an idea into a working automation block more effort than it is worth. The integration installs nothing and changes no configuration. It acts as a consultant. It collects a picture of your setup, asks a large language model to spot opportunities around energy saving, security, comfort and convenience, and hands back YAML snippets you read, adjust and paste yourself. Every result is a proposal, and the review step stays with you.

The snapshot step and why existing automations are part of it

The first stage of the pipeline is a snapshot, taken on a manual trigger or on a schedule. It gathers entities and their attributes, devices, areas, and the automations you already have. That last part matters more than it sounds. A model asked to suggest lighting automation with no idea what already exists will happily duplicate a rule you wrote last month, and it will do so with confident YAML. Feeding existing automations back into the prompt gives it something to avoid and something to build on. Scope control also lives in this stage. The snapshot can be narrowed with filters and limits, and entity selection can be randomized so consecutive runs do not settle on the same handful of devices and propose the same suggestion again. Randomized selection is a blunt instrument, since it can hide a perfectly good candidate, but it is what keeps a recurring analysis from repeating itself week after week.

One system prompt assembled from your areas and entities

The snapshot is then embedded into a system prompt that describes your particular Home Assistant installation: entities and their attributes, where devices live, what automations already exist, and what you asked for in plain language. A custom prompt field lets you bias the output toward a specific goal, and the README uses presence lighting as the example, so the model is pushed toward a theme instead of scanning for anything it can think of. Temperature is configurable across providers from 0.0 to 2.0, and the integration ships configuration options for model selection as well. This stage decides the quality of the output. A broad prompt against a large house produces generic suggestions, and no amount of parsing fixes that. Entity limits and domain filters exist precisely because a hundred entities in one snapshot exceed what a single suggestion can meaningfully cover.

OpenAI to Ollama, and the OpenAI-compatible escape hatch

Provider choice is the most flexible part of the design. The call can go to OpenAI, Azure OpenAI, Anthropic, Google, Groq, LocalAI, Ollama, Mistral, Perplexity, OpenRouter, Requesty, MiniMax, LiteLLM, or another OpenAI-compatible endpoint, which covers a long tail of hosted backends. That list matters for two different reasons. The first is cost and latency, where a local Ollama or LocalAI endpoint trades model quality for keeping entity and area names on your own network. The second is that the OpenAI-compatible route means you are not tied to the named services when a new provider appears. LiteLLM is named in the same list and is described as covering more than one hundred backends. The trade-off is that each provider returns structured output in its own way, so suggestion quality is not equal across that list, and the configuration options differ from one provider to the next.

JSON when the provider allows it, fenced YAML when it does not

Response handling is where integrations of this kind usually break, and this one is explicit about it. The integration asks providers that are capable of it for structured JSON, falls back to parsing fenced YAML when JSON does not arrive, validates the YAML it extracted, and records warnings for missing output or output that looks truncated. Validation matters because a suggestion that does not parse is worse than no suggestion at all: you paste it into Home Assistant and get an error pointing at a line the model invented. A warning about truncation is the same concern for long responses, where the tail of a YAML block can be cut off mid-trigger and still look plausible. The consequence for you is that warnings are part of the result rather than an afterthought. If the sensor shows warnings for a run, the suggestions attached to that run deserve a second look before any of them are pasted.

Notifications, sensor attributes and stored history

Output reaches you through three channels rather than one. Suggestions appear as Home Assistant persistent notifications, which is the path the README leads with and the one its screenshots show, and they are also exposed as sensor attributes for the bundled dashboard card, plus stored history that your own cards can query. The sensor attribute route is the more interesting one for anyone building their own view, because the README shows a custom dashboard card with a human-readable description beside an extracted YAML block. Persistent notifications are what make the integration usable when you have no dashboard open at all: a new device appears, the analysis runs, and the notification waits in the tray until you deal with it. Keeping the description and the raw YAML in separate attributes is deliberate, since a card can show a summary while still exposing the block you need to copy.

Installing a HACS custom integration, and what the repo expects of contributors

The project ships as a HACS custom integration. The repository root holds custom_components/, hacs.json and a docs/ directory, and the README carries the HACS custom repository badge, so the install path runs through adding this repository as a custom source in HACS and pulling the integration from there. The README does not publish a pip install command, and for a Home Assistant custom integration that is not an omission, since the code is loaded from custom_components/ instead of being installed into a Python environment. For contributors the Python side is described in requirements.txt and pyproject.toml, with pytest pointed at a tests/ directory and the repository root on the import path. The same checkout you load as an integration also carries a test suite. The linting configuration below shows the project targets Python 3.9 and uses ruff with a 120 character line length.

[tool.pytest.ini_options]
testpaths = ["tests"]
pythonpath = ["."]

[tool.ruff]
line-length = 120
target-version = "py39"

[tool.ruff.lint]
select = ["E", "F", "I", "UP", "B"]
ignore = ["E501", "UP007", "UP045"]

Recent releases, a permissive licence, a small dependency list

Activity on this repository is recent. The last push was on 2026-10-02, and the release history shows v1.6.2 on 2026-10-02, v1.6.1 on 2026-09-26 and v1.6.0 on 2026-09-05, so releases are shipping close together. The repository is not archived. The licence is MIT, which is permissive: the code can be read, modified and redistributed with attribution and with no warranty attached. That is worth knowing for a component that sits inside a system you already run and has access to your entity list, and MIT does not require you to keep modifications private or hand them back. The runtime dependency list is short, covering aiohttp, anyio, pyyaml and voluptuous, with pytest, pytest-cov and ruff for development, which keeps the footprint modest for something running inside Home Assistant.

Editorial conclusion

Home Assistant users with a long entity list who want a starting point for automations will get real value from AI Automation Suggester, especially if they already point it at a local Ollama or LiteLLM endpoint and care about keeping device names off a hosted API. Users who expect suggestions to be applied without review, or who need YAML that is correct on the first paste, will not get that from this project. Before adopting it, check the provider you plan to use, the entity filters and limits, and whether your Home Assistant setup accepts the integration from HACS, then run a single analysis and read the warnings attached to that run.

Frequently asked questions

Official sources

1. Issues
2. ITSpecialist111/ai_automation_suggester on GitHub
3. License: MIT
4. README
5. Releases