Home Assistant has more than 2,000 integrations. A grower approaching the integration catalog for the first time can easily feel overwhelmed — every sensor brand, every smart-home ecosystem, every cloud service, every protocol stack appears to be represented. For agricultural operations, only a fraction of these matter. The integrations that carry actual weight for a farm are a short list: the wireless protocols for sensors and actuators (BLE, Zigbee, LoRa/LoRaWAN, WiFi), the industrial protocols for connecting to real control systems (Modbus), the messaging layer that ties everything together (MQTT), the custom-device platform that turns commodity microcontrollers into any sensor or controller a grower might need (ESPHome), and the utility integrations that bring in external data and send out notifications (Weather, Notifications, Voice, AI Services). This page orients the grower to the integrations landscape, explains the tradeoffs between the main wireless protocols, and provides the framework for choosing integrations without getting lost. The sub-pages cover each integration family in depth.
What an integration is.
In Home Assistant, an integration is a piece of software that connects Home Assistant to a specific device, service, or protocol. The integration handles the specifics of communication — pairing, polling, translating data formats — and exposes the device's capabilities as Home Assistant entities that automations, dashboards, and templates can reference.
Some integrations are provided by the Home Assistant project itself (core integrations). Others come from device manufacturers, third parties, or the community. The Home Assistant Community Store (HACS) hosts community integrations that are not included in the core distribution.
How integrations appear to the grower.
When an integration is added, its devices and entities appear in Settings → Devices & Services and in the entity browser. The entities behave like any other entities — they have states, histories, and can be referenced by automations and dashboards.
Most integrations require some configuration — specifying which devices to connect to, which services to authenticate against, or which network addresses to poll. The configuration flow is typically guided through the Home Assistant interface.
The agricultural integration landscape.
Of Home Assistant's 2,000+ integrations, the ones that matter most for agricultural operations fall into several categories.
Wireless sensor protocols. BLE (Bluetooth Low Energy), Zigbee, LoRa/LoRaWAN, WiFi. These are how most sensors talk to Home Assistant. Each has a tradeoff profile — range, power consumption, scale, complexity.
Industrial control protocols. Modbus (RTU over serial, or TCP over network) is the workhorse for connecting to commercial control equipment, variable-frequency drives, industrial sensors, boiler controllers, and similar equipment. Essential for operations integrating Home Assistant with existing commercial control systems.
Messaging layer. MQTT is the pub/sub messaging protocol that ties many devices and services together. ESPHome devices use it. Zigbee2MQTT uses it. Many custom integrations use it. An operation running Home Assistant seriously ends up running an MQTT broker (Mosquitto) as part of the graybox.
Custom device platform. ESPHome compiles firmware for ESP32 and ESP8266 microcontrollers that can implement any sensor or controller a grower designs. Extends Home Assistant's reach beyond commercial devices into custom-built solutions.
Utility integrations. Weather data integrations (OpenWeatherMap, Met.no, weather.gov, local weather stations). Notification services (mobile apps, email, SMS, voice calling, team messaging). Voice interfaces (local voice assistants, cloud voice). AI services (LLM integrations, computer vision via Frigate, local AI models).
Other categories. Energy monitoring, cameras, presence detection, smart home ecosystems (not usually primary for agriculture but sometimes useful). Most of these are not the focus of this sub-section but have their own Home Assistant integrations for operations that want them.
Wireless protocol tradeoffs.
The choice of wireless protocol for sensors and actuators affects cost, range, reliability, and scale. No protocol is universally best; each fits different situations.
BLE (Bluetooth Low Energy).
Range: 30-100 feet in open space; much less through obstacles. Power: Very low. Battery-powered sensors run 1-3 years on coin cells. Scale: A typical Home Assistant host's Bluetooth adapter handles 10-30 devices reliably. With ESPHome-based BLE proxies, coverage extends and device count scales. Cost: Sensors inexpensive. Complexity: Simple. Plug and play for most sensors.
Best for: Temperature and humidity monitoring, small-to-medium operations, situations where devices are close enough to Home Assistant host, experimentation and first-deployment.
Weak for: Long-range field deployments, operations requiring hundreds of sensors distributed across a large area, situations where BLE range limitations are binding.
[Bluetooth Low Energy integration](/home-assistant/integrations/ble) covers the specifics.
Zigbee.
Range: 30-50 feet per hop; mesh networking extends the effective range substantially. Power: Low, though not as low as BLE. Battery-powered sensors typically run 1-2 years. Scale: Many hundreds of devices supported per Zigbee coordinator. The mesh topology handles large device counts well. Cost: Sensors and controllers moderate. Coordinator USB stick. Complexity: Moderate. Pairing is straightforward; managing many devices requires organization.
Best for: Medium-to-large operations with many devices distributed across a greenhouse or facility. Operations wanting wireless controllers (smart plugs, relays) in addition to sensors.
Weak for: Very long distances (LoRa better), very low-power applications (BLE wins). Some Zigbee devices have compatibility variations that require research.
[Zigbee integration](/home-assistant/integrations/zigbee) covers the specifics.
LoRa and LoRaWAN.
Range: Miles in open terrain; significant range through obstacles. Power: Very low. Battery-powered sensors can run 5-10 years on lithium batteries. Scale: Thousands of devices possible. Multi-gateway deployments cover very large areas. Cost: Gateway a moderate amount. Sensors moderate but durable industrial-grade available. Complexity: Higher than BLE or Zigbee. LoRaWAN vs. LoRa P2P choice adds complexity. Network server setup.
Best for: Outdoor field operations, multi-acre farms, remote sensor locations, operations where the communication distance is the primary constraint.
Weak for: Fast-updating sensors (LoRa duty-cycle limits reduce update frequency). High-bandwidth applications. First deployments where simpler protocols suffice.
[LoRa and LoRaWAN integration](/home-assistant/integrations/lora) covers the specifics.
WiFi.
Range: Limited to WiFi network coverage — typically 100-200 feet indoors, further with enterprise access points. Power: High. Battery-powered WiFi devices have short battery life (weeks to months). Most WiFi devices need mains power. Scale: Limited by WiFi network capacity. Commercial-grade APs handle hundreds of clients; consumer APs often strain above 20-30 active devices. Cost: Devices variable. No specialized gateway needed beyond the WiFi network. Complexity: Low for devices with vendor apps; higher for operations wanting local-only control.
Best for: Mains-powered devices in WiFi-covered areas. Smart plugs, mains-powered smart lights, specific products with WiFi-only connectivity.
Weak for: Battery-powered sensors (battery life too short). Large outdoor deployments. Dense sensor coverage.
[WiFi devices integration](/home-assistant/integrations/wifi) covers specifics.
Modbus.
Range: Wired — as far as the RS-485 run or as far as the network reaches for Modbus TCP. Power: Wired — not a concern. Scale: Many devices per RS-485 bus; unlimited effectively for Modbus TCP. Cost: Varies. Industrial sensors and controllers are often expensive but robust. Complexity: Higher. Modbus registers, function codes, and data types need understanding.
Best for: Connecting to industrial equipment that natively speaks Modbus — boiler controllers, variable-frequency drives, commercial HVAC, industrial sensors, some solar inverters.
Weak for: Consumer or DIY devices (rarely support Modbus). Wireless applications (not a wireless protocol).
[Modbus integration](/home-assistant/integrations/modbus) covers specifics.
Messaging and custom devices.
Two integrations that are almost universal in serious Home Assistant deployments, regardless of the specific devices in use.
MQTT.
MQTT (Message Queuing Telemetry Transport) is a lightweight pub/sub messaging protocol. A Home Assistant installation running ESPHome devices, Zigbee2MQTT, custom integrations, or many community add-ons ends up using MQTT as connective tissue. The MQTT broker (Mosquitto, typically) runs as part of the graybox.
For agricultural operations, MQTT enables: - ESPHome devices reporting state - Zigbee2MQTT bridging Zigbee to Home Assistant - Custom scripts or applications publishing data to Home Assistant - Home Assistant publishing state for external systems to consume - Multi-site or multi-instance federation patterns
[MQTT integration](/home-assistant/integrations/mqtt) covers the broker setup and integration patterns.
ESPHome.
ESPHome compiles firmware for ESP32 and ESP8266 microcontrollers. A grower can build a custom sensor, actuator, or controller using a little ESP32 board plus specific sensor chips or relays, write a simple YAML configuration, and have a device that integrates with Home Assistant natively.
For agricultural operations, ESPHome enables: - Custom sensors that don't exist as commercial products - Adapting commercial sensors that don't support standard protocols - Building cost-effective multi-sensor nodes - Relay and switch controllers for irrigation valves, fans, heaters, lights - BLE proxies that extend Bluetooth coverage - Integration with industrial devices through custom firmware
ESPHome is genuinely transformative for serious operations. The up-front learning curve pays off in flexibility.
[ESPHome integration](/home-assistant/integrations/esphome) covers the device-building approach.
Utility integrations.
Integrations that bring external data in or push internal data out.
Weather data.
Home Assistant integrates with multiple weather services for current conditions and forecasts. OpenWeatherMap (widely used, free tier available), Met.no (Norwegian Meteorological Institute, free), weather.gov (U.S. National Weather Service, free for U.S. operations). Local personal weather stations integrate via specific integrations (Ecowitt, Davis Instruments, and others).
For agriculture, weather data drives: - Weather-aware irrigation skip - Freeze-protection automations - Ventilation based on outdoor vs indoor conditions - Fertigation timing adjustments - Daily DLI forecasting for supplemental lighting
[Weather Data integration](/home-assistant/integrations/weather) covers the options and patterns.
Notifications.
Home Assistant supports many notification paths — the Home Assistant mobile app (push notifications), email, SMS via services like Twilio, voice calling via services like Vonage, team messaging via Slack/Discord/Teams, and others.
For agriculture, notification routing matters especially for alerts — different severity levels, different times of day, different contacts, different channels. A single notification pathway is a single point of failure.
[Notification Integrations](/home-assistant/integrations/notifications) covers routing strategies.
Voice interfaces.
Local voice assistants (running entirely on the Home Assistant host) and cloud voice assistants (Google, Amazon Alexa) both integrate. For growers in the field with their hands busy, voice commands for status checks ("what's the temperature in Greenhouse 2") can be useful.
Privacy considerations favor local voice for operations that prefer data stays on-premises. [Voice Assistants integration](/home-assistant/integrations/voice) covers the options.
AI services.
LLM integrations (OpenAI, Anthropic Claude, Google Gemini, local models via Ollama). Computer vision (Frigate with local processing, cloud vision APIs). These are covered in depth in the AI sub-section but appear here because they integrate with Home Assistant through standard integration patterns.
[AI Services integration](/home-assistant/integrations/ai-services) covers the integration specifics; the AI in Home Assistant sub-section covers specific use cases.
How to choose integrations.
The question "what integrations should I use" decomposes into several narrower questions.
What devices do I already have?
Existing hardware constrains the integration choices. Existing Bluetooth sensors → BLE integration. Existing Modbus-speaking boiler controller → Modbus integration. Existing WiFi smart plugs → vendor-specific or generic WiFi integration.
What protocols does my operation need?
Small scale and close quarters: BLE is sufficient for many operations. Large scale with many devices: Zigbee or LoRa. Connecting to industrial equipment: Modbus. Custom devices: ESPHome.
What's my tolerance for complexity?
Each additional protocol adds complexity — another system to learn, another failure mode to debug, another integration to maintain. An operation running three protocols (BLE, Zigbee, Modbus) has three learning curves. Stacking unnecessarily is a tax on the operation.
What's my failure tolerance?
Some integrations are more reliable than others. Wired (Modbus, ESPHome with Ethernet) more reliable than wireless. Local (on-premises, no cloud) more reliable than cloud (depends on internet and service uptime). Critical functions benefit from the most reliable integrations.
What's my budget?
Integration costs span a wide range. BLE sensors. Zigbee devices moderate. LoRa gateway + sensors higher up-front. Modbus-speaking industrial equipment often expensive. Budget constraints can drive integration choices as much as capability needs.
What's my future growth?
Starting small and scaling to large is easier with protocols that scale — Zigbee and LoRa both scale to many devices cleanly. Starting with BLE at small scale is fine but a transition to Zigbee or LoRa may be needed later. ESPHome scales naturally because each custom device is independent.
Common integration architectures.
A few patterns that grower deployments commonly converge on.
The BLE-plus-ESPHome hobbyist setup.
Small operation. A few BLE temperature/humidity sensors. A handful of ESPHome devices for custom sensing and relay control. MQTT broker (Mosquitto) running in the graybox. WiFi for the ESPHome devices. Modest cost, moderate capability, good foundation.
The Zigbee-plus-ESPHome growing operation.
Medium operation. A Zigbee coordinator with 30-100 Zigbee sensors and controllers across the facility. ESPHome for custom devices and specific control points. MQTT broker. Weather integration. Notifications. A representative mid-size deployment.
The multi-protocol production operation.
Larger operation. Zigbee for indoor sensing and control. LoRa for outdoor field sensors (distant locations). Modbus for the boiler controller and industrial refrigeration. ESPHome for custom equipment integration. MQTT as the messaging fabric. Multiple notification paths. Weather integration. Possibly AI services for specific use cases. Complex but each component earning its place.
The commercial augmentation operation.
Operation already has commercial control systems. Home Assistant monitors through Modbus and MQTT, provides dashboards and alerting that supplement the commercial systems, integrates with the operation's other business systems. Less about controlling and more about adding visibility and integration.
What not to do.
Don't install every integration that looks interesting. Each integration is a maintenance burden. Keep the installed set to what is actually used.
Don't choose integrations based on first-glance ease. WiFi sensors look easy (no gateway needed) but struggle at scale. BLE feels limited until the range hits. LoRa looks complex until the distance needs demand it. Match the integration to the actual need.
Don't ignore protocol scaling. An integration working fine at 5 devices may struggle at 50. Understanding the scaling characteristics of chosen protocols prevents late-stage migrations.
Don't skip MQTT for small deployments. Even a small deployment running ESPHome or Zigbee2MQTT benefits from having MQTT set up properly. It scales without rework.
Don't rely on cloud integrations for critical functions. Cloud-dependent integrations fail when the internet or the service fails. Critical monitoring and alerts should use local integrations.
Don't abandon integrations that stop being maintained. Community integrations sometimes stop receiving updates. A dead integration eventually breaks when Home Assistant's core changes. Monitoring the maintenance status of integrations in use catches issues before they become failures.
Don't mix protocols needlessly. An operation using Zigbee successfully does not need to add BLE for a few more sensors just because they came cheaper. Consistency pays off in maintenance.
The sub-pages in this section.
Each major integration gets its own detailed page in this sub-section:
[Bluetooth Low Energy](/home-assistant/integrations/ble) — BLE sensors, proxies, range extension, the pairing and discovery patterns.
[Zigbee Network](/home-assistant/integrations/zigbee) — Zigbee coordinators, device pairing, mesh network management, Zigbee2MQTT vs. native integration.
[LoRa and LoRaWAN](/home-assistant/integrations/lora) — gateways, network servers, device provisioning, range and deployment planning.
[Modbus for Industrial Control](/home-assistant/integrations/modbus) — RTU and TCP variants, register mapping, common industrial devices.
[MQTT](/home-assistant/integrations/mqtt) — Mosquitto broker setup, topic design, authentication, Home Assistant MQTT integration.
[ESPHome](/home-assistant/integrations/esphome) — device building, YAML configuration, OTA updates, agricultural applications.
[WiFi Devices](/home-assistant/integrations/wifi) — WiFi sensor and controller integration, Tasmota, local control preferences.
[Weather Data](/home-assistant/integrations/weather) — weather services, personal weather stations, forecast integration, agricultural uses.
[Notification Integrations](/home-assistant/integrations/notifications) — routing, escalation, multi-channel alerts, reliability considerations.
[Voice Assistants](/home-assistant/integrations/voice) — local voice, cloud voice, privacy considerations.
[AI Services](/home-assistant/integrations/ai-services) — LLM integrations, computer vision, the integration patterns.
Each page goes deeper than this overview and covers the specific configuration, failure modes, and agricultural applications for its integration.