The terms in here are organized by topic, not alphabetically — context makes definitions stick. Read it once before you start buying anything, and you’ll save yourself a lot of expensive confusion later. Bookmark it and come back when something in an article stops making sense.
The foundations
These are the concepts everything else builds on. If the later sections feel confusing, it’s usually because one of these isn’t solid yet.
Smart home — A home where devices can be controlled remotely or operated automatically, without manual intervention. The key word is automated. A home where you can turn on a light from your phone is convenient. A home where the lights come on when you walk in and turn off when you leave is smart. The distinction matters because it changes what you build toward.
Hub (or Controller) — The central brain of your smart home. The hub is a piece of software — sometimes hardware too — that your devices connect through. It translates commands into something your devices understand and collects their state information in one place. Without a hub, you end up with a different app for every device brand, no way to automate across them, and a setup that quickly becomes unmanageable.
Local processing — When your hub processes commands and runs automations on hardware inside your home, rather than sending that data to a company’s server somewhere on the internet. This matters more than most people realise. If your hub relies on cloud processing and the manufacturer’s servers go down — or the company goes out of business — your automations stop working even though nothing in your house has changed. Local processing means your home keeps working whether or not you have an internet connection.
Cloud-dependent — The opposite of local processing. A device or system that requires a connection to an external server to function. Many consumer smart home products are cloud-dependent by design. This isn’t always a dealbreaker, but it’s worth knowing before you buy — especially for security cameras and door locks where reliability directly matters.
Integration — A connection between your hub and a specific device or service. Integrations are what let Home Assistant talk to your lights, your weather service, your cameras, or your speakers. Each integration handles the translation layer so the hub can read device states and send commands. Integration quality varies significantly — some are official and actively maintained, others are community-built and may lag behind firmware updates. Checking integration quality before buying a device is one of the most useful habits you can build.
Bridge / Gateway — A piece of hardware that connects devices on one protocol to a hub running on another. Philips Hue uses a bridge, for example — it speaks Zigbee to the bulbs and Wi-Fi to your network. Not all ecosystems require a bridge, but many older or proprietary ones do. In general, the fewer bridges in your setup, the better. Every extra hop is another point of failure and another thing to troubleshoot.
Firmware — The software that runs on a device itself — not your hub, but the code burned into the device’s own chip. Firmware updates fix bugs, improve performance, and occasionally add features to hardware you already own. They also occasionally break integrations that were working fine. Worth knowing before you set automatic firmware updates on everything at once.
Pairing — The process of connecting a new device to your hub or coordinator for the first time. Pairing usually involves putting the device into a discovery mode so the hub can find and register it. Unpaired devices can’t be controlled. If a device won’t pair, the most common culprit is distance from the coordinator, not a broken device.
Protocols
Protocols are the languages devices use to communicate. Two devices can only talk directly if they speak the same one. This is one of the most important things to understand before buying anything — a Zigbee sensor cannot pair with a Thread hub, and a Wi-Fi plug cannot join a Zigbee network.
Zigbee — A low-power, short-range wireless protocol designed for IoT devices. Zigbee runs on the 2.4GHz band and forms a mesh network — devices with a permanent power source act as repeaters, extending range throughout the home. It’s fast, reliable, widely supported, and has one of the largest device ecosystems of any smart home protocol. If you’re building a new setup today, Zigbee is the most practical place to start. Most of the sensor and switch hardware worth buying supports it.
Zigbee coordinator / dongle — A USB device that plugs into your hub server and acts as the radio interface for your Zigbee network. Without one, your hub has no way to communicate with Zigbee devices. Common options include the Sonoff Zigbee 3.0 USB Dongle Plus and the SMLIGHT SLZB series. The coordinator is the single point of failure for your entire Zigbee network — it’s worth buying a spare and keeping it in a drawer.
Zigbee2MQTT — A software add-on that runs alongside Home Assistant and translates between your Zigbee coordinator and Home Assistant’s native format. It supports more devices than the built-in Zigbee integration (ZHA), gives you a full visual network map, and is actively maintained by a large open-source community. Most serious Home Assistant setups use Zigbee2MQTT. If you’re choosing between the two, start here.
Thread — A newer low-power mesh protocol, also on the 2.4GHz band, designed with the smart home in mind from the start. Unlike Zigbee, Thread is IP-based — every device gets its own network address, which makes communication more robust and reduces some of the pairing complexity. Thread is the transport layer that Matter runs over. It requires a border router — typically a HomePod, Apple TV, or Google Nest Hub — to connect the Thread mesh to your main network. Thread is worth understanding; it’s where the industry is heading.
Matter — A cross-platform interoperability standard built on top of Thread (and Wi-Fi). The idea is that a Matter-certified device works with any Matter-compatible hub — Apple Home, Google Home, Home Assistant, Samsung SmartThings — without needing different apps or bridges. It’s a genuinely good idea and it will matter a lot eventually. The honest assessment today: the standard is real, certification is happening, but the implementation is still patchy. Not all Matter devices work reliably across all platforms, and Home Assistant’s Matter support has rough edges. Worth understanding, worth choosing Matter-certified hardware when the price difference is minimal — but don’t plan your whole setup around what Matter promises to become.
Wi-Fi (smart devices) — Many devices — bulbs, plugs, cameras — connect directly to your Wi-Fi network rather than using a dedicated IoT protocol. This is convenient since no coordinator is required, but adds load to your wireless network, tends to be more cloud-dependent, and creates security concerns if devices aren’t properly isolated. Wi-Fi makes sense for bandwidth-hungry devices like cameras. For sensors and switches, Zigbee or Thread is usually the better choice.
Bluetooth / BLE (Bluetooth Low Energy) — Some devices use Bluetooth for local communication. BLE is power-efficient and doesn’t require a hub for basic pairing, but range is limited and HA’s Bluetooth support depends on your hub hardware having a Bluetooth radio. BLE is common in temperature sensors and presence beacons. It works, but it isn’t the protocol you’ll build your core infrastructure around.
Z-Wave — An older low-power mesh protocol that, until a few years ago, was considered a solid choice for smart home devices. Z-Wave operates on a sub-GHz band which gave it better wall penetration than 2.4GHz protocols. However, the Z-Wave Alliance’s licensing model has become increasingly restrictive and several major manufacturers have dropped or reduced their Z-Wave lines. If you have existing Z-Wave devices that work, keep using them. If you’re starting fresh, build around Zigbee or Thread instead — the ecosystem is contracting, not growing.
Networking
Smart home networking is where most setups eventually go wrong. Devices that work fine in isolation start misbehaving when you have thirty or forty of them on the same network. A few concepts here pay off significantly.
VLAN (Virtual Local Area Network) — A way to divide your physical network into separate logical networks. In smart home terms, this means creating a dedicated IoT VLAN for your devices, separate from the network your computers and phones live on. This limits the damage if a device is compromised, prevents devices from accessing your personal files, and makes traffic management easier. If your router supports VLANs — UniFi, pfSense, OPNsense, and many others do — setting up an IoT VLAN before you have too many devices to move is one of the best decisions you can make early on.
IoT VLAN — The specific VLAN dedicated to smart home and IoT devices. The typical configuration: IoT devices can reach the internet for firmware updates and cloud dependencies, but cannot initiate connections to your main network. Your hub lives on the main network or a separate management VLAN with explicit access rules. The thing that catches people: your hub needs to be able to reach the IoT VLAN to control devices. That’s a firewall allow rule you have to add manually — it won’t be there by default.
mDNS (Multicast DNS) — The protocol that lets devices discover each other by name on a local network. It’s what makes addresses like “homeassistant.local” work without manually configuring DNS. The problem: mDNS traffic doesn’t cross VLANs by default. If your hub is on one VLAN and your devices are on another, discovery will fail unless your router is configured to relay mDNS between them. This is the most common cause of “everything worked until I set up VLANs” problems.
PoE (Power over Ethernet) — A standard that allows network switches to deliver electrical power through Ethernet cables to devices that support it. Relevant for smart home setups primarily for IP cameras, access points, and some hubs and controllers. One cable does both the data and power jobs. When buying a PoE switch, check the total PoE budget in watts as well as the port count — a cheap 8-port switch with a 30W budget will run out of power quickly once you have a few cameras connected.
Mesh network — A Wi-Fi system where multiple access points work together to cover a larger area, with devices connecting to the strongest access point automatically. Relevant to smart home setups because Wi-Fi-based devices perform better with consistent coverage, and because proper mesh systems (UniFi, Omada, and similar) handle IoT VLANs and mDNS relay more reliably than consumer routers. If you’re serious about your setup, a proper mesh system is worth the investment over an ISP-provided router.
Pi-hole — A network-level DNS filter that runs on your local network and blocks requests to known ad-serving and tracking domains before they leave your network. In a smart home context, it’s also a useful monitoring tool — you can see exactly which devices are calling home to which servers. That visibility helps identify cloud-dependent devices and spot anything behaving unexpectedly.
Home Assistant
Home Assistant has its own vocabulary, and the concepts don’t map cleanly onto how most people think about devices. This section is worth reading carefully even if you think you already know what an “entity” is.
Home Assistant (HA) — The most capable open-source smart home platform available. Home Assistant runs locally on your own hardware, supports thousands of integrations, and gives you full control over your automations and data. It has a steeper learning curve than consumer platforms like Apple Home or Google Home, but the trade-off is that it doesn’t depend on any company’s continued existence, subscription model, or policy decisions. Most serious smart home setups eventually end up here.
Entity — The fundamental unit in Home Assistant. An entity is one specific thing a device can report or do — not the whole device, one piece of it. A smart socket might have entities for its on/off state, current power draw in watts, cumulative energy in kWh, Wi-Fi signal strength, and firmware version. That’s five entities for one plug. Understanding this prevents a lot of confusion when you first look at a device and see a list where you expected to see one thing.
State — The current value of an entity. A light entity has a state of “on” or “off”. A temperature sensor has a state like “21.4”. A door sensor reports “open” or “closed”. States are what automations check and what dashboards display. When something seems wrong, checking the entity’s state history is usually the fastest way to understand what actually happened and when.
Device — In Home Assistant, a device is a grouping of related entities — it roughly maps to one physical piece of hardware. A Zigbee temperature sensor is one device. It might have four entities: temperature, humidity, battery level, and link quality. The device page shows all of them together and is where you manage firmware updates for supported integrations.
Add-on — An additional piece of software that runs alongside Home Assistant OS under the Supervisor. Add-ons are separate applications — Zigbee2MQTT, the Mosquitto MQTT broker, Node-RED, ESPHome — that integrate tightly with Home Assistant but run as their own processes. Add-ons are only available on a full Home Assistant OS install, not on Container or Core installs.
HACS (Home Assistant Community Store) — A third-party app store for Home Assistant that gives you access to community-built integrations, themes, and dashboard cards that aren’t in the official store. HACS significantly expands what you can do, but it’s community-maintained code running with full access to your HA instance. Install it once you’re comfortable with the basics, not on day one.
Dashboard (Lovelace) — The Home Assistant frontend — the visual interface you use to see and control your devices. Home Assistant auto-generates a basic dashboard when you first set it up. Lovelace is the name of the dashboard editor system. Most people build custom dashboards once devices are configured. With HACS installed, custom cards significantly extend what the dashboard can display.
Helper — A virtual entity you create inside Home Assistant that doesn’t represent a physical device. Input booleans (on/off toggles), input numbers, input selects, counters, and timers are all helpers. They’re used to store state for your automations — a “guest mode” toggle, a scene selector, a counter for how many times a door has opened today. Once you start writing more complex automations, helpers become indispensable.
Automations
Most of what makes a smart home feel smart comes from automations. Every automation in Home Assistant has the same structure, and understanding it makes everything else easier.
Automation — A rule that tells Home Assistant to do something automatically when something else happens. The structure is always the same: trigger → condition (optional) → action. Learning to think in those three parts before you start clicking is the single most valuable habit you can build when starting with Home Assistant.
Trigger — The event that starts an automation. Triggers can be a state change (the front door opened), a time (every day at sunset), a numeric threshold (temperature drops below 18°C), a button press, or dozens of other events. An automation can have multiple triggers — if any of them fire, the automation runs. Getting trigger logic right is the most important part of writing a good automation.
Condition — An optional check that runs after a trigger fires but before the actions execute. If the condition isn’t met, the automation stops without doing anything. Conditions are how you add context: “turn on the lights when motion is detected, but only if it’s after sunset and nobody is already home.” Without conditions, automations fire regardless of context, which quickly becomes annoying.
Action — What the automation actually does when the trigger fires and conditions are met. Actions can control devices, send notifications, run scripts, call services, or trigger other automations. A single automation can have multiple sequential or parallel actions.
Scene — A snapshot of device states that you can apply all at once. A “movie night” scene might dim the living room lights to 20%, shift them to warm white, and turn off the kitchen lights — all in one action. Scenes are static: they capture a state and replay it. They don’t adapt based on conditions; they just set things to the values you recorded.
Script — A reusable sequence of actions that can be called from automations, dashboards, or other scripts. If you find yourself writing the same sequence of actions in multiple automations, that’s usually a sign it should be a script. Scripts can accept variables, which makes them flexible — a “set room lighting” script that accepts a brightness value and colour temperature is more useful than five separate automations with hardcoded values.
Blueprint — A pre-built automation template you can configure without writing code. Blueprints define the structure of an automation and you fill in the specifics for your setup. The HA community publishes blueprints for common use cases: motion-activated lighting with a timeout, door-left-open alerts, and so on. They’re a good starting point — but understanding the underlying trigger → condition → action structure means you’ll eventually write better automations than any blueprint can give you.
Devices and hardware
The physical side. Knowing what these terms mean before you buy anything saves you from ending up with a drawer full of hardware that doesn’t work the way you expected.
Sensor — A device that measures or detects something and reports it. Temperature, humidity, motion, door state, power consumption, air quality — these are all sensors. Sensors are the inputs of your smart home. Without good sensor data, automations are either dumb or unreliable. Investing in the right sensors — especially for presence detection — pays off in every automation you write.
Motion sensor (PIR) — A Passive Infrared sensor that detects movement by measuring changes in infrared radiation — essentially, detecting warm objects moving across its field of view. PIR sensors are cheap, widely available, and work well when people are moving. The limitation: they can’t detect a stationary person. If you sit still long enough, the sensor reports “no motion” even though you’re still in the room. This is the cause of the lights-off-while-reading problem that everyone who’s installed smart lighting has experienced at least once.
Presence sensor (mmWave) — A millimeter-wave radar sensor that detects a person regardless of movement. mmWave sensors can detect breathing, someone sitting still at a desk, a person asleep in bed. They’re more expensive than PIR sensors but solve the stationary-person problem completely. For any space where you spend time sitting or sleeping — a home office, a bedroom, a living room — a presence sensor is worth the premium.
Contact sensor — A two-part sensor that detects whether two surfaces are in contact: a small magnet and a reed switch. When together, “closed”; when separated, “open”. Used primarily on doors and windows. Contact sensors are among the cheapest and most useful sensors you can add — knowing whether a door or window is open or closed unlocks a large number of practical automations.
Smart switch — A wall switch that connects to your smart home network and can be controlled remotely or automated. Unlike smart bulbs, smart switches work with any regular bulbs — the intelligence is in the switch, not the light. This means you don’t lose network control if someone flicks the physical switch, and you don’t need to replace every bulb in the house. For most installations, smart switches are the more practical choice.
Smart plug — A plug adapter that adds remote control and usually power monitoring to any plugged-in device. Smart plugs are useful for non-smart appliances you want to include in automations, and for monitoring energy consumption at the device level. Power monitoring data can also act as a proxy for device state: if your washing machine is drawing less than 5W, it’s finished its cycle — that’s a useful automation trigger.
Smart bulb — A light bulb with built-in wireless connectivity. Smart bulbs often support colour temperature and full RGB — useful for scenes and circadian lighting. The trade-off: smart bulbs need constant power to stay connected to your network. If someone turns off the wall switch, the bulb loses power and drops offline. For smart bulbs to work reliably, the wall switch needs to stay on at all times — which means either using a smart switch configured to always supply power, or accepting that physical switches are now decoration.
Actuator — Any device that does something in the physical world in response to a command. Lights, locks, switches, valves, motorised blinds — these are all actuators. The term is used to contrast with sensors: sensors are inputs, actuators are outputs. A smart home is, at its core, a system of sensors feeding information to a hub that sends commands to actuators.
Coordinator / Dongle — The USB hardware that provides a radio interface for your Zigbee network. It plugs into your hub server and acts as the bridge between your hub software and your device mesh. Also called a stick. For Zigbee, the Sonoff Dongle Plus and the SMLIGHT SLZB-06 are the most commonly recommended options. Buy a spare. If the coordinator fails, the entire Zigbee network goes with it.
This glossary will grow over time. If you’re reading an article and hit a term that isn’t here, let me know and I’ll add it.
