Understanding Entities, Devices, and Automations in Home Assistant

Quick take: Every Home Assistant setup builds on three concepts. Entities are the individual data points and controls (a temperature reading, a light switch, a door sensor). Devices group the entities from one piece of physical hardware. Automations watch entities for state changes and respond automatically. I've been running Home Assistant on a Raspberry Pi 4 for three years, and understanding these three concepts early would have saved me weeks of confusion.

Understanding how Home Assistant organizes your smart home is the foundation for everything else you'll build. Most newcomers add integrations fast and quickly hit terms like "entity", "device", and "automation" without a clear sense of what separates them. They're related but distinct, and the distinction matters when you're writing automations that work reliably and building dashboards that show the right information.

This guide covers the three core concepts: what each one does, and how they connect. Get these right and the rest of Home Assistant starts making sense.

What Is the Difference Between an Entity and a Device?

The fastest way to understand this is a concrete example. Take a Kasa P100 smart plug with energy monitoring. When you add it to Home Assistant through the Kasa integration, it shows up on your Devices page as one device named "EP25" (or whatever label you assigned in the Kasa app).

That one device exposes four separate entities:

• A switch entity for turning the plug on and off
• A sensor entity showing real-time power draw in watts
• A sensor entity showing current voltage
• A sensor entity tracking cumulative energy consumption in kWh

The device is the container. The entities are the individual things you can read or control from it. When you write an automation that turns the plug off when power draw drops below 5W (useful for detecting when a TV enters standby), you're referencing the power draw sensor entity specifically, not the device.

This separation is intentional. Devices organize and identify hardware. Entities are what automations, dashboards, and scenes actually interact with. A device by itself doesn't have a state. Its entities do. Keep that distinction clear and you'll avoid a lot of confusion in the early stages.

What Are Entities in Home Assistant?

Entities are the core unit of everything in Home Assistant. The Home Assistant developer documentation defines an entity as a representation of a single function of a device. Every entity has an entity ID in the format domain.name (like sensor.living_room_temperature), a current state value, and optional attributes that carry additional data.

The domain (the part before the dot) tells you what category the entity belongs to. The main domains you'll encounter in a typical setup:

• sensor: a measured value that changes over time (temperature, humidity, power draw, CO2 level)
• binary_sensor: a state with exactly two values (motion detected/clear, door open/closed, presence home/away)
• switch: a controllable on/off relay (smart plugs, irrigation valves, some power strips)
• light: a controllable light supporting optional brightness, color temperature, and RGB color
• climate: a device managing temperature (thermostats, heat pumps, portable AC units)
• cover: a motorized opening (garage doors, roller shades, smart blinds)
• lock: a door or padlock with state reporting and remote control
• media_player: any playback device supporting play, pause, volume, and source selection

Most integrations expose sensor and binary_sensor entities alongside the primary controllable entity. A smart thermostat might appear as a climate entity for temperature control but also expose a separate sensor entity for the current temperature reading and another for humidity. All from one physical device.

Entities are what you see in the History view. They're what you add to dashboard cards. Every automation trigger references an entity state. Every condition checks an entity's current value. Every action targets an entity through a service call. There's almost nothing useful in Home Assistant that doesn't ultimately work through entities.

How Do Devices Organize Your Hardware?

Devices exist to keep setups manageable at scale. If your home has 30 smart devices, you're looking at 90 to 150 individual entities. Without the device layer, that's just an unorganized list with no clear structure. The Devices page groups all entities from each piece of hardware together and shows you the manufacturer, model number, firmware version, integration source, and connectivity status in one place.

Why does this matter practically? Devices let you do several things that raw entity lists don't support well:

• Find all entities from one piece of hardware in a single view
• Assign a friendly name to the hardware that applies across all its entities automatically
• See when a device was last seen and whether it's currently online
• Remove all of a device's entities at once when you remove the physical hardware
• Check signal strength, battery level, and diagnostic information from one page

That last point is especially useful for troubleshooting. If a ZigBee door sensor is showing stale state readings, click through to its device page and you'll see the last update time, battery percentage, and signal quality all together. Without the device layer you'd have to check each entity attribute individually.

Devices aren't directly referenced in automations. But they're how you keep a real installation organized as it grows. A setup with 40 or 50 devices gets confusing fast without that layer to anchor everything to real hardware.

What Can Home Assistant Automations Do?

Automations are where Home Assistant earns its name. An automation is a rule that runs on its own when specific conditions are met. No tapping an app. No voice command. It just runs.

Every automation has the same three-part structure: a trigger, an optional condition, and an action. The official Home Assistant automation documentation covers the full syntax, but here's how each part actually works.

What Triggers an Automation?

The trigger is the event that starts the automation. Home Assistant supports several trigger types worth knowing:

• State trigger: fires when an entity changes from one state to another (a motion sensor going from "clear" to "detected")
• Numeric state trigger: fires when a sensor value crosses a threshold you define (indoor CO2 rising above 1000 ppm)
• Time trigger: fires at a specific clock time (6:30 AM on weekdays) or on an offset from sunrise/sunset
• Sun trigger: fires at sunrise or sunset with an optional minute offset, no manual updates needed when seasons change
• Template trigger: fires when a Jinja2 expression evaluates to true, letting you compare two entity states directly
• Device trigger: a UI-friendly wrapper for state triggers, organized by device instead of raw entity ID

State triggers and numeric state triggers handle the majority of real-world automations. Time-based triggers manage morning routines. Sunrise and sunset triggers keep lighting automations aligned with actual daylight throughout the year.

What Do Conditions Add?

Conditions are optional filters between the trigger and the action. If the trigger fires but the conditions aren't met, the automation stops. Nothing happens.

The most common use is time-of-day filtering. A motion sensor triggering lights makes sense after dark. During daylight hours, you probably don't want lights switching on every time someone walks past. Add a condition that checks whether it's after sunset and the automation becomes context-aware rather than just reactive.

Conditions can check entity state (is the TV on?), time ranges (is it between 10 PM and 7 AM?), sun position (is it currently after sunset?), and template expressions. You can combine multiple conditions with AND logic (all must pass) or OR logic (any one must pass). The practical pattern: write broad triggers, then use conditions to filter down to the right circumstances.

What Do Actions Do?

Actions define what happens when the trigger fires and all conditions pass. Calling a service is the standard action: turn on a light, send a notification to your phone, set the thermostat to 68 degrees, lock the front door. Home Assistant has service calls for every entity domain.

You can chain multiple actions in sequence and add wait steps with time delays between them. A common pattern: when motion clears, wait 5 minutes, then turn the light off. Two actions with a delay in between.

Actions can also update input helpers (virtual switches and number sliders that store values for coordinating automations), call reusable scripts, or fire custom events that other automations can respond to. They're more flexible than they look at first glance.

How Do You Create Your First Automation?

My first year with Home Assistant I used the visual editor for everything. It's the right starting point and most people underestimate how much it can handle. Go to Settings, then Automations and Scenes, then Create Automation.

The UI walks you through choosing a trigger type, picking which entity or time to watch, adding optional conditions, and defining actions. For straightforward automations, you don't need to touch YAML at all.

When does YAML become necessary? Mostly when you need template triggers or conditions that compare two entity states directly. The visual editor doesn't expose every option the underlying automation engine supports. You can switch any automation to YAML view from the three-dot menu and back again whenever you want. The two representations stay in sync.

A practical first automation to build: turn on a light when a motion sensor goes active, turn it off 5 minutes after motion clears. That's two automations, one for "detected" and one for "clear" with a delay action. Both take under 2 minutes to configure using the visual editor. That sequence covers the basics of triggers, state values, and delayed actions all in one project.

From there, adding conditions is the natural next step. Add the same motion-trigger light automation but require it to be after sunset. That's the foundation of a genuinely useful home automation rather than a toy demo.

Summary

Entities, devices, and automations are the three building blocks of every Home Assistant setup. Entities are individual state values and controls, identified by domain and name. Devices group the entities from one physical device into an organized hardware view. Automations watch for entity state changes, check conditions, and run actions in response. Understanding how these three relate makes every other part of the system approachable: dashboards reference entities, scenes target entities, scripts execute service calls on entities. Start with the entity model, use devices for organization, and build automations for everything that should run on its own.