--- title: "Home Assistant Integration" description: "Read entity states, control devices through Home Assistant services, fire and inspect events, render templates, and query history and calendars through the Home Assistant REST API." url: https://flowrunner.ai/integrations/home-assistant date_modified: 2026-08-01T02:40:32-07:00 --- # Home Assistant [Utilities & Personal](https://flowrunner.ai/integrations/category/utilities-personal) Read entity states, control devices through Home Assistant services, fire and inspect events, render templates, and query history and calendars through the Home Assistant REST API. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 16 actions · API key · available [Home Assistant website](https://home-assistant.io/) · [Platform Documentation](https://developers.home-assistant.io/docs/api/rest/) · Capability data verified 2026-07-14 1. A schedule or an upstream signal starts the check 2. Agent reads the relevant entity with Get Entity State 3. Agent confirms the reading against the expected range or condition 4. Agent classifies whether the needed action is safe to run or physically consequential 5. Agent runs the low-risk device change with Call Service 6. Agent posts the state and the action it took to the operations channel 7. A physically consequential action, such as unlocking a door, waits for a person to confirm ## What This Integration Enables FlowRunner agents use Home Assistant to bring a physical environment into an operational workflow. An agent can read live entity states to drive conditional logic, control devices by calling Home Assistant services, fire custom events onto the event bus, render templates against live state to compute a value or a status message, and read history, logbook entries, and calendar events for reporting. What it does not do is run every device action unchecked. When an action changes the physical world in a way that carries risk, the agent runs what is safe and asks a person before it does the rest. ### Without FlowRunner **State checked by hand**: Someone opens the dashboard to read a sensor or device state **No automated response**: A reading that crosses a threshold waits for a person to notice and react **Every action treated the same**: A physical action runs on the same path as a harmless read ### With FlowRunner **State read in the workflow**: The agent reads the entity and drives the next step from its value **Low-risk actions run automatically**: A harmless device change, like adjusting a light, happens without a person **Consequential actions confirmed**: A physical action that carries risk waits for a human confirmation first ## Use Case Scenarios ### Sensor-Driven Alerting A schedule or a state change starts the flow. The agent reads a door, motion, or temperature entity with Get Entity State, compares it against the expected condition, and posts an alert to the operations channel when something is off. For a harmless response, such as turning on a light, the agent runs Call Service directly. The environment is monitored without anyone watching a dashboard. ### Trend Reporting On a schedule, the agent calls Get History for temperature and energy entities, reads the values, and records each reading into a spreadsheet for long-term trend tracking. It can render a template to produce a readable summary. The reporting stays current without manual pulls. ### Confirmed Physical Action An AI agent interprets a natural-language request that would change the physical environment, such as unlocking a door for a delivery. Reading state and computing the plan happens automatically. The unlock itself does not. The agent holds the physical action for a person to confirm, then runs Call Service once the confirmation comes back. ## Human-in-Loop Highlight When a workflow reaches an action that changes the physical world in a consequential way, such as unlocking a door, disarming an alarm, or switching off a system that people depend on, the agent does not run it on its own. It pauses and routes to the responsible person through their preferred channel: "The workflow wants to run \[service\] on \[entity\], which will \[physical effect\]. Current state: \[reading\]. Confirm the action, or hold?" The person confirms, and only then does the agent call the service. The reads and the low-risk changes keep running automatically; the actions that carry physical risk get a human first. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 16 actions ### Config and Info 3 - **Get API Status** Confirms the instance is reachable and the token is valid. Used as a connection check. - **Get Config** Returns the instance configuration. Used to read location, unit, and version details. - **Check Config** Validates the instance configuration. Used before relying on a configuration change. ### States 3 - **Get States** Returns the state of every entity. Used to read the full instance state at once. - **Get Entity State** Returns the state and attributes of one entity. Used to drive conditional logic on a specific sensor or device. - **Set State** Updates Home Assistant internal representation of an entity. Used for virtual state only; it does not talk to the physical device. ### Services 2 - **List Services** Lists the available domain and service pairs and their fields. Used to discover how to control a given device. - **Call Service** Runs a service against a target, for example turning a light on with a brightness value. Used to actually control a physical device. ### Events 2 - **List Events** Lists the event types on the event bus. Used to see what events an instance emits. - **Fire Event** Fires a custom event on the event bus. Used to trigger Home Assistant automations from an external system. ### History and Logbook 3 - **Get History** Returns state history for entities over a time range. Used for reporting and trend tracking. - **Get Logbook** Returns logbook entries over a time range. Used for a human-readable activity log. - **Get Error Log** Returns the instance error log. Used for diagnostics. ### Templates and Calendars 3 - **Render Template** Renders a Jinja2 template against live state. Used to compute a value or a human-readable status message. - **List Calendars** Lists the calendar entities. Used to discover which calendars an instance exposes. - **Get Calendar Events** Returns upcoming events from a calendar entity. Used to read a schedule into a workflow. ## Frequently Asked Questions ### What can FlowRunner do with Home Assistant? FlowRunner agents can run Get API Status, Get Config, and Check Config in Home Assistant, plus 13 more actions. ### Does connecting Home Assistant to FlowRunner require OAuth? No. Home Assistant connects to FlowRunner with an API key, no OAuth flow required. ### Can Home Assistant trigger a FlowRunner workflow automatically? Home Assistant doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Home Assistant?** This integration exposes Home Assistant to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/home-assistant. Site index: https://flowrunner.ai/llms.txt