LoRa is the answer when BLE and Zigbee can't reach far enough. A LoRa sensor transmits miles in open terrain, runs for years on a single lithium battery, and arrives at the Home Assistant operation through a gateway that covers an entire farm or a cluster of farms. The tradeoff — lower data rates, regulatory duty-cycle limits, and more upfront setup complexity — is worth it when the alternative is no communication at all. Outdoor field sensors, remote weather stations, livestock monitoring, multi-site monitoring, and any sensor more than a few hundred feet from the operation's main facility all fit LoRa's sweet spot. This page covers LoRa fundamentals, the distinction between raw LoRa and LoRaWAN, gateway and network server options, device provisioning, range and deployment planning for agricultural contexts, and the failure modes that affect LoRa deployments. For operations where distance is the primary communication constraint, LoRa is transformative.
LoRa vs. LoRaWAN.
These terms are often confused. They refer to different layers of the protocol stack.
LoRa (Long Range) is the physical-layer modulation technique — how the radio actually encodes bits onto the airwaves. LoRa achieves its range through chirp spread spectrum modulation, trading data rate for receiver sensitivity. The physical layer is proprietary (licensed from Semtech) but can be used in several networking configurations.
LoRaWAN is a networking layer built on top of LoRa. It defines how devices join networks, how messages are routed, how security works, and how network operators manage devices. LoRaWAN is the dominant way to use LoRa in real deployments.
LoRa P2P (point-to-point) uses the LoRa physical layer without LoRaWAN — simpler but limited. A LoRa P2P system is two or more devices talking directly without a network server, appropriate for small deployments but not scalable.
For most agricultural deployments, LoRaWAN is the appropriate choice. This page focuses on LoRaWAN; LoRa P2P gets brief mention but isn't the typical recommendation.
Why LoRa for agriculture.
Specific properties that fit agricultural contexts.
Range.
LoRa's defining property. In open terrain (line of sight or near-line-of-sight), LoRa devices communicate with gateways at distances of 5-15 km (3-10 miles). Through trees and buildings the range drops substantially but remains far better than other wireless protocols — 1-3 km through moderate obstruction is typical.
For farms, this range means a single gateway on a barn roof can cover fields, pastures, and outbuildings across hundreds of acres. Multi-site operations with gateways at each site cover even larger areas.
Battery life.
LoRa devices transmit very briefly (tens of milliseconds per message) and sleep the rest of the time. Battery life of 5-10 years is common. A lithium battery in a sensor deployed once can run for the sensor's useful life with minimal maintenance. This is dramatically better than BLE (1-3 years) or WiFi (weeks to months).
Scale.
A single LoRaWAN gateway can handle thousands of devices. Duty cycle limits reduce the practical count but the scaling is fundamentally different from BLE or Zigbee.
Infrastructure.
LoRaWAN runs on unlicensed spectrum (915 MHz in the Americas, 868 MHz in Europe). No service contract required. A farm can deploy its own private LoRaWAN network entirely on-premises.
Industrial applications.
Commercial agricultural LoRaWAN devices exist for soil moisture at depth, crop sensing, livestock tracking, water-level monitoring, gate-opening detection, tractor location, and many other applications. The ecosystem is mature enough to support production operations.
LoRa's limitations.
The tradeoffs that come with the range.
Low data rate.
LoRa sends small messages — typically 10-50 bytes of payload per transmission. Large payloads (images, high-frequency logs) are not appropriate. For sensor readings (temperature, humidity, position, state) the small payload is sufficient.
Duty cycle limits.
Regulations limit how much airtime any single device can use. In the US, the FCC imposes dwell-time limits and frequency-hopping requirements; in Europe, duty cycle is explicitly limited (often 1% per hour on some bands). The practical result: a LoRa sensor typically reports every 10-30 minutes at most, not every 10 seconds. For most agricultural sensing (slowly-changing soil moisture, weather, position) the low update frequency is fine. For rapidly-changing variables, LoRa is not appropriate.
Latency.
LoRaWAN is not real-time. Messages can have significant latency (seconds to tens of seconds). Real-time control — turning a fan on or off immediately — is not a LoRaWAN use case. Monitoring and slow control are fine.
Upfront complexity.
A LoRaWAN deployment requires a gateway, a network server, and device provisioning. BLE and Zigbee are simpler to start with. LoRaWAN's setup complexity pays off only when the range or scale requirements justify it.
Cost.
Gateways cost a moderate amount or more. Sensors cost a moderate amount each. The entry cost is higher than BLE or Zigbee, though it scales economically to many sensors once the gateway is in place.
Gateway hardware.
The gateway is the bridge between LoRa devices and the network server. Several categories of gateway hardware.
Entry-level gateways.
The Things Indoor Gateway.. Small, WiFi-connected, appropriate for small deployments.
RAK Wireless indoor gateways (RAK7268, RAK7289, etc.). a moderate amount. Higher quality than TTIG, supports both 8-channel and advanced multi-packet reception.
Dragino LG308.. Popular budget option.
Outdoor gateways.
RAK Wireless outdoor (RAK7240, RAK7249, RAK7258). a moderate amount. Weatherproof enclosures, outdoor mounting. For gateway deployment on a barn roof or tower.
Mikrotik LoRa.. Commonly used by operators who already deploy Mikrotik networking hardware.
High-density gateways.
Multi-channel professional gateways. a substantial amount+. For deployments needing to handle hundreds or thousands of devices simultaneously.
DIY gateways.
A Raspberry Pi with a LoRa concentrator card (RAK2287, SX1302-based) built into a case. a modest amount in parts. Appropriate for operations wanting hardware they control entirely, with the upside of being customizable and the downside of needing assembly and ongoing maintenance.
Gateway placement.
Height matters. A gateway mounted at 10-20 feet has substantially longer range than one at ground level. Clear line-of-sight to the deployment area is ideal; even a non-line-of-sight position gives reasonable coverage if the gateway is high.
For maximum coverage across a large operation, multi-gateway deployment provides redundancy and coverage in areas where a single gateway has weak signal. Two gateways at opposite ends of a 1,000-acre farm cover the area better than one central gateway.
Network server options.
The network server handles device joining, message routing, and coordination among gateways. Several options.
The Things Network (TTN).
Public community network. Free. Gateway operators agree to accept any TTN traffic; in return they get free access for their own devices. Covers much of populated areas through community gateways.
Pros: Free. Public infrastructure. Easy to start.
Cons: No guarantees of coverage or performance. Device data flows through community infrastructure. Not appropriate for operations with data-privacy requirements.
The Things Industries (TTI).
Commercial version of TTN. Paid service with SLAs, private networks, compliance support.
ChirpStack.
Open-source LoRaWAN network server. Runs on-premises. Free software; operator provides hardware.
Pros: Full control. Data stays on-premises. No usage costs.
Cons: Operator manages the software, handles updates, ensures availability. More upfront setup.
Helium Network.
Blockchain-based public LoRaWAN network. Pay-per-packet usage model.
Commercial cloud-hosted options.
Some commercial LoRaWAN providers offer hosted network servers with per-device or per-packet pricing. Mentioned for completeness; many agricultural operations prefer self-hosted or TTN for the control.
For agricultural deployments, the collective's observation: TTN works well for small deployments and experimentation; ChirpStack works well for production deployments wanting on-premises control; commercial options make sense for operations that need the support and don't want to run infrastructure.
Integrating LoRaWAN with Home Assistant.
LoRaWAN data reaches Home Assistant through integration patterns.
MQTT bridge.
The most common pattern. The LoRaWAN network server publishes device uplink data to MQTT topics. Home Assistant subscribes to those topics through the MQTT integration. Each LoRaWAN device becomes an MQTT device in Home Assistant.
Setup: configure the network server to publish to the operation's MQTT broker; create MQTT sensor entities in Home Assistant matching the expected topics; parse the device-specific payloads into useful sensor values.
Direct integration.
Some LoRaWAN gateways and network servers have direct Home Assistant integrations available. Less common than the MQTT bridge pattern but simpler when available.
Webhook / HTTP integration.
Network servers can POST uplink data to HTTP endpoints. Home Assistant can receive webhook data and convert to sensor values. Appropriate for some specific use cases.
Payload parsing.
LoRaWAN devices send payloads in device-specific binary formats. Decoding the payload is device-specific work — for each device model, a decoder (JavaScript function in the network server, or a template in Home Assistant) extracts values from the binary bytes.
Decoders for common devices are usually available from manufacturers or the community. Writing custom decoders for less-common devices is straightforward with some knowledge of the device's documentation.
Common LoRaWAN devices for agriculture.
Several categories of devices are widely deployed in agriculture.
Soil moisture sensors.
Devices from manufacturers like Dragino, Sensoterra, Teralytic, and many others. Typically a moderate amount per sensor. Long-lived (5+ years on battery). Provide soil moisture at one or multiple depths, often with soil temperature and sometimes EC.
For field agriculture, soil moisture sensors scattered across fields with a single LoRaWAN gateway produce the monitoring coverage that would be impossible with BLE.
Weather stations.
LoRaWAN-connected weather stations (Dragino LSE01, various commercial options) provide outdoor weather data at remote locations. a moderate amount.
Water/tank level sensors.
Ultrasonic level sensors for water tanks, cisterns, and wells. a moderate amount typically. Long battery life; appropriate for checking water supply status without visiting each tank.
Livestock monitoring.
GPS trackers for cattle, sheep, and other livestock. Various products; pricing and feature sets vary substantially. Some operations use these for grazing management and theft detection.
Gate and door sensors.
Simple open/close sensors for outbuildings, gates, and equipment enclosures. Useful for security and operational awareness at distant locations.
Temperature and humidity for outdoor applications.
Dragino, RAK, and various manufacturers produce LoRaWAN-connected temperature/humidity sensors for outdoor use. a modest amount per sensor.
Soil sensors with multiple measurements.
Professional-grade agricultural sensors measuring soil moisture, temperature, EC, pH, and other parameters. Teralytic, Sensoterra, and others. a substantial amount+ per sensor depending on capabilities.
Flow meters.
Water flow and water level sensors. Useful for irrigation monitoring at remote field locations.
Deployment planning.
LoRa deployment requires more planning than BLE or Zigbee.
Survey the coverage area.
Identify the deployment locations — where sensors will go, where the gateway(s) will be. Consider: - Line of sight between sensor locations and gateway - Obstacles (buildings, dense tree lines, terrain) - Mounting options for the gateway (buildings, towers, dedicated poles) - Power availability for the gateway (most outdoor gateways run on PoE or solar) - Network connectivity for the gateway (Ethernet, cellular, or WiFi to reach the network server)
Choose frequency band.
Regional. North America: 915 MHz (US902-928). Europe: 868 MHz (EU868). Other regions have their own bands. The gateway and devices must match the regional band.
Select network server.
As covered above — TTN for small/public, ChirpStack for self-hosted, commercial for hands-off.
Plan device provisioning.
Each LoRaWAN device has a unique identifier (DevEUI) and joins the network through either ABP (activation by personalization, keys pre-programmed) or OTAA (over the air activation, joined at first use). OTAA is more secure and common.
Provisioning involves registering the device with the network server — entering the DevEUI and relevant keys. For many devices at once, the provisioning is a data-entry exercise that's worth automating.
Test coverage before deployment.
Place a test sensor at planned deployment locations and verify it reaches the gateway reliably. Marginal locations (intermittent reception) should be reconsidered or addressed with gateway relocation or additional gateways.
LoRaWAN failure modes.
Specific problems that affect deployments.
The sensor that's out of range. Sensor was placed at a location that tested fine during the survey but became unreliable in winter when trees lost leaves (or in summer when leaves grew in). Fix: place sensors with range margin; test at worst-case conditions.
The gateway that lost network connectivity. Gateway worked fine until the operation's Internet connection became unstable, breaking the link to the network server. Sensor data collected during the outage was lost. Fix: cellular-backup gateways, local network server (ChirpStack) that doesn't depend on external connectivity.
The payload format that changed. A sensor's firmware update changed its payload format. Decoder in the network server didn't match; sensor values became garbage. Fix: monitor device firmware versions, test decoders after updates, keep version pins where possible.
The duty-cycle limit. An operator tried to poll sensors frequently (every minute) and hit the regulatory duty-cycle limit — sensors dropped messages. Fix: accept LoRaWAN's low update cadence; use a different protocol if faster updates are required.
The gateway that was too low. A gateway mounted at ground level had much worse range than expected. Repositioning to 15 feet up dramatically improved coverage. Fix: height in gateway placement.
The sensor that failed to join. Device entered OTAA join mode but never successfully joined the network. Causes: incorrect keys in the network server, regional frequency mismatch, gateway not seeing the join request. Fix: verify provisioning, check gateway logs, try device closer to gateway.
The TTN policy change. An operation built on TTN's free community network experienced policy changes that affected coverage or usage limits. Fix: understand that public networks can change; plan migration paths to private infrastructure if the operation depends on the network.
The sensor battery that lasted less than expected. Sensor battery drained much faster than the 5-year claim. Investigation: the device was transmitting more often than intended due to a configuration issue. Fix: verify reporting intervals match expectations, monitor battery levels, understand the device's specific duty cycle.
The gateway firmware that lagged. Gateway firmware was outdated; it didn't support newer LoRaWAN features some devices expected. Symptom: intermittent issues with specific devices. Fix: firmware update schedule, compatibility verification.
The network server that went down. ChirpStack service crashed; all LoRaWAN data was interrupted. Fix: service monitoring on the network server, backup, restart procedures.
What not to do.
Don't use LoRaWAN for real-time control. Latency and duty cycle limits make it inappropriate.
Don't place the gateway at ground level. Height is essential for range. Roof or tower mounting makes a substantial difference.
Don't assume devices from different manufacturers all work the same. LoRaWAN is a standard; device-specific quirks exist. Test each device type before large deployments.
Don't skip coverage testing. A survey with a test sensor saves problems. Marginal range at deployment becomes failed communication six months later.
Don't rely on public community networks for production. TTN is fine for experimentation and small deployments; production monitoring needs the predictability of private infrastructure or a commercial service with SLAs.
Don't neglect the network server maintenance. A self-hosted ChirpStack (or equivalent) needs monitoring, updates, and backups like any other production service.
Don't expect BLE or Zigbee battery life. LoRa sensors last longer; the comparison is LoRa vs "months to weeks," not LoRa vs "1-2 years."
Don't send large payloads. LoRaWAN is designed for small messages. Trying to send larger data wastes airtime and may fail outright.