How core works

Every integration talks to the same small set of building blocks: an event bus, a state machine, an action registry, and the configuration. They all hang off one object, hass, and they all run on one asyncio event loop. Once you know how those pieces behave, most of core stops being magic.

This part of the area is for developers who want to understand what happens under an integration, who work on core itself, or who build a client that talks to Home Assistant from the outside. For the big picture of how core, the frontend, the Supervisor, and the operating system fit together, see the Architecture area.

If you are new to core, read these three first. They explain things you run into in every integration:

1. The hass object: what hass is, and what hangs off it.
2. Async in Home Assistant: why almost everything is async, and which functions you may call from where.
3. Events and states: how things happen, and how Home Assistant remembers them.

• The hass object: the central object, and the core configuration on hass.config.
• Events: firing and listening on the event bus.
• States: the state machine and the state object.
• Actions: the action registry, calling actions, and response data.

• Async in Home Assistant: the event loop, coroutines, callbacks, and the executor.
• Thread safety: which API to use when your code runs outside the event loop.
• Blocking operations: keeping I/O out of the event loop, imports included.

• How authentication works: users, credentials, tokens, auth providers, and multi-factor modules.
• Permissions: policies, and checking them in your code.
• Authentication API: letting an app log in to a Home Assistant instance with OAuth 2.

• REST API: the HTTP endpoints under /api/.
• WebSocket API: the API the frontend uses, and how to add your own commands.
• Instance discovery: how apps find Home Assistant on the network.
• Modbus devices: libraries for Modbus devices, and sharing one connection.
• LoRaWAN devices: registering a network server, and exposing the devices on it.

• Intents: handling and firing intents.
• Built-in intents: the intents Home Assistant handles out of the box.
• Conversation API: sending text to a conversation agent and reading the response.
• Assist pipelines: running speech to text, intent recognition, and text to speech over the WebSocket API.
• LLM API: exposing tools to large language models, and building your own API.

Building a conversation agent, a speech-to-text provider, or a text-to-speech provider? Those are entities, see conversation, speech-to-text, and text-to-speech. Writing sentences so Assist understands your language is translation work: see translate voice commands.

• The #core channel on the Home Assistant Discord is the place for questions about core internals.
• Much of the voice work, like the sentences and the wake word engines, happens in the OHF-Voice organization on GitHub. The integrations themselves, like conversation and assist_pipeline, live in core.
• Proposals to change how core works start as a discussion in the architecture repository.