Sensor selection follows a three-step process: (1) define requirements (measurement type, accuracy, range, power budget, interface, environment, cost), (2) create a shortlist of 3-5 candidates using a comparison matrix, and (3) verify against datasheets before purchasing. For outdoor deployment, prioritize waterproof options (DS18B20 probe) and low sleep current. Always calculate battery life and prototype in real conditions before committing to production.
Total Cost of Ownership (TCO): Complete cost over the deployment lifetime: purchase price + installation + calibration + replacement frequency; a $5 sensor requiring monthly calibration often costs more over 5 years than a $50 factory-calibrated alternative
Environmental Rating (IP Code): Ingress Protection rating defining dust and water resistance; IP67 (dust-tight, 1 m immersion) is the minimum for outdoor IoT; IP69K is needed for high-pressure washdown environments
Mean Time Between Failures (MTBF): Average time a sensor operates before failing; critical for infrastructure deployments where sensor replacement requires maintenance visits; choose MTBF appropriate for the maintenance interval
Form Factor and Integration: Physical size, mounting method (board-mount, panel-mount, pipe-thread), and connector type; a technically superior sensor that cannot be mechanically integrated is not a viable choice regardless of its specifications
Long-Term Availability / Lifecycle: Manufacturer’s guarantee of continued production; sensors in products with 10-year lifespans must remain available as spare parts for that duration; check lifecycle notices before designing a long-production-run product
Regulatory Compliance: Certifications required for the target market: CE (Europe), FCC (USA), RoHS (hazardous materials), ATEX/IECEx (explosive atmospheres), FDA (medical); non-compliant sensors block product certification
Calibration Interval Requirement: How frequently the sensor must be recalibrated to maintain accuracy; industrial pressure sensors may require annual traceable calibration while consumer MEMS sensors may not need recalibration for 5+ years
Learning Objectives
After completing this chapter, you will be able to:
Apply a systematic three-step process for sensor selection
Evaluate selection criteria to narrow down candidate sensors
Prioritize tradeoffs across cost, accuracy, power, and complexity dimensions
Justify purchasing decisions using weighted scoring matrices
For Beginners: Choosing the Right Sensor
Picking a sensor can feel overwhelming with so many options available. This guide gives you a simple step-by-step process: first decide what you need to measure, then how accurate it needs to be, then what your budget and power constraints are. It is like shopping for shoes – once you know your size, activity, and budget, the thousands of options quickly narrow down to just a handful of good choices.
With thousands of sensor models available, choosing the right one for a specific IoT project can feel overwhelming. A temperature sensor alone might have dozens of viable candidates across different technologies, price points, and form factors. Without a structured approach, teams often default to familiar sensors or the first result from an online search – only to discover months later that the sensor fails in deployment due to power, accuracy, environmental, or cost constraints they never evaluated.
This chapter presents a repeatable three-step methodology for sensor selection: define requirements, create a shortlist with a scored comparison matrix, and verify against datasheets. You will work through a complete outdoor deployment example, use interactive tools to explore how weighting priorities changes the “best” sensor, and study how Google’s Nest team navigated the transition from prototype sensor to production sensor at scale.
16.3 How to Choose the Right Sensor: A Step-by-Step Process
Sensor selection is a structured engineering process, not guesswork. The following three steps transform vague project needs into a defensible sensor choice backed by data.
16.3.1 Step 1: Define Requirements
Before looking at sensors, answer these questions:
Question
Your Answer
Impact on Selection
What physical quantity?
(temp, pressure, motion…)
Determines sensor category
Required accuracy?
(+/-X units)
Filters cheap vs expensive options
Required range?
(min to max value)
Must cover all expected conditions
Response time needed?
(ms, seconds, minutes)
Fast control vs slow logging
Power budget?
(mA, battery life)
Active vs passive, duty cycling
Interface preference?
(analog, I2C, SPI, UART)
Hardware/software compatibility
Environmental conditions?
(temp, humidity, vibration)
IP rating, industrial-grade
Budget per unit?
($)
Narrows options significantly
16.3.2 Step 2: Create a Shortlist
Based on requirements, identify 3-5 candidate sensors:
Example: Temperature Sensor Selection
Requirement
DHT11
DHT22
DS18B20
BME280
SHT31
Accuracy +/-0.5C
No (+/-2C)
Yes
Yes (-10 to +85C range)
Marginal (+/-1C)
Yes (+/-0.3C)
Range -20 to 60C
Yes
Yes
Yes
Yes
Yes
Humidity reading
Yes
Yes
No
Yes
Yes
I2C interface
No
No
No (1-Wire)
Yes
Yes
Power <1mA
Yes
Yes
Yes
Yes
Yes
Cost <$10
Yes ($2)
Yes ($5)
Yes ($3)
Yes ($8)
No ($15)
PASS
No
Yes
Partial
Yes
No
Result: DHT22 or BME280 meet requirements. Choose BME280 if pressure is useful, DHT22 if simpler is better.
Figure 16.1 summarizes the three-step process as a visual flowchart. Start at the top with “What do you need to measure?” and follow the branches through accuracy, power, interface, and environment constraints to reach a recommended sensor.
Figure 16.1: Sensor selection decision tree flowchart starting with measurement type (temperature, motion, distance, gas, etc.), then branching by accuracy requirements, power constraints, interface preferences, and environmental conditions to recommend specific sensor models
16.5 Quick Sensor Selector by Application
Application
Primary Sensor
Alternative
Key Spec
Smart thermostat
DHT22
BME280
+/-0.5C accuracy
Weather station
BME280
SHT31 + BMP280
Pressure for altitude
Motion lighting
PIR HC-SR501
Radar RCWL-0516
7m range
Parking detection
HC-SR04 (2-400cm)
VL53L0X (up to 200cm)
Ultrasonic or ToF ranging
Step counting
ADXL345
MPU6050
3-axis, selectable up to +/-16g
Smoke detection
MQ-2
MQ-135
Gas sensitivity
Water leak
Conductivity probe
Float switch
Digital output
Door/window
Reed switch
Hall sensor
Magnet detection
16.6 Worked Example: Selecting a Temperature Sensor for Outdoor Deployment
Requirements:
Measure temperature -20C to +50C
Accuracy +/-0.5C
Battery-powered (2 years target)
Read every 5 minutes
Outdoor enclosure (IP65)
Budget: $10 per sensor
Analysis:
Criterion
DS18B20
DHT22
BME280
Decision
Range
-55 to +125C
-40 to +80C
-40 to +85C
All pass
Accuracy
+/-0.5C (-10 to +85C; +/-2C outside)
+/-0.5C
+/-1C
DS18B20, DHT22
Current (active)
1mA
1.5mA
0.3mA
BME280 best
Current (sleep)
1uA
50uA (high for multi-year battery)
0.1uA
DS18B20, BME280
Interface
1-Wire
Digital
I2C
All OK
Waterproof option
Yes (probe)
No
No
DS18B20
Cost
$3
$5
$8
All within budget
Battery Life Calculation (DS18B20 sensor only):
288 readings/day x 0.75s x 1mA = 0.06mAh active
23.94 hours x 0.001mA = 0.024mAh sleep
Total sensor consumption: 0.084mAh/day
2000mAh battery: 23,800 days (65 years theoretical, sensor only)
Note: This calculation covers only the sensor’s power draw. In practice, the microcontroller (ESP32, ATmega328P, etc.) dominates total power consumption. For example, an ESP32 in deep sleep draws approximately 10-150uA depending on configuration (RTC peripherals enabled, ULP coprocessor, etc.), adding 0.24-3.6mAh/day. Always calculate system-level power, not just sensor power, when estimating battery life.
Selection: DS18B20 - Best for outdoor due to waterproof probe option, excellent power efficiency, and meets accuracy requirement.
16.6.1 Interactive Battery Life Calculator
Use this calculator to estimate sensor battery life for your own projects. Adjust the parameters to match your sensor’s datasheet values and your sampling requirements.
Show code
viewof batteryCapacity = Inputs.range([100,10000], {value:2000,step:100,label:"Battery capacity (mAh)"})viewof activeCurrent = Inputs.range([0.01,50], {value:1.0,step:0.01,label:"Sensor active current (mA)"})viewof activeTime = Inputs.range([0.01,10], {value:0.75,step:0.01,label:"Active time per reading (s)"})viewof sleepCurrent = Inputs.range([0.01,500], {value:1.0,step:0.01,label:"Sensor sleep current (uA)"})viewof readingInterval = Inputs.range([1,1440], {value:5,step:1,label:"Reading interval (minutes)"})viewof mcuActiveCurrent = Inputs.range([1,250], {value:50,step:1,label:"MCU active current (mA)"})viewof mcuActiveTime = Inputs.range([0.01,10], {value:0.5,step:0.01,label:"MCU active time per reading (s)"})viewof mcuSleepCurrent = Inputs.range([0,500], {value:10,step:1,label:"MCU sleep current (uA)"})
This Python tool automates the comparison matrix from Step 2, scoring candidate sensors against your requirements. It eliminates subjective bias by computing a weighted score:
class SensorComparator:"""Score and rank candidate sensors against project requirements. Each requirement has a weight (importance) and a pass/fail threshold. Passing requirements contribute their full weight to the total score. """def__init__(self):self.requirements = []self.candidates = {}def add_requirement(self, name, weight, unit=""):"""Add a project requirement with importance weight (0-10)."""self.requirements.append({"name": name, "weight": weight, "unit": unit })def add_candidate(self, name, specs):"""Add a sensor candidate with its specifications. Args: name: Sensor model name (e.g., "DHT22"). specs: Dict mapping requirement names to {"value": actual, "meets": True/False}. """self.candidates[name] = specsdef rank(self):"""Rank all candidates by weighted score. Returns: List of (name, score, pass_count, fail_list) sorted by score. """ results = []for name, specs inself.candidates.items(): total_score =0 total_weight =0 fails = []for req inself.requirements: rname = req["name"]if rname in specs:if specs[rname]["meets"]: total_score += req["weight"] *10else: fails.append(rname) total_weight += req["weight"] score = (total_score / (total_weight *10) *100if total_weight >0else0) passed =len(self.requirements) -len(fails) results.append((name, round(score), passed, fails)) results.sort(key=lambda r: r[1], reverse=True)return results# Example: Outdoor temperature monitoring projectcomp = SensorComparator()comp.add_requirement("accuracy", weight=9, unit="C")comp.add_requirement("waterproof", weight=10)comp.add_requirement("sleep_current_under_10uA", weight=7)comp.add_requirement("cost_under_10", weight=5)comp.add_requirement("humidity", weight=3)comp.add_candidate("DS18B20", {"accuracy": {"value": 0.5, "meets": True},"waterproof": {"value": "probe", "meets": True},"sleep_current_under_10uA": {"value": 1, "meets": True},"cost_under_10": {"value": 3, "meets": True},"humidity": {"value": "no", "meets": False},})comp.add_candidate("DHT22", {"accuracy": {"value": 0.5, "meets": True},"waterproof": {"value": "no", "meets": False},"sleep_current_under_10uA": {"value": 50, "meets": False},"cost_under_10": {"value": 5, "meets": True},"humidity": {"value": "yes", "meets": True},})comp.add_candidate("BME280", {"accuracy": {"value": 1.0, "meets": False},"waterproof": {"value": "no", "meets": False},"sleep_current_under_10uA": {"value": 0.1, "meets": True},"cost_under_10": {"value": 8, "meets": True},"humidity": {"value": "yes", "meets": True},})for name, score, passed, fails in comp.rank(): status ="PASS"ifnot fails elsef"FAIL: {', '.join(fails)}"print(f"{name:10s} Score: {score}% ({passed}/{len(comp.requirements)} reqs) {status}")# Output:# DS18B20 Score: 91% (4/5 reqs) FAIL: humidity# DHT22 Score: 50% (3/5 reqs) FAIL: waterproof, sleep_current_under_10uA# BME280 Score: 44% (3/5 reqs) FAIL: accuracy, waterproof
Putting Numbers to It
Weighted scoring quantifies trade-offs. For DS18B20 with weights \(w = [9, 10, 7, 5, 3]\) and meets \(= [1, 1, 1, 1, 0]\):
DHT22 fails waterproof (weight 10) and sleep current under 10uA (weight 7): \(\frac{(9+0+0+5+3) \times 10}{340} \times 100 = 50\%\). The 41-point gap (91% vs 50%) reflects the combined weight of waterproofing (10) and low sleep current (7) – both critical for outdoor battery-powered deployment. Even if you increase humidity weight from 3 to 10 (new total weight = 41), DS18B20 scores \(\frac{310}{410} \times 100 = 76\%\) while DHT22 becomes \(\frac{240}{410} \times 100 = 59\%\). DS18B20 still leads because multiple failed high-weight requirements compound. Weights encode your priorities.
16.7.1 Interactive Weight Explorer
Adjust the requirement weights below to see how they change the sensor ranking. This demonstrates how your priorities directly determine the “best” sensor – there is no objectively best sensor, only the best sensor for your requirements.
Use modules - Breakout boards include passives, save soldering
Skip unnecessary features - DHT11 vs DHT22 if +/-2C is acceptable
Check Chinese sources - AliExpress sensors 3-5x cheaper (longer shipping)
Open-source designs - Community-validated circuits save development time
Key Takeaway
The cheapest sensor on a BOM is rarely the cheapest in total cost of ownership. Factor in development time (library maturity, community support, documentation quality), reliability costs (warranty returns, field failures), and power infrastructure (battery size, solar panel). A sensor that costs $3 more per unit but saves 20 hours of debugging across a project is the better investment.
For Kids: Meet the Sensor Squad!
Max the Microcontroller needed to pick a temperature sensor for a garden weather station. But there were SO many choices! How do you pick?
“Step one: Write down what you NEED,” Max said. He made a list: - Measure -20 to +50 degrees (gardens get cold in winter!) - Accurate to +/- 0.5 degrees - Waterproof (it rains!) - Run on batteries for at least a year - Cost less than $10
Sammy the Sensor (DS18B20) raised his hand: “I am waterproof, I cost $3, I have +/-0.5 degree accuracy, and I sleep at only 1 microamp!”
Dee the DHT22 tried too: “I also have +/-0.5 degree accuracy AND I measure humidity! But… I am not waterproof.”
The BME280 jumped in: “I measure temperature, humidity, AND pressure! But my temperature accuracy is only +/-1 degree.”
Max made a comparison chart and checked off each requirement. “DS18B20 wins for this project because it is waterproof, accurate enough, cheap, and super low-power. For an indoor project, I might choose differently!”
Bella the Battery approved: “With DS18B20’s tiny sleep current, I can last for YEARS! Always check the power consumption before choosing!”
Lila the LED added: “And ALWAYS test the sensor in real conditions before you build 100 of them. What works on your desk might not work in a rainy garden!”
16.9 Scaling from Prototype to Production: Nest Protect Sensor Selection
Sensor selection decisions that work at prototype scale can fail catastrophically at production volumes. The Nest Protect smoke and CO detector illustrates how production constraints reshape sensor choices.
Prototype phase (2012): Nest engineers initially prototyped with an MQ-2 gas sensor (the same $2 sensor common in hobbyist projects) alongside an optical smoke chamber. The MQ-2 performed well in lab tests – detecting smoke, CO, and natural gas.
Why MQ-2 failed at production scale:
Factor
MQ-2 (Prototype)
Production Requirement
Gap
Power consumption
~800 mW continuous (heater element, 5V x 160mA)
<5 mW average (6-year battery life)
~160x over budget
Warm-up time
24-48 hours for stable readings
Instant-on for safety device
Unacceptable for battery-powered device
Cross-sensitivity
Responds to cooking vapors, hair spray, steam
Must distinguish real threats from nuisance alarms
False alarm rate too high
Calibration drift
Significant drift after 6 months
UL 2034 requires accuracy over 7-year lifespan
Would fail regulatory testing
Unit cost at volume
$2 (single unit)
$0.50 target at 1M units
Sensor itself was cheap; the power budget was not
Production solution: Nest selected a Figaro TGS5141 electrochemical CO sensor ($4.50 at volume) paired with a split-spectrum optical smoke chamber. The electrochemical sensor draws 0 mA at idle (no heater), responds within approximately 60 seconds (T90), maintains calibration for 10+ years, and distinguishes CO from other gases with near-zero cross-sensitivity.
The counterintuitive lesson: The production sensor cost 2x more per unit than the prototype sensor, but saved an estimated $12 per unit in battery costs (no heater = smaller battery), $8 per unit in warranty claims (fewer false alarms = fewer returns), and enabled the 6-year battery life that became a key selling point. Total cost of ownership was 40% lower despite higher sensor unit cost.
Checklist for prototype-to-production sensor transitions:
Calculate power budget over full product lifetime, not just active measurement
Verify sensor accuracy spec at end-of-life, not just new-from-factory
Test cross-sensitivity with realistic household interferents (cooking, cleaning products, humidity)
Confirm regulatory certification path (UL, CE, FCC) for the specific sensor model
Get volume pricing quotes – some sensors have steep quantity discounts, others do not
Evaluate supply chain risk – single-source sensors create production bottlenecks; consider dual-sourcing critical sensors or securing supplier agreements and safety stock to mitigate shortages
Request reliability data (MTTF) for the specific operating conditions of your product, not just the generic datasheet value
16.10 Concept Relationships
Concept
Related To
Connection Type
Accuracy Requirement
Application Constraints
HVAC needs ±1°C; medical needs ±0.1°C
Power Budget
Battery Capacity
Sleep current determines multi-year battery life
Interface Type
GPIO Availability
I2C shares 2 pins; analog needs 1 pin per sensor
Waterproof Rating
Deployment Environment
Outdoor sensors need IP65+ protection
Maximum Spec
Production Variation
Design for worst-case, not typical performance
🏷️ Label the Diagram
Code Challenge
16.11 Summary
Key sensor selection takeaways:
Define requirements first - Then find sensors, not the other way around
Create a shortlist - Compare 3-5 candidates systematically
Verify with datasheets - Don’t trust marketing specs alone
Consider total cost - Includes development time, libraries, support
Prototype before production - Test in real conditions
16.12 Try It Yourself
Exercise: Selection Matrix Practice
Scenario: Design a battery-powered weather station for a remote hiking trail. Requirements: - Measure temperature (-20°C to +50°C, ±0.5°C accuracy) - Measure humidity (0-100% RH, ±3% accuracy) - Battery life: minimum 1 year (CR2477 coin cell, 1000mAh) - Read sensors every 10 minutes - Budget: $15 or less per sensor
Your task: Create a comparison matrix and select the best sensor.
Click for solution template
Sensor
Temp Accuracy
Humidity
Power (active/sleep)
Cost
Waterproof
Score
DHT22
±0.5°C ✓
±2% ✓
1.5mA / 50µA
$5 ✓
No ✗
4/5
BME280
±1°C ✗
±3% ✓
0.3mA / 0.1µA
$8 ✓
No ✗
3/5
SHT31
±0.2°C ✓
±2% ✓
1.5mA / 0.4µA
$15 ✓
PTFE filter option ✓
5/5
Best choice: SHT31 - Best accuracy and humidity performance with excellent sleep current. The SHT31-DIS-F variant includes a PTFE membrane filter for splash protection, though a proper IP65 enclosure is still needed for outdoor deployment. At exactly $15 it meets the budget ceiling. If cost pressure increases, the DHT22 at $5 is a strong alternative that passes all requirements except waterproofing.
Battery life check (SHT31, sensor only):
Per cycle (10 min = 600s):
Active: 1.5mA × 1s = 1500µA × (1/3600)h = 0.417µAh
Sleep: 0.4µA × 599s = 0.4µA × (599/3600)h = 0.067µAh
Total per cycle: 0.484µAh
Per day: 144 cycles × 0.484µAh = 69.7µAh = 0.070mAh
Battery life (sensor only): 1000mAh / 0.070mAh/day ≈ 14,300 days ✓ (39 years)
Note: Microcontroller sleep current will dominate real-world battery life.
Common Mistakes - Avoid voltage mismatch and interface errors
Common Pitfalls
1. Optimizing on a Single Criterion
Choosing the most accurate, cheapest, or lowest-power sensor without considering other requirements leads to designs that fail in practice. A sensor can be the most accurate in its class but impractical if it needs weekly calibration, has a 20-week lead time, or uses an incompatible protocol. Always use a multi-criteria weighted matrix.
2. Ignoring Component Lead Times During Prototyping
The sensor available for prototyping may have 20-week lead times for production quantities. Verify production supply chain availability before finalizing the BOM. Component shortages can delay product launches by months.
3. Not Testing in the Actual Deployment Environment
A sensor that performs well in the lab may fail in the field due to vibration, condensation, EMI from motors, or temperature cycling. Always conduct a deployment trial in the actual operating environment for 2-4 weeks before finalizing sensor selection.
4. Underspecifying Connector and Cable Requirements
The sensor may be rated IP67, but if the cable entry connector is only IP54, the assembly is IP54. Ingress protection is only as good as the weakest seal. Specify connectors and cable glands with IP ratings equal to or exceeding the sensor’s rating.
16.14 What’s Next
Now that you can select sensors using a structured methodology, explore these related topics: