# Extended OpenAI Conversation for Home Assistant service control > Extended OpenAI Conversation adds OpenAI function calls, automation creation, entity history, and external data retrieval to a Home Assistant conversation agent. It suits users who want natural-language control of exposed devices, but its service execution and custom functions require careful configuration. **jekalmin/extended_openai_conversation** — Home Assistant custom component of conversation agent. It uses OpenAI to control your devices. - Repository: https://github.com/jekalmin/extended_openai_conversation - Stars: 1,454 · Forks: 270 - Language: Python - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/jekalmin-extended-openai-conversation ## Why Extended OpenAI Conversation extends Home Assistant Assist Extended OpenAI Conversation addresses a specific gap between a language model and Home Assistant. Extended OpenAI Conversation adds function calls for Home Assistant services, automation creation, entity history, REST data, and scraped web content. Its intended users are Home Assistant operators who already manage that platform and want the model to perform more than answer a question or alter one exposed entity. The distinction between entities and services matters. An exposed entity gives the conversation agent a device or feature it can discuss and control through supported entity capabilities. A service function can pass a domain, service name, and service data to `hass.services.async_call`. That broader mechanism can also target devices and areas through `device_id` and `area_id`. This makes the component useful for multi-entity actions and other service-based workflows, while also making its configuration more consequential than a simple list of exposed devices. The component is derived from Home Assistant's OpenAI Conversation integration rather than presented as a separate conversational platform. According to the README, an API key is required, and a base URL can be supplied for OpenAI-compatible services such as Azure OpenAI, APIM, or LocalAI. It is therefore intended to sit inside Home Assistant's existing configuration and Assist interface, not to replace Home Assistant or provide a standalone assistant server. ## How OpenAI function calling reaches Home Assistant services The documented data path begins with a conversation sent through the selected Home Assistant assistant. Extended OpenAI Conversation describes available functions to the OpenAI model through function specifications. When the model decides that a function is applicable, the component processes the resulting call and can pass arguments to Home Assistant. Device awareness comes from exposing entities through Home Assistant's voice assistant exposure page, allowing the model to work with the entities the operator has selected. The built-in `execute_service` function accepts three service-level values: `domain`, `service`, and `service_data`. Within `service_data`, the documented targets are `entity_id`, `device_id`, and `area_id`. This is the core mechanism behind calls such as operating multiple entities. The README demonstrates single-entity, multiple-entity, custom notification, automation, and media examples, although most examples are linked demonstrations rather than reproducible command transcripts. Other functions extend the same model-to-component path. `add_automation` accepts an automation configuration in YAML format. `get_history` accepts entity identifiers and a time range, with optional filters for attributes and significant changes. Custom function types include `script`, `template`, `rest`, `scrape`, and `composite`. A `composite` function is documented as a sequence of functions to execute. The README does not document rollback, approval prompts, transaction behavior, or recovery if one operation succeeds and a later operation fails. The model is not given unrestricted control by default merely because function calling exists. Operators define which function specifications are sent to the model and which local implementation each one invokes. However, the README does not describe a separate confirmation or permission system for destructive service calls, so the actual safety boundary depends heavily on the functions configured and on what Home Assistant services those functions can reach. ## HACS or manual installation and Assist setup The README provides two installation routes: register the repository as a custom HACS repository, or copy the `extended_openai_conversation` folder into `/custom_components`. It does not provide a shell command for either method, so there is no command here that would need to be invented. The project declares `requires-python = ">=3.14"` in `pyproject.toml`, which is an important compatibility constraint for source-based or development installation. After installation, restart Home Assistant. In `Settings > Devices & Services`, select `Add Integration` in the bottom-right corner and follow the on-screen setup. Enter the required API key. Leave `Base Url` unchanged for the default service, or specify it when using an OpenAI-compatible server such as Azure OpenAI, APIM, or LocalAI. The wording here follows the README and does not define a default URL value. Next, open `Settings > Voice Assistants`, edit the assistant named `Home Assistant` by default, and select `Extended OpenAI Conversation` from the `Conversation agent` tab. Preparation also requires exposing entities from the Home Assistant voice assistant exposure page. The documented exposure path ends in `/expose`, matching the surrounding instruction to expose entities. Once the assistant is selected, the README's first example is a request to turn on one entity, followed by examples for multiple entities and service-based actions. The demonstrations are videos, so the exact spoken wording and response cannot be confirmed from the text. ## Function configuration choices and their operating costs Configuration options are edited from `Edit Assist`. In addition to the options inherited from OpenAI Conversation, this component documents `Attach Username`, `Maximum Function Calls Per Conversation`, and `Functions`. Enabling `Attach Username` adds the active user's name to the message payload when one is available. The README limits this behavior to conversations made through the UI or REST API. `Maximum Function Calls Per Conversation` is a direct guard against repeated model requests. The README explicitly notes that a function can sometimes be called repeatedly and enter an infinite loop. The limit applies per conversation, which is more precise than claiming that it controls a device globally or across all users. The documentation does not state the default value, how exhaustion is reported, or whether partially executed operations are reversed. Each item under `Functions` maps a `spec` to a `function`. The `spec` is passed to the chat API, while `function` identifies what the component executes. This separation means that changing the model's name or parameter description does not itself define the local action. Operators must review both halves together. The README begins a default function configuration with a specification named `execute_services`. A native `script` is a list of services to call, a `template` returns a configured value, `rest` retrieves an API endpoint, `scrape` reads website information, and `composite` executes a sequence. These functions expand what the assistant can do, but they also expand the configuration and privacy surface. REST and scraping functions can send data to external endpoints or pages, while automation and service functions can alter household state. ## History retrieval, external requests, and practical limits The built-in `get_history` function is more constrained than the general service caller. It accepts `entity_ids`, `start_time`, `end_time`, `minimal_response`, `no_attributes`, and `significant_changes_only`. According to the README, the start defaults to one day before the request, the end defaults to one day, `minimal_response` defaults to true, `no_attributes` defaults to true, and `significant_changes_only` defaults to true. The end time is described as URL encoded. Those defaults reduce returned history volume, but they do not turn history into a read-only explanation of past events. The function retrieves state records for selected entities and can include attributes when configured. Review the entity identifiers supplied to the function and the resulting history payload before enabling this in a conversation where personal activity may be inferred from device state. External data support is available through `rest` and `scrape` functions. The README says that these retrieve information from an endpoint or website, but it does not document authentication fields, response limits, caching, content filtering, or failure behavior. It also does not explain how model-generated text is validated before being passed to those functions. The repository includes example directories for component functions, functions, prompts, and skills. This component is the wrong choice when conversational service execution is unacceptable or when every device action must pass through a separate approval mechanism not documented by this project. It is also a poor fit for operators who do not want to review YAML-like automation definitions, API request functions, or model instructions. The additional features create more ways for a mistaken or undesired action to occur than a basic entity-only conversation setup. ## Comparison with Home Assistant OpenAI Conversation and maintenance status The clearest alternative is Home Assistant's built-in OpenAI Conversation integration, from which this component is derived. The difference is not simply the provider. The README identifies the built-in OpenAI Conversation integration as this component's parent. Extended OpenAI Conversation adds a configurable function layer for `hass.services.async_call`, automation creation, entity history, REST retrieval, scraping, templates, scripts, and composite sequences. A user who only needs conversational control of exposed entities may not need those additional execution paths. The trade-off is control and complexity. Direct entity exposure gives operators a recognizable list of available household objects. This component can represent service-oriented actions and retrieve information beyond current entity state, but that requires meaningful function specifications and careful mapping to local handlers. More capability does not imply better answers. For routine device control, the standard integration has a narrower operational surface. The repository is not archived, and its last push was on 2026-10-11. Recent release history includes `2.0.3` on 2026-10-11 and beta releases `3.0.0-beta12` on 2026-10-09 and `3.0.0-beta11` on 2026-09-06. The presence of beta tags means adoption may involve a version line whose compatibility expectations differ from stable releases. The repository's MIT license permits use, modification, distribution, and sublicensing subject to its notice requirements, but this is not legal advice. Upgrade cost comes from reviewing changes in integration behavior, function mappings, Home Assistant compatibility, Python requirements, and configuration files rather than only copying a new release. The README does not provide an upgrade procedure or migration notes for custom functions. A Home Assistant custom component also has to remain compatible with the host platform, so the release date alone does not establish that an upgrade is safe for a particular installation. ## Conclusion Adopt this component if you want an OpenAI conversation agent to call selected Home Assistant services or retrieve entity data. Do not adopt it if exposing broad service capabilities without reviewing the generated function definitions is acceptable risk for your household. Verify the compatible Home Assistant environment, Python 3.14 availability, exposed entity list, OpenAI-compatible endpoint configuration, and each custom function before enabling it through Assist. ## FAQ ### What is Extended OpenAI Conversation used for in Home Assistant? It is a Home Assistant conversation-agent custom component that lets an OpenAI model call exposed entities and configured functions. The documented functions can execute Home Assistant services, create automations, retrieve entity history, fetch REST data, scrape web pages, and combine actions. ### How do I install Extended OpenAI Conversation? Install it through HACS as a custom repository or copy the `extended_openai_conversation` folder into `/custom_components`, then restart Home Assistant. Add the integration with an API key, edit the Home Assistant assistant, and select the component as its conversation agent. ### What Python version does Extended OpenAI Conversation require? The repository's `pyproject.toml` declares `requires-python = ">=3.14"`. The README does not add a separate Python installation procedure. ### Does Extended OpenAI Conversation limit repeated function calls? Yes. The `Maximum Function Calls Per Conversation` option limits function calls in one conversation. The README presents it as protection against a function being called repeatedly and entering an infinite loop. ### Can Extended OpenAI Conversation retrieve Home Assistant entity history? Yes. Its `get_history` function accepts entity identifiers, a time range, and options that control attributes and significant changes. The documented defaults focus on the most recent state information over a shorter period. ## Sources - [Issues](https://github.com/jekalmin/extended_openai_conversation/issues) - [jekalmin/extended_openai_conversation on GitHub](https://github.com/jekalmin/extended_openai_conversation) - [License: MIT](https://github.com/jekalmin/extended_openai_conversation/blob/develop/LICENSE) - [README](https://github.com/jekalmin/extended_openai_conversation/blob/develop/README.md) - [Releases](https://github.com/jekalmin/extended_openai_conversation/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jekalmin-extended-openai-conversation