BLE is the most common first integration for agricultural Home Assistant deployments. A a modest amount temperature and humidity sensor communicates with Home Assistant over Bluetooth Low Energy, the Home Assistant host's Bluetooth adapter receives the broadcasts, and within minutes the grower has real-time data flowing. BLE works well for small-to-medium operations where sensors are within 30-100 feet of the Home Assistant host (or a BLE proxy). Battery life is measured in years. Device pairing is typically automatic. The tradeoffs — limited range, single-host bottleneck without proxies, some devices requiring vendor-specific integrations — are manageable with understanding. This page covers BLE fundamentals for agricultural use, the common sensor families and their integrations, the BLE proxy pattern for range extension, and the failure modes that affect BLE deployments. The grower who has already followed [Your First Sensor](/home-assistant/getting-started/first-sensor) has the basics; this page goes deeper.
BLE fundamentals.
Bluetooth Low Energy is a variant of Bluetooth optimized for low power. A BLE sensor typically operates in advertising mode — it periodically broadcasts short data packets that any nearby receiver can pick up, without needing a connection. The receiver (Home Assistant's Bluetooth adapter) listens for these broadcasts and extracts the sensor's data.
Advertising intervals.
BLE sensors typically advertise every few seconds to every few minutes. A sensor that advertises every 10 seconds sends 8,640 broadcasts per day; a sensor that advertises every 60 seconds sends 1,440. More frequent advertising means more responsive data in Home Assistant and shorter battery life. Less frequent advertising means the opposite. Most agricultural sensors balance at 30-60 second intervals.
Connection-based vs. advertising-based.
Some BLE devices use a connection model — the receiver actively connects to the device, reads specific data, and disconnects. This provides more flexibility but uses more power and reduces the number of devices a single receiver can handle. Advertising-based devices are simpler and scale better; most agricultural sensors are advertising-based.
Range.
BLE range depends on transmit power, antenna design, and obstacles. Practical ranges: - 30 feet through a single interior wall. - 60-80 feet in open space indoors. - 100+ feet outdoors or through minimal obstructions.
Greenhouses with plastic or polycarbonate glazing pass BLE signals fairly well. Concrete walls, metal buildings, and dense foliage attenuate substantially. Real-world agricultural range often comes in at 30-50 feet through greenhouse structures.
Frequency and interference.
BLE operates in the 2.4 GHz ISM band, shared with WiFi, Zigbee, microwave ovens, and many other devices. In a dense RF environment, BLE can experience interference that manifests as missed advertisements, delayed updates, or temporary disconnections. For most agricultural environments this is not a serious issue, but operations near heavy WiFi use or in buildings with many 2.4 GHz devices may see more BLE instability.
Bluetooth hardware for Home Assistant.
Home Assistant needs access to Bluetooth hardware to receive BLE broadcasts. Several options.
Built-in Bluetooth on the host.
Most laptops have Bluetooth built in. Some mini PCs include it. Raspberry Pi 4 and 5 have it. For Ubuntu Server on a repurposed desktop that lacks Bluetooth, the hardware can be added via USB.
USB Bluetooth adapter.
A little USB Bluetooth 5.0 dongle adds Bluetooth to any Home Assistant host. Cambridge Silicon Radio (CSR)-based dongles are common and generally work; Broadcom, Realtek, and Intel-based dongles also work with varying Linux support quality. For best results, look for adapters with documented Home Assistant compatibility.
Home Assistant Yellow.
Includes Bluetooth as part of the integrated radio. One less thing to add.
BLE proxies.
ESP32-based BLE proxies (running ESPHome's Bluetooth proxy firmware) extend BLE coverage beyond the Home Assistant host. A proxy placed in a distant greenhouse receives BLE broadcasts from that area and forwards them over WiFi (or Ethernet) to Home Assistant. Proxies are inexpensive and transform what BLE can cover.
The Home Assistant Bluetooth integration.
Home Assistant's core Bluetooth integration handles most BLE devices natively. For many sensors, adding the device is a matter of enabling the Bluetooth integration and waiting — Home Assistant detects and offers to add compatible devices automatically.
Enabling the integration.
Settings → Devices & Services → Add Integration → Bluetooth. Home Assistant detects available Bluetooth hardware and enables the integration. Multiple Bluetooth adapters (built-in plus USB, for example) can be used together.
Device discovery.
Once enabled, the Bluetooth integration scans for BLE advertisements. Compatible devices appear under "Discovered" in Devices & Services. The grower clicks to add them; each device's entities are created.
For devices not automatically recognized, some BLE devices are supported by vendor-specific integrations rather than the generic Bluetooth integration. The vendor integrations often provide more complete feature coverage for their specific devices.
Common BLE sensors for agriculture.
Specific sensor families that agricultural operations use.
SensorPush.
SensorPush HT1 and HTP.xw. Industrial-feeling build quality, documented accuracy specifications, 1-2 year battery life, strong BLE signal. Native Home Assistant integration (SensorPush) works over BLE without cloud dependency. Well-regarded in agricultural contexts.
Placement considerations covered in [Your First Sensor](/home-assistant/getting-started/first-sensor) and [Understanding Sensors](/fundamentals/understanding-sensors).
Govee.
Govee produces a range of BLE sensors at consumer prices. H5075, H5100, H5179. Consumer-grade accuracy (±0.5°C, ±5% RH typical), decent battery life, good availability. Integrated through the Home Assistant Bluetooth integration (some models need the Govee BLE or GoveeHome integration for full feature coverage).
Appropriate for broad low-cost coverage when accuracy requirements are modest. Not appropriate for compliance-critical applications without calibration against a reference.
Xiaomi LYWSD03MMC and similar.
Very inexpensive Chinese-market sensors, little each through various importers. Basic LCD display, BLE advertising. Stock firmware is limited; community custom firmware (ATC firmware) substantially improves integration and feature set. For operations that already know the specific products and their limitations, these provide sensor density at minimum cost.
Appropriate for learning deployments, high-density coverage where accuracy matters less, and growers comfortable with community firmware tooling.
Aranet.
Aranet4 and Aranet2. Professional-tier sensors with documented accuracy, long battery life (5+ years on lithium), good BLE performance. Integrated through the Aranet integration in Home Assistant.
Appropriate when measurement quality and calibration traceability matter — compliance, research, or high-value crops where small measurement errors have consequences.
ThermoPro.
ThermoPro TP25, TP357, and similar. Consumer sensors sometimes used in agriculture. Mixed BLE support; some models have good Home Assistant integration and others don't.
Inkbird.
Inkbird produces BLE temperature loggers and probes primarily targeted at homebrewing and cooking but usable for some agricultural applications. Pricing variable. Home Assistant integration through the Inkbird integration or generic Bluetooth integration.
Specialized sensors.
Beyond the common temperature/humidity sensors, BLE options exist for: - Soil moisture sensors - pH sensors (rare in BLE; most are wired) - Light sensors (some commercial options) - Gas sensors including CO2 (Aranet4 being notable) - Battery-powered water flow sensors
The sensor landscape evolves quickly. Growers researching BLE sensors should check current availability and Home Assistant integration status before committing.
BLE proxies with ESPHome.
The single most important pattern for serious agricultural BLE deployments.
The problem BLE proxies solve.
A greenhouse 200 feet from the Home Assistant host is out of BLE range. Adding sensors throughout the greenhouse requires either moving the Home Assistant host (usually impractical) or extending BLE coverage.
How BLE proxies work.
An ESP32 microcontroller with ESPHome's Bluetooth proxy firmware acts as a BLE receiver at its location. Whatever BLE broadcasts the proxy receives (within its own 30-100 foot range), it forwards to Home Assistant over WiFi. From Home Assistant's perspective, the BLE data is coming in through the proxy rather than the host's own Bluetooth adapter.
Proxy hardware.
An ESP32-based board (NodeMCU-32, Wemos Lolin32, ESP32 DevKit, etc.) per board. A proxy is sometimes purpose-built and sold as an "ESP32 Bluetooth Proxy" device; other times assembled from generic ESP32 hardware. Power is typically USB (5V wall adapter).
Deployment pattern.
One proxy per distinct area where BLE coverage is needed. A small operation might have 2-3 proxies (one in each greenhouse). A larger operation might have 5-10 proxies covering different zones.
Proxies require: - WiFi coverage at the proxy location (so the proxy can reach Home Assistant) - Power (USB-C or micro-USB wall adapter) - Location choice that maximizes BLE reception of nearby sensors
The grower configures the proxy once (WiFi credentials, Home Assistant connection details) and places it. It runs continuously, forwarding BLE data.
Scaling with proxies.
The BLE proxy approach scales BLE deployments substantially. A single Home Assistant host might handle 20-30 BLE sensors directly; with proxies, the same host can handle hundreds of BLE sensors distributed across multiple proxies. Each proxy has its own ~30-device effective capacity, multiplied by the number of proxies.
Active vs. passive proxies.
ESPHome supports both passive (listen-only, receiving advertisements) and active (can connect to devices and read characteristics) proxy modes. Passive is simpler and supports more devices; active supports devices that require connections but uses more resources. Most agricultural sensors work with passive proxies.
Configuring BLE devices.
After devices are discovered and added, configuration matters for useful operation.
Renaming.
The default names Home Assistant generates are typically like `sensor.goveeh50751a2btemperature`. Rename to descriptive names following the conventions from [Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing) — `sensor.greenhouse1zonea_temperature` and similar.
Assigning to areas.
Each BLE device should be assigned to its physical area. This enables area-based queries and automation filtering.
Calibration offsets.
For sensors that read consistently high or low against a reference, Home Assistant supports calibration offsets in some integrations. Alternatively, a template sensor can apply an offset to the raw sensor value.
The offset approach: `sensor.greenhouse1zoneatemperaturecalibrated` as a template sensor that adds a known offset to `sensor.greenhouse1zoneatemperatureraw`. Automations reference the calibrated sensor; the raw sensor remains available for troubleshooting.
Battery monitoring.
Most BLE sensors report their battery level. An automation watching for battery-low conditions across all sensors — triggered when any sensor's battery drops below 20% — routes a notification to the grower. Proactive replacement beats failed-sensor troubleshooting.
Pattern: a template sensor lists all devices with battery under a threshold; an automation notifies when the list is non-empty.
BLE failure modes.
Specific problems that affect BLE deployments.
The sensor that drops out during summer. A BLE sensor in a hot greenhouse disconnects during afternoon heat spikes. Investigation reveals the sensor is physically overheating (sitting in direct sunlight with inadequate ventilation around it); the BLE radio goes into thermal protection. Fix: relocate sensor away from direct sun, add a small radiation shield.
The proxy that keeps disconnecting. A BLE proxy loses WiFi connection intermittently. Home Assistant shows the proxy and its downstream sensors as unavailable during the outages. Investigation: WiFi coverage at the proxy location is marginal; the proxy's WiFi radio is dropping. Fix: move the proxy closer to a strong WiFi access point, or add a WiFi extender.
The range that seemed fine but wasn't. A sensor placed 50 feet from the host worked during setup but became unreliable after being deployed. Investigation: the host's BLE receiver was different from the handheld device used during setup; the host's adapter has weaker reception. Fix: add a BLE proxy near the sensor's location.
The signal strength that degraded over time. A sensor that worked well at installation became unreliable months later. Investigation: the sensor's battery voltage dropped enough that its BLE transmit power reduced; the weaker signal was on the edge of range. Fix: replace battery, or position proxy closer.
The BLE traffic jam. An operation with 80 BLE sensors in a relatively small area experienced missed advertisements and delayed updates. Investigation: airtime contention in the 2.4 GHz band with heavy WiFi use and many BLE advertisements. Fix: reduce WiFi congestion (move to 5 GHz where possible), increase sensor advertising intervals (slower updates, less contention), add additional BLE proxies to split the load.
The sensor that paired but doesn't update. A Govee sensor appeared in Discovered, was added, created entities, but the entity values never changed. Investigation: the sensor's specific model required a vendor-specific integration rather than the generic Bluetooth integration. Fix: install the Govee-specific integration.
The Linux Bluetooth stack that went down. The Home Assistant host's Bluetooth adapter stopped working after a kernel update. All BLE sensors went unavailable. Investigation: a Linux kernel driver regression affected the specific USB Bluetooth adapter. Fix: kernel version pinning until a fixed driver arrives, or switching to a different adapter.
The proxy that couldn't handle all the devices. A single BLE proxy at scale became overwhelmed trying to track dozens of nearby devices. Some updates were lost. Fix: add more proxies, distribute devices across them based on physical proximity.
The sensor location that changed without the software knowing. A sensor was moved from Zone A to Zone B during a cleanup. Its readings went to the Zone A automations until the grower noticed the mismatch. Fix: physical sensor labels, sensor-move protocols that include updating Home Assistant assignments.
What not to do.
Don't rely on a single BLE adapter for large deployments. BLE proxies distribute the work and prevent the single-adapter bottleneck.
Don't place BLE sensors in direct sunlight. Thermal issues and reading inaccuracy both result.
Don't assume setup-time range equals deployment-time range. Different devices have different receivers. Test with the final deployment hardware.
Don't let battery warnings accumulate. A sensor silently depleted is an unmonitored zone. Automate battery alerts.
Don't mix BLE with heavy WiFi on the same 2.4 GHz band. Move WiFi to 5 GHz where possible. In dense deployments, air congestion affects both.
Don't ignore the signal strength readings. A sensor reporting -85 dBm or worse is on the edge; it will become unreliable. Address range before it becomes a failure.
Don't skip device labeling. A physical label on the sensor matching its Home Assistant name prevents confusion when physical maintenance happens.