TL;DR
A LoRaWAN wireless temperature and humidity sensor is a battery-powered IoT device that measures environmental conditions and transmits small data packets over long distances — up to 15 km outdoors — to a LoRaWAN gateway, which forwards the data to a cloud application.
Inside the sensor: a capacitive or resistive humidity sensing element + a thermistor or RTD temperature probe + a low-power microcontroller + a LoRa radio chip (typically SX1261 or SX1262) + a lithium battery.
How it sends data: The sensor wakes from deep sleep on a configurable interval (typically every 5–60 minutes), samples the sensing elements, encodes the readings into a compact binary payload (as few as 4–11 bytes), transmits the payload to the nearest LoRaWAN gateway using chirp spread spectrum radio, then immediately returns to deep sleep. The entire active cycle takes 50–1,500 ms. The rest of the time — 99%+ — the sensor draws microamps in sleep mode. This is why battery life of 5–10 years is achievable.
How the network works: Before sending data, the sensor authenticates with the LoRaWAN network using OTAA (Over-the-Air Activation), exchanging encrypted session keys with the network server. Every subsequent uplink is encrypted with AES-128. The gateway receives the packet, forwards it over IP to the network server, which decodes the payload and delivers clean JSON (temperature in °C, humidity in %RH) to your application.
Where it is used: Cold chain logistics, pharmaceutical storage, industrial process monitoring, warehouse management, smart agriculture, HVAC control, and data centre environmental monitoring.
How a LoRaWAN Wireless Temperature and Humidity Sensor Works ?
Most product pages for LoRaWAN temperature and humidity sensors tell you what the sensor does. This guide explains how it does it — from the polymer film that changes electrical capacitance as moisture is absorbed, to the binary payload that travels over sub-GHz radio to a gateway two kilometres away, to the JSON object that triggers an alert on your monitoring dashboard.
If you are evaluating these sensors for an industrial project, specifying them for a procurement team, or trying to understand what you are actually buying before you order, this is the guide you need.
What Is a LoRaWAN Wireless Temperature and Humidity Sensor?
A LoRaWAN temperature and humidity sensor is a self-contained wireless IoT end node that performs three functions simultaneously:
- Measures ambient or process temperature and relative humidity using calibrated electronic sensing elements
- Encodes those measurements into a compact binary data packet
- Transmits that packet over LoRaWAN radio to a gateway, from where it travels to a cloud application or local server
The defining characteristic that separates a LoRaWAN sensor from a Wi-Fi sensor or a Bluetooth sensor is the combination of long range and ultra-low power consumption. A LoRaWAN sensor can transmit data from inside a cold room, through a concrete wall, across a warehouse yard, to a gateway mounted on the facility roof — while running on a single battery for five to ten years, with no SIM card, no Wi-Fi password, and no local network infrastructure needed at the sensor location.
This combination makes it uniquely suited to industrial and large-scale commercial monitoring applications where wired sensors are impractical and conventional wireless protocols cannot cover the distance or the battery life requirement.
Inside the Sensor: The Four Core Hardware Components
Every LoRaWAN temperature and humidity sensor, regardless of manufacturer or form factor, is built around four hardware subsystems. Understanding what each does explains both the capabilities and the limitations of the device.
1. The Sensing Elements
The sensor contains two separate physical measurement elements — one for temperature, one for humidity. They operate on different physical principles and have different accuracy characteristics.
Temperature Sensing Element
Industrial and commercial LoRaWAN temperature sensors use one of three sensing technologies:
NTC Thermistor (Negative Temperature Coefficient): The most common in cost-effective sensors. A thermistor is a semiconductor resistor whose electrical resistance changes predictably with temperature. As temperature rises, resistance falls (hence "negative temperature coefficient"). The microcontroller applies a small known voltage across the thermistor, measures the resulting current, calculates resistance, and looks up the corresponding temperature from a calibration curve stored in firmware.
Typical accuracy: ±0.3°C to ±0.5°C over the operating range. NTC thermistors are inexpensive, robust, and well-suited to the −40°C to +85°C range covering most industrial monitoring applications.
RTD (Resistance Temperature Detector — PT100/PT1000): Used in higher-accuracy industrial sensors. A PT100 RTD uses a platinum element with a precisely defined resistance of 100 Ω at 0°C. Platinum's resistance increases linearly and predictably with temperature — far more accurately than an NTC thermistor. PT100/PT1000 sensors achieve accuracy of ±0.1°C to ±0.3°C and are used where process accuracy matters: pharmaceutical cold chain, food safety compliance, laboratory monitoring.
PT100 sensors are also the standard interface for many legacy RS485/Modbus instruments — meaning an RS485-to-LoRaWAN converter can bridge an existing wired PT100 sensor to a LoRaWAN network without replacing the sensing element at all.
Thermocouple (Type K, J, T, etc.): Used for extreme temperature ranges. A thermocouple is two dissimilar metal wires joined at one end — the "hot junction" — with the other ends connected to the measurement circuit — the "cold junction." The voltage generated at the hot junction (the Seebeck effect) is proportional to the temperature difference between hot and cold junctions. Type K thermocouples cover −200°C to +1,260°C, making them suitable for high-temperature industrial processes (motors, turbines, kilns, exhaust monitoring) where thermistors and RTDs cannot operate.
Humidity Sensing Element
Humidity measurement in LoRaWAN sensors is almost universally achieved using capacitive relative humidity sensing, with resistive sensing used in some lower-cost variants.
Capacitive Humidity Sensor: This is the technology used in the Sensirion SHT31, SHT40, and similar sensing ICs found in most quality LoRaWAN sensors (Dragino LHT65, Milesight EM300-TH, and others). The element consists of a hygroscopic polymer film — a moisture-absorbing material — sandwiched between two metal electrodes, forming a capacitor.
As the relative humidity of the surrounding air changes, the polymer film absorbs or releases water molecules. This changes the dielectric constant of the material between the electrodes, which directly changes the capacitance of the element. The ADC in the microcontroller measures this capacitance change, and firmware converts it to a relative humidity percentage using a calibration lookup.
Capacitive sensors offer: typical accuracy of ±2–3% RH, full-range measurement from 0–100% RH, good long-term stability, and low hysteresis (the reading is the same whether humidity is rising or falling). They are the standard choice for all precision and industrial applications.
Resistive Humidity Sensor: Uses a hygroscopic salt or conductive polymer whose electrical resistance changes with humidity. Less expensive than capacitive but less accurate, more susceptible to hysteresis, and shorter-lived in condensing environments. Encountered in low-cost consumer devices; rarely in industrial-grade LoRaWAN sensors.
Dew Point — Derived, Not Directly Measured
Dew point is not directly measured by most sensors. It is calculated from the temperature and relative humidity readings using the Magnus formula or similar approximations. Most network server payload decoders or application-layer software perform this calculation. If dew point monitoring is critical for your application, verify whether the sensor computes it on-device or requires the application to calculate it.
2. The Microcontroller (MCU) and ADC
The microcontroller is the brain of the sensor. It coordinates every function: waking on the programmed interval, powering the sensing elements, reading the ADC, encoding the payload, commanding the LoRa radio, managing receive windows, and returning to deep sleep.
In most LoRaWAN sensors, the MCU is a low-power ARM Cortex-M0+ or similar ultra-low-power processor — STM32L series and Nordic nRF52/nRF54 series are widely used across commercial devices. Power consumption in active mode is in the milliamp range; in deep sleep, it falls to 1–10 microamps.
The MCU includes or is paired with an ADC (Analogue-to-Digital Converter) that reads the analogue output of the sensing elements and converts it to a digital value the firmware can process. Modern temperature/humidity ICs like the SHT31 integrate their own ADC and deliver pre-converted digital output directly over I²C — simplifying the MCU's job and improving measurement accuracy, since the analogue path is kept short inside the sensor IC.
Firmware responsibilities:
- Reading sensing elements and applying calibration offsets
- Encoding measurements into the uplink payload byte structure
- Managing the LoRaWAN stack: OTAA join, uplink scheduling, duty cycle compliance, downlink processing
- Implementing the deep sleep / wake cycle
- Managing configurable parameters: uplink interval, alert thresholds, spreading factor override
- Processing downlink commands from the network server (reconfiguration, alert threshold changes)
3. The LoRa Radio Chip
The LoRa radio chip is what makes the sensor a LoRaWAN device. It is the component responsible for modulating the sensor's data payload onto the sub-GHz radio signal using chirp spread spectrum (CSS) modulation, and transmitting it to the gateway.
Common LoRa radio chips:
| Chip | Manufacturer | Frequency | Key Features |
|---|---|---|---|
| SX1261 | Semtech | EU868 / IN865 / AS923 | Up to +15 dBm TX power; ultra-low RX current |
| SX1262 | Semtech | US915 / AU915 / all bands | Up to +22 dBm TX power; longer range |
| LLCC68 | Semtech | Sub-GHz LPWAN | Lower cost; reduced SF range |
The SX1261/SX1262 family dominates current-generation LoRaWAN sensors. The SX1262 is particularly common in devices intended for global deployment due to its higher output power and compatibility with all major regional frequency plans.
How chirp spread spectrum works (simplified):
Instead of transmitting a fixed-frequency carrier, the LoRa radio transmits a signal whose frequency sweeps linearly across a defined bandwidth — a "chirp." The spreading factor (SF7–SF12) determines how many chirps encode one symbol: higher SF means more chirps per symbol, slower data rate, and significantly better receiver sensitivity. An SF12 signal can be decoded 20 dB below the noise floor — a level of sensitivity unachievable by Wi-Fi or Bluetooth radios.
This is why LoRaWAN can transmit through concrete walls, across factory yards, and into basement environments where no other low-power radio protocol can reliably communicate.
4. The Power System
Battery selection and power architecture are what make multi-year operation possible.
Battery chemistry:
| Chemistry | Typical Capacity | Temperature Range | Self-Discharge | Best For |
|---|---|---|---|---|
| Li-SOCl₂ (Lithium Thionyl Chloride) | 2,400–19,000 mAh | −60°C to +85°C | <1% per year | Industrial; extreme temperature; long life |
| Li-MnO₂ (CR123A, CR2032) | 1,200–1,500 mAh | −40°C to +60°C | ~1% per year | Standard commercial sensors |
| Li-ion rechargeable | 1,000–3,000 mAh | −20°C to +60°C | 2–5% per year2–5% per year | Solar/USB rechargeable variants |
| Alkaline (AA/AAA) | 2,500–3,000 mAh | 0°C to +50°C | 2–3% per year | Not recommended for industrial; poor cold performance |
For cold chain and refrigerated environment deployment — the most demanding use case — Li-SOCl₂ batteries are mandatory. Alkaline and standard lithium batteries lose capacity rapidly below 0°C. A Li-SOCl₂ cell rated at 19,000 mAh at 20°C will deliver approximately 70–80% of that capacity at −20°C; an alkaline cell in the same conditions delivers less than 20%.
The deep sleep power cycle — why battery life figures are achievable:
A LoRaWAN Class A sensor running on a 30-minute uplink interval has the following approximate duty cycle:
| Phase | Duration | Current Draw (typical) |
|---|---|---|
| Wake + MCU boot | ~5 ms | ~3 mA |
| Sensor measurement | ~10–50 ms | ~1–3 mA |
| Payload encoding | ~2 ms | ~3 mA |
| LoRa transmission (SF7, 11 bytes) | ~56 ms | ~20–40 mA |
| LoRa transmission (SF12, 11 bytes) | ~1,483 ms | ~20–40 mA |
| RX Window 1 + RX Window 2 | ~2 × 1,000 ms | ~5–8 mA |
| Return to deep sleep | ~2 ms | — |
| Deep sleep (remainder of 30-min cycle) | ~1,770 s | ~1–5 µA |
The total energy consumed per 30-minute cycle at SF7 is dominated almost entirely by the transmit and receive windows — roughly 100–200 µJ — while deep sleep contributes very little despite lasting 99.7% of the cycle. Across a year, 17,520 cycles at this rate consume energy well within the capacity of a 2,400 mAh Li-SOCl₂ cell, even accounting for battery aging and temperature derating.
This is why the same physics that limits LoRaWAN data rate also delivers its battery life: short, infrequent transmissions of small payloads are inherently energy-efficient.
Important: Battery life claims of "10 years" assume specific conditions — low transmission frequency (often once per hour or less), SF7–SF9, moderate temperatures, and no confirmed uplinks. Every application layer decision that increases duty cycle — shorter reporting intervals, confirmed uplinks, SF12 on all devices — reduces battery life proportionally. Validate battery life estimates against your actual uplink frequency and environmental conditions, not the datasheet headline figure.
How the Sensing Elements Are Read: From Physics to Digital Value
The measurement chain from physical phenomenon to digital reading involves four steps:
Step 1 — Physical change: Temperature change alters thermistor resistance. Humidity change alters capacitor dielectric constant. These are passive, continuous, analogue phenomena.
Step 2 — Electrical measurement: The MCU or integrated sensor IC applies a reference voltage and measures the resulting electrical signal — resistance for temperature, capacitance for humidity. In modern digital sensor ICs (SHT31, SHT40, HDC2080), this measurement and conversion is performed internally on the sensor chip and delivered digitally over I²C. In simpler designs, the MCU reads an analogue voltage directly.
Step 3 — ADC conversion: If the sensor output is analogue, the MCU's onboard ADC samples the voltage and produces a digital count (e.g., a 12-bit value from 0 to 4095). The firmware maps this count to a physical value using a transfer function stored during factory calibration.
Step 4 — Calibration and compensation: Raw sensor readings are not the final values. Calibration constants stored in the sensor IC's non-volatile memory are applied to correct for manufacturing variation. Temperature compensation is applied to humidity readings — because the dielectric constant of the polymer film is temperature-dependent, the humidity reading must be corrected for the concurrent temperature measurement. High-quality sensors like the SHT31 perform this compensation internally; the value the MCU reads is already corrected and ready for transmission.
The result: two clean numbers — temperature in 0.01°C resolution, relative humidity in 0.01% RH resolution — ready to be encoded into the uplink payload.
The Full Data Journey: From Measurement to Dashboard
This is the complete end-to-end sequence of what happens between the sensor sampling the air and the alert appearing on your monitoring dashboard. No competing documentation on the open web covers this entire path in one place.
Stage 1 — Device Wakes From Deep Sleep
The MCU's internal real-time clock or watchdog timer fires after the programmed uplink interval (default: commonly 10, 20, or 30 minutes depending on manufacturer). The MCU exits deep sleep, the main clock starts, and the power management IC enables voltage rails to the sensing elements and LoRa radio.
Stage 2 — Sensor Measurement
The MCU commands the temperature/humidity IC (e.g., SHT31) via I²C to take a measurement. The IC performs an internal measurement cycle (5–16 ms typical), applies internal calibration and temperature compensation, and returns a 32-bit result over I²C: 16 bits for temperature, 16 bits for humidity. The MCU stores these values in RAM.
Stage 3 — Payload Encoding
The MCU firmware encodes the measurement values into a compact byte array — the uplink payload. LoRaWAN payloads are small by design: 11 bytes is typical for a temperature + humidity + battery status packet.
The raw numbers are encoded as integers scaled by a factor (×10 or ×100) to avoid floating point — LoRaWAN payloads carry bytes, not decimal numbers. The decoder at the application layer reverses the scaling to recover the original readings.
Stage 4 — OTAA Network Join (First Transmission Only)
Before the sensor can send its first real data uplink, it must authenticate with the LoRaWAN network. This is the OTAA (Over-the-Air Activation) join procedure.
Every LoRaWAN sensor ships from the factory with three permanent identifiers printed on a sticker:
- DevEUI — 64-bit globally unique device identifier (like a MAC address)
- JoinEUI (AppEUI) — 64-bit application/join server identifier
- AppKey — 128-bit root encryption key (secret; must not be shared)
The join procedure:
- JoinRequest: The sensor transmits a JoinRequest message containing its DevEUI and JoinEUI, plus an encrypted Message Integrity Code derived from the AppKey. This message is unencrypted (the receiving gateway does not need to decrypt it) but is cryptographically authenticated.
- JoinAccept: The join server (part of the network server or a separate service) verifies the DevEUI and validates the MIC using the stored AppKey. If valid, it responds with a JoinAccept message containing a DevAddr (32-bit network address), network session key (NwkSKey), and application session key (AppSKey).
- Session keys derived: Both the network server and the sensor independently derive NwkSKey and AppSKey from the AppKey and random nonces. Neither key is transmitted over the air — they are derived identically on both sides from shared secrets. This is the cryptographic security foundation of LoRaWAN.
- Session established: The sensor now has a DevAddr, NwkSKey, and AppSKey. All subsequent uplinks use DevAddr as the network address, NwkSKey for network-layer MIC verification, and AppSKey for application-layer payload encryption.
OTAA vs ABP:
Some older or simplified deployments use ABP (Activation By Personalisation), where the DevAddr, NwkSKey, and AppSKey are hardcoded into the device at manufacture — no join procedure is required. ABP is simpler to configure but less secure (keys are fixed and cannot be rotated) and loses frame counter state on power cycle (a significant security vulnerability). OTAA is the correct choice for all production deployments.
Stage 5 — Uplink Transmission
With a valid network session, the sensor constructs a LoRaWAN MAC frame:
The payload is encrypted using AES-128-CTR with the AppSKey. The MIC (Message Integrity Code) is calculated over the entire frame using the NwkSKey. The LoRa radio transmits this frame on one of the configured uplink channels, at the configured spreading factor and bandwidth.
The transmission is unacknowledged by default (Class A unconfirmed uplink) — the sensor fires the packet and proceeds directly to the receive window, not waiting for a gateway to confirm reception. This keeps time-on-air short and battery consumption low. Confirmed uplinks (where the network acknowledges each packet) are available but significantly increase energy consumption and duty cycle usage.
Stage 6 — Gateway Reception and Forwarding
One or more LoRaWAN gateways in range receive the uplink packet. The gateway does not decrypt the payload — it is a transparent forwarder. It adds metadata: RSSI, SNR, channel, spreading factor, timestamp, and its own gateway ID. It then forwards the complete packet over IP to the LoRaWAN network server via its backhaul connection (Ethernet, cellular, or Wi-Fi).
If multiple gateways receive the same uplink (common in well-deployed networks), the network server receives multiple copies with different metadata. It deduplicates them, uses the best copy for decoding, and retains the multi-gateway metadata for geolocation if needed.
Stage 7 — Network Server Processing
The network server (The Things Stack, ChirpStack, AWS IoT Core for LoRaWAN, or similar) performs:
- Device lookup: Identifies the device from DevAddr
- Frame counter validation: Verifies the FCnt has not been replayed (replay attack prevention)
- MIC verification: Validates the frame's integrity using the stored NwkSKey
- Payload decryption: Decrypts the application payload using the stored AppSKey
- ADR processing: Records RSSI/SNR for Adaptive Data Rate decisions
- Downlink scheduling: Queues any pending downlink commands (configuration changes, threshold updates) for the next receive window
The decrypted raw payload is now a hex byte string — e.g., 0B45 0C40 02BC 01 0CD6 00 — which is human-unreadable without a decoder.
Stage 8 — Payload Decoding
The network server applies a payload formatter — a small JavaScript or similar function that maps the raw byte array to named, typed values. This is a critical configuration step that many deployments miss or delay.
Example decoder for a Dragino-compatible device (simplified):
Output after decoding:
This clean JSON is what flows to the application layer via MQTT, HTTP webhook, or direct API integration.
Stage 9 — Application Layer: Storage, Visualisation, and Alerting
The decoded JSON arrives at the application platform — which may be a vendor dashboard, a custom IoT platform (Grafana + InfluxDB, Node-RED, ThingsBoard), or a SCADA integration. Here:
- Readings are stored in a time-series database
- Historical trends are visualised on dashboards
- Alert rules evaluate each reading: if
temperature > 8°CANDzone == "vaccine_fridge", trigger an alert via email, SMS, or webhook - Compliance reports are generated for HACCP, GDP, or internal quality audits
The sensor itself knows none of this. It transmitted 11 bytes of encrypted binary data and returned to sleep.
OTAA Join in Practice: What Happens When You First Power On a LoRaWAN Sensor
When you peel the battery tab on a new LoRaWAN temperature sensor for the first time, this is the exact sequence:
- Deep sleep exit: MCU boots; LoRa radio initialises
- LED indicator (if present): Most sensors flash a status LED during join — typically 1 second ON / 1 second OFF for the first 60 seconds
- JoinRequest transmitted: Sensor broadcasts JoinRequest on a random channel. If no gateway is in range, it retries on a different channel after a back-off delay. Without gateway coverage, it will never connect — this is the most common first-deployment failure mode
- JoinAccept received: If a gateway hears the JoinRequest and the network server validates the AppKey, JoinAccept is sent in the RX1 receive window (1 second after the uplink) or RX2 (2 seconds after)
- Session established: Keys derived; device registers as "connected" on the network server dashboard
- First data uplink: Sensor sends its first measurement uplink immediately after join confirmation
- Normal operation: Subsequent uplinks follow the configured interval
Common first-time failure: The most frequent cause of a sensor never appearing in the network server is wrong OTAA keys — DevEUI, JoinEUI, or AppKey entered incorrectly in the network server registration. Always copy these from the physical sticker or QR code on the device, not from memory or a spreadsheet that may have been reformatted.
Key Specifications to Evaluate Before Buying
Not all LoRaWAN temperature and humidity sensors are equivalent. These are the specifications that actually determine whether a device is fit for your application.
Temperature Measurement Range and Accuracy :
| Specification | Economy Grade | Industrial Grade | High-Precision Industrial |
|---|---|---|---|
| Range | −20°C to +60°C | −40°C to +85°C | −40°C to +125°C (probe) |
| Accuracy | ±1.0°C | ±0.3–0.5°C | ±0.1–0.3°C |
| Resolution | 0.1°C | 0.01°C | 0.01°C |
| Typical sensing element | NTC thermistor | NTC thermistor / RTD | PT100/PT1000 or thermocouple |
| Suitable for | Office / building monitoring | Industrial, cold chain, agriculture | Pharmaceutical, laboratory, high-temperature process |
For pharmaceutical cold chain (2°C–8°C storage), a ±1.0°C sensor is inadequate — an excursion of 1.5°C above the upper limit could be missed entirely within measurement uncertainty. Use ±0.3°C or better.
For HVAC comfort monitoring in an office, ±1.0°C is perfectly acceptable and does not justify the cost premium of a PT100 sensor.
Humidity Measurement Range and Accuracy :
| Specification | Economy Grade | Industrial Grade |
|---|---|---|
| Range | 0–95% RH (non-condensing) | 0–100% RH |
| Accuracy | ±5% RH | ±2–3% RH |
| Condensing environment | Not rated | Rated (with appropriate IP enclosure) |
For cold chain and refrigeration applications, the sensor will frequently encounter near-100% RH and potential condensation. Verify the sensor and its enclosure are rated for condensing environments — most economy sensors explicitly exclude condensing conditions.
IP Protection Rating
The IP (Ingress Protection) rating defines how well the enclosure protects the sensor electronics from dust and moisture.
| IP Rating | Dust Protection | Moisture Protection | Typical Application |
|---|---|---|---|
| IP20 | No protection beyond 12.5 mm | No protection | Indoor office use only |
| IP54 | Dust limited | Splash protected | Indoor industrial (dry) |
| IP65 | Fully dust-tight | Jet water protected | Outdoor; warehouse; general industrial |
| IP67 | Fully dust-tight | 1 m immersion, 30 min | Harsh outdoor; refrigeration; washdown areas |
| IP68 | Fully dust-tight | Continuous submersion (depth specified) | Buried; permanently wet environments |
For any outdoor deployment, food processing facility, refrigerated warehouse, or environment subject to cleaning with water jets, IP65 is the minimum — IP67 is strongly preferred.
Note that the IP rating of the sensor body is separate from the probe or external sensing element. A sensor with an IP67 body and an unrated external probe is only as weatherproof as its weakest component.
Battery Life
Battery life figures in datasheets are calculated under specific assumptions that may not match your deployment:
- Uplink interval: Longer intervals = longer battery life. A sensor set to 30-minute intervals uses twice the energy per day as one set to 60-minute intervals.
- Spreading factor: SF12 transmissions use approximately 26× the energy per packet compared to SF7. A device locked to SF12 (typically from poor placement forcing long-range modulation) will exhaust its battery in a fraction of the datasheet life.
- Confirmed uplinks: Requesting acknowledgement from the network for every packet doubles or triples energy per transmission.
- Temperature: Battery capacity falls at low temperatures. A sensor rated for 5 years at 20°C may last 2–3 years in a −20°C freezer environment, depending on battery chemistry.
The right way to read a battery life claim: Ask the manufacturer what uplink interval and spreading factor were assumed in the calculation. If they assumed SF7 and 60-minute intervals for a "10-year" claim, expect significantly shorter life in a dense urban environment where SF9–SF12 is required.
Probe Type and External Sensor Interface
Many LoRaWAN temperature sensors support external probes in addition to the built-in element:
| Probe Type | Temperature Range | Best Application |
|---|---|---|
| NTC probe (waterproof) | −40°C to +80°C | Cold rooms, soil, pipe surface |
| PT100 probe | −50°C to +200°C | Industrial process; boiler rooms; HVAC ducts |
| Thermocouple (Type K) | −200°C to +1,260°C | High-temperature industrial process |
| 4–20 mA loop input | Depends on connected sensor | Legacy industrial instrumentation bridging |
If your application involves monitoring an existing wired temperature sensor (PT100, thermocouple, 4–20 mA transmitter), look for sensors that accept external inputs — or consider an RS485-to-LoRaWAN converter that can bridge existing Modbus RTU temperature instruments directly to the LoRaWAN network without replacing the sensing hardware at all.
LoRaWAN Specification Version and Regional Frequency Plan
Verify that the sensor supports:
- LoRaWAN 1.0.3 or 1.1 — older 1.0.2 devices lack full security improvements
- The correct regional frequency plan for your country:
- EU868 (863–870 MHz) — Europe
- IN865 (865–867 MHz) — India
- US915 (902–928 MHz) — North America
- AS923 — Southeast Asia, Japan, New Zealand
A sensor purchased for a European deployment will not function correctly on an Indian (IN865) network server, even if the hardware physically transmits at similar frequencies. Frequency plans define channel configurations, duty cycle rules, and power limits that must match the network server configuration exactly.
Industrial vs Standard Sensor Variants: Which Type for Which Environment
Not every LoRaWAN temperature and humidity sensor is designed for the same environment. Understanding the variant categories helps you specify correctly.
Standard / Commercial Sensors
Examples: Dragino LHT65N, Milesight EM300-TH, Elsys ERS
Characteristics: Compact form factor. IP54–IP65. Built-in sensing elements (no external probe). Battery life of 3–7 years at standard intervals. Accuracy ±0.3°C / ±3% RH. Designed for indoor commercial environments: offices, server rooms, retail stores, building management.
Not suited for: Outdoor harsh environments, refrigeration below −20°C, high-vibration industrial machinery, or washdown areas.
Industrial-Grade Sensors
Examples: Milesight EM500-SWL, Tektelic TUNDRA, NCD LoRaWAN Industrial T&H
Characteristics: Rugged IP67 enclosure. Wide temperature range (−40°C to +85°C operating). Stainless steel or reinforced ABS housing. Li-SOCl₂ battery. External probe support. Built for harsh industrial environments: factories, cold rooms, outdoor installations, high-humidity areas.
Best for: Cold chain logistics, food processing, outdoor industrial monitoring, refrigerated warehouses, and any environment subject to moisture, vibration, or temperature extremes.
High-Accuracy / Compliance-Grade Sensors
Examples: Dragino LHT65N-E3, Minew MST01 (long probe variant), NCD High-Accuracy series
Characteristics: Calibration certificate available. Accuracy ±0.1–0.3°C / ±2% RH. Traceable calibration to national standards (NIST, PTB). Required for pharmaceutical storage under GDP (Good Distribution Practice), vaccine cold chain monitoring, and laboratory environments under ISO 17025.
Critical point: Calibration certificates expire. Most pharmaceutical and laboratory compliance frameworks require annual or biannual sensor recalibration. Factor in the cost and logistics of recalibration when specifying sensors for regulated environments.
Sensors With RS485 / Modbus Integration
This category is underrepresented in most sensor comparisons but is highly relevant for industrial retrofit deployments.
Many industrial temperature transmitters and process instruments output data via Modbus RTU over RS485 — a wired communication standard that has been the backbone of industrial instrumentation for decades. These instruments are not LoRaWAN sensors; they are wired sensors with RS485 outputs.
An RS485-to-LoRaWAN converter — also called a Modbus-to-LoRaWAN gateway — connects to the RS485 bus, polls the Modbus registers of the connected instruments at a configured interval, encodes the register values into LoRaWAN payloads, and transmits them wirelessly to the LoRaWAN network. The result: your existing wired temperature transmitter — PT100, 4–20 mA, or Modbus RTU output — becomes a wireless LoRaWAN sensor without any change to the sensor itself.
This approach is frequently the most cost-effective path for industrial retrofit applications where:
- Existing PT100 or thermocouple instruments are already installed and calibrated
- The instruments are in locations with poor wireless signal (inside metal enclosures, in process equipment)
- Regulatory or process compliance requires the use of specific, certified sensing elements
See also: [RS485 to LoRaWAN Converter Guide — How to Connect Modbus Instruments Wirelessly]
Use Cases by Industry: Where LoRaWAN Temperature and Humidity Sensors Deploy
Cold Chain Logistics and Food Safety
The problem: Temperature-sensitive perishables — fresh produce, dairy, meat, seafood — must be maintained within strict temperature bands throughout their journey from producer to consumer. A single undetected temperature excursion can render an entire shipment unsafe and non-compliant. Traditional data loggers are manual, require physical download, and only flag problems after the fact.
How LoRaWAN solves it: Sensors inside refrigerated trucks, cold rooms, and warehouse racking transmit temperature and humidity readings every 5–15 minutes to a central gateway. Any excursion above or below the defined threshold triggers an immediate alert — before spoilage occurs, not after. Data is logged continuously for regulatory audit trails.
Real-world result benchmark: A food distributor deploying TEKTELIC TUNDRA sensors across refrigerated trucks and warehouses recorded temperature deviations within minutes of occurrence, achieving a 30% reduction in product loss. Battery life across multi-year contracts required no replacement, and IP67 housings survived wet, cold environments without failure.
HACCP and regulatory compliance: Many food safety frameworks (HACCP, FDA 21 CFR Part 11, EU Food Hygiene Regulation 852/2004) require continuous temperature records for auditable periods. LoRaWAN systems provide this automatically, replacing manual logging with timestamped electronic records accessible on-demand.
Pharmaceutical and Vaccine Storage
Temperature requirements: Vaccines and many pharmaceuticals require storage at 2°C–8°C (refrigerated) or −20°C to −80°C (frozen). Excursions outside these ranges can render product ineffective or unsafe. WHO prequalification and GDP (Good Distribution Practice) require continuous monitoring and documented excursion response procedures.
Why LoRaWAN: Monitoring dozens of refrigerators and freezers across a hospital, pharmacy, or distribution facility with wired sensors is impractical. LoRaWAN sensors inside each unit, transmitting to a single gateway covering the entire facility, provide continuous monitoring without cabling. High-accuracy sensors (±0.1–0.3°C) with calibration certificates meet regulatory accuracy requirements.
Key requirement: Sensors used in GDP/GMP-regulated environments must have calibration traceability documentation and defined recalibration schedules. Confirm before purchasing that the manufacturer provides and supports calibration certificates.
Industrial Process and Machine Monitoring
Temperature in industrial context: In manufacturing, temperature is not just an environmental parameter — it is a process variable. Motor winding temperature, bearing temperature, coolant temperature, and oven cavity temperature all affect product quality, equipment life, and safety. Monitoring these requires sensors capable of interfacing with existing Modbus RTU instruments or direct thermocouple inputs, not just ambient air measurement.
What LoRaWAN adds: Wireless connectivity eliminates the need for new signal cable runs in existing facilities — often the most expensive part of a monitoring upgrade. A combination of native LoRaWAN industrial sensors and RS485-to-LoRaWAN converters can instrument an entire factory floor and transmit all data to a single gateway, enabling predictive maintenance alerting and real-time process dashboards.
Warehouse and Supply Chain
The challenge: Large distribution warehouses — 50,000 m² and above — have significant environmental variation between zones. Ambient temperature near loading bays differs from conditions in the deep storage area. Humidity varies with the number of active doors and local ventilation. Manual spot-checking misses this variation; wired sensor grids are expensive to retrofit.
LoRaWAN advantage: A single outdoor LoRaWAN gateway can cover an entire warehouse yard. Indoor gateways on the roof trusses cover the floor below. Sensors on racking uprights, loading bay doors, and HVAC return air ducts provide a complete environmental picture with no new cabling beyond the sensor mounting bracket.
Smart Agriculture and Greenhouses
Why temperature and humidity matter in agriculture: Plant growth, disease pressure, irrigation scheduling, and post-harvest storage are all temperature and humidity sensitive. In greenhouses, maintaining optimal temperature and humidity increases yield and reduces fungal disease risk. In grain storage, humidity monitoring prevents mould and mycotoxin development that can condemn entire harvests.
LoRaWAN's advantage in outdoor agriculture: Range. A single gateway mounted on a silo or elevated pole can cover hundreds of hectares of field crops. Sensors between crop rows, in soil surface positions, or inside storage bins transmit data without any cellular coverage requirement. Battery life of 5+ years means no maintenance for the life of a sensor installation.
HVAC and Building Management
The use case: Commercial buildings, data centres, and manufacturing facilities spend significant energy on HVAC. Granular temperature and humidity data — per-zone, per-floor, per-room — enables demand-controlled ventilation, identifies zones with poor climate control, and provides energy optimisation data that broad thermostat-based control cannot.
LoRaWAN vs Wi-Fi for building monitoring: Wi-Fi sensors require AP coverage at every sensor location, and the 2.4/5 GHz signals from hundreds of sensors create network congestion. LoRaWAN sensors transmit infrequent small payloads that do not meaningfully load the gateway. A single LoRaWAN gateway covers an entire multi-storey building; Wi-Fi requires an AP on every floor and segment.
Data Centres
Critical monitoring: Server rooms and data centre rows require temperature monitoring at rack level — ambient temperature varies significantly between the cold aisle, hot aisle, and room perimeter. Humidity control prevents static discharge and condensation on sensitive electronics. Regulatory frameworks (ASHRAE A2, EN 50600) define operating envelopes that must be continuously verified.
LoRaWAN vs alternatives: In a data centre environment, Wi-Fi APs are already present but adding IoT sensors to the same infrastructure creates RF congestion and management complexity. LoRaWAN operates on sub-GHz unlicensed spectrum that does not interfere with 2.4/5 GHz IT infrastructure. A single LoRaWAN gateway covers the entire data hall; sensors are battery-powered and require no additional PoE drops or cable management.
Frequently Asked Questions
Q: How does a LoRaWAN temperature humidity sensor send data without Wi-Fi or cellular?
It uses LoRa (Long Range) radio — a sub-GHz wireless protocol using chirp spread spectrum modulation that is completely independent of Wi-Fi or cellular infrastructure. The sensor transmits directly to a LoRaWAN gateway (which you own and deploy, or which a network operator has installed), which then forwards the data over the internet via its own backhaul connection. The sensor itself needs no network credentials, no SIM card, and no IP address — it uses its DevEUI and AppKey for authentication over the LoRaWAN protocol.
Q: How often does a LoRaWAN temperature sensor send data?
Most sensors are configurable, with common defaults of 10, 20, or 30 minutes. Some support intervals as short as 1 minute (for process-critical applications) or as long as 24 hours (for very long battery life on slow-changing environments like archive storage). The interval is a key trade-off: shorter intervals give more granular data but reduce battery life proportionally. For most cold chain and environmental monitoring applications, 15–30 minute intervals provide adequate resolution for both alerting and compliance logging.
Q: What is the difference between OTAA and ABP in LoRaWAN sensors?
OTAA (Over-the-Air Activation) is the secure join method where the sensor generates session keys dynamically each time it joins the network, using its AppKey and random nonces. ABP (Activation By Personalisation) hardcodes the session keys in the device permanently. OTAA is significantly more secure — session keys change with each join, and the AppKey never travels over the air. ABP is simpler to configure but has known security vulnerabilities, particularly around frame counter reset on power cycle. Use OTAA for all production deployments.
Q: Can a LoRaWAN sensor work inside a metal enclosure or freezer?
Inside a metal enclosure, the LoRaWAN signal is severely attenuated by the metal casing. Most industrial sensors designed for this application either use an external antenna routed outside the enclosure (through a cable gland or SMA bulkhead), or are designed for surface-mounting on the exterior with a probe entering the enclosure. The sensor body and radio need clear signal path to the gateway; the sensing probe can extend into any environment. For freezers specifically, verify the sensor's operating temperature range against the storage temperature — standard sensors rated to −20°C are not appropriate for deep-freeze (−80°C) pharmaceutical storage.
Q: How accurate are LoRaWAN temperature humidity sensors?
Accuracy varies by sensor grade and sensing technology. For humidity: ±2–3% RH for quality capacitive sensors; ±5% RH for lower-cost variants. For temperature: ±0.1–0.3°C for PT100-based sensors; ±0.3–0.5°C for NTC thermistor sensors; ±1.0°C for economy grades. For pharmaceutical and laboratory applications requiring regulatory compliance, look for sensors with traceable calibration certificates — not all manufacturers provide these, and those that do typically charge a premium. Calibration typically degrades over time; plan for annual recalibration in compliance-critical applications.
Q: What is payload decoding in a LoRaWAN sensor, and do I need to configure it?
Yes, payload decoding is a required configuration step that many first-time deployments overlook. LoRaWAN sensors transmit their readings as raw binary byte arrays — a string of hex bytes that is meaningless without a corresponding decoder. The payload decoder is a small function (usually JavaScript) configured in the network server that converts the raw bytes into named, human-readable values (e.g., {"temperature": 4.2, "humidity": 78.5}). Most manufacturers provide pre-written decoders for their devices; The Things Stack v3 and ChirpStack both have community repositories of decoders for popular sensor models. Without a decoder, data arrives at your application as useless hex strings.
Q: How long does the battery last in a LoRaWAN temperature humidity sensor?
Battery life depends on four variables: uplink interval, spreading factor, battery chemistry, and ambient temperature. A quality industrial sensor with Li-SOCl₂ battery, transmitting every 30 minutes at SF7–SF9, in a moderate temperature environment, will typically last 5–8 years. The same sensor set to 5-minute intervals or forced to SF12 (due to poor gateway placement) may last 1–2 years. Always ask the manufacturer what assumptions underlie their stated battery life, and model your own expected life against your actual deployment conditions.
Q: Can I connect my existing wired temperature sensors to a LoRaWAN network?
Yes, in most cases. If your existing sensors output Modbus RTU over RS485, a 4–20 mA signal, or a PT100 resistance output, an RS485-to-LoRaWAN converter or multi-input LoRaWAN interface device can read these outputs and transmit the values wirelessly. This avoids replacing calibrated, installed sensing elements and is often the most cost-effective approach for industrial retrofit projects. See our [RS485 to LoRaWAN converter guide] for a full breakdown of how this works.
Q: Does a LoRaWAN temperature sensor work without internet?
The sensor itself transmits to the gateway over LoRa radio regardless of internet connectivity. If the gateway has no internet connection (backhaul failure), data is not forwarded to the network server — packets are lost unless the gateway has local buffering. Some industrial gateway models include local data buffering that stores packets during backhaul outages and retransmits when connectivity is restored. For mission-critical monitoring, specify gateways with local buffering and dual-backhaul capability (Ethernet + cellular failover).
Summary: What You Now Know About LoRaWAN Temperature and Humidity Sensors
| Component / Stage | What It Does |
|---|---|
| Capacitive sensing element | Hygroscopic polymer film changes capacitance with humidity → ADC reads → %RH |
| NTC thermistor / PT100 / thermocouple | Resistance or voltage changes with temperature → ADC reads → °C |
| Microcontroller | Wakes on timer, samples sensors, encodes payload, manages LoRaWAN stack, returns to sleep |
| LoRa radio chip (SX1261/62) | Modulates payload using chirp spread spectrum; transmits on sub-GHz channel |
| OTAA join | Sensor exchanges encrypted credentials with network server; session keys derived; never transmitted |
| Uplink packet | 4–11 bytes of encrypted binary data: temperature + humidity + battery + status |
| Gateway | Receives LoRa packet; adds RSSI/SNR metadata; forwards over IP to network server |
| Network server | Verifies MIC; decrypts payload; applies ADR; delivers to application |
| Payload decoder | Converts hex byte array to named JSON fields (temperature, humidity, battery_mv) |
| Application layer | Time-series storage, dashboard visualisation, threshold alerts, compliance reporting |
The sensor transmits for less than 1,500 ms per cycle. The remaining 99%+ of its life is spent in microamp deep sleep. Everything from the sensing physics to the network architecture is optimised around this single constraint — and it is why a battery the size of a AA cell powers a device that monitors your cold chain for a decade.
