3. 硬件与设备选型
物联网云平台的底层价值，最终要通过物理世界的感知与控制来兑现。硬件选型决定了项目的成本下限、功耗上限、开发效率以及长期运维的稳定性。本章从开发板、传感器/执行器、通信模块三个维度，建立一套可复用的选型决策框架。需要强调的是，选型不是“选最贵的”或“选最流行的”，而是基于供电条件、通信距离、数据量、部署环境与量产预期，在性能、成本、功耗和开发速度之间做显式权衡。
3.1 开发板选型：ESP32、树莓派、STM32的定位与适用边界
核心原理：主控选型的本质是算力、功耗与接口资源的三角平衡
物联网节点的主控芯片承担三类任务：采集传感器数据、运行通信协议栈、执行本地逻辑（如阈值判断、PID控制）。不同芯片在这三方面的能力差异巨大。ESP32 集成 Wi-Fi 和蓝牙，适合需要直接上云的终端设备；树莓派运行完整 Linux 系统，适合作为边缘网关或协议转换器；STM32 以 Cortex-M 内核为主，强调实时性与低功耗，适合工业传感器节点或电池供电设备。选型时首先要明确：设备是“端”还是“网关”？端设备通常只做采集和上报，网关则需要处理多协议转换、本地缓存和规则引擎。
判断方法：从需求指标反推芯片选型
| 需求维度 | ESP32（典型型号ESP32-WROOM-32） | 树莓派（Zero 2 W / 4B） | STM32（如STM32L4系列） |
|---|---|---|---|
| CPU算力 | 双核240MHz Xtensa | 4核1.5GHz Cortex-A72 | 80MHz Cortex-M4F |
| 内存 | 520KB SRAM + 4MB Flash | 512MB~8GB LPDDR4 | 128KB SRAM + 1MB Flash |
| 网络能力 | Wi-Fi 2.4G + BLE 4.2 | Wi-Fi 2.4/5G + BLE（需扩展） | 无内置，需外挂模块 |
| 典型功耗 | Wi-Fi 发射约240mA@3.3V | 空闲约200mA，满载1.2A | 低功耗模式可低至1μA |
| 开发语言 | C/C++、MicroPython、Arduino | Python、Node.js、C++ | C/C++、RTOS |
| 适用场景 | 智能家居终端、环境监测节点 | 边缘网关、图像识别、本地MQTT Broker | 工业传感器、可穿戴、电池设备 |
操作流程上，建议按以下步骤决策：第一步，列出设备必须支持的通信协议（如MQTT over Wi-Fi、LoRaWAN）；第二步，估算每秒最大数据量（如温湿度每10秒上报一次，约50字节/次，则Wi-Fi完全够用）；第三步，评估是否需要本地复杂逻辑（如视频流处理、TensorFlow Lite推理），若需要则直接考虑树莓派或带NPU的芯片；第四步，检查IO资源——需要几路ADC、几路PWM、几个UART，避免选型后外扩太多芯片。
实战案例：智能农业大棚环境监测节点
背景与约束：某农业科技公司需要部署200个节点，每个节点采集空气温湿度、土壤湿度、光照强度，每5分钟上报一次。现场无市电，采用太阳能+锂电池供电，要求单次充电续航至少30天。初始方案选用树莓派Zero 2 W，理由是Python开发快。
问题分析：树莓派Zero 2 W在Wi-Fi连接状态下平均电流约180mA，锂电池容量按10000mAh计算，理论续航仅约55小时，远不满足30天要求。进一步测量发现，树莓派即使进入待机模式，功耗仍高达80mA，且启动时间长达15秒，不适合频繁唤醒。
调整方案：改用ESP32-S3（支持Wi-Fi + BLE），搭配SHT30温湿度传感器、土壤湿度电容式传感器和BH1750光照传感器。ESP32在深度睡眠模式下电流仅10μA，每5分钟唤醒一次，采集数据后通过Wi-Fi发送至网关，单次工作电流约200mA，持续2秒。经实测，平均功耗约0.8mA，10000mAh电池理论续航超过500天。
结果与复盘：最终方案成本降低约40%（树莓派Zero 2 W约150元，ESP32-S3约25元），续航满足要求。复盘经验：选型时功耗预算必须放在第一位，开发便利性只能作为第二优先级。如果项目确实需要Python生态，可考虑ESP32运行MicroPython，但要注意MicroPython在低功耗管理上不如原生ESP-IDF灵活。
常见误区与总结
- 误区一：认为树莓派“什么都能干”就选它做终端设备。实际上树莓派不适合电池供电场景，其Linux系统启动慢、功耗高、易损坏SD卡。
- 误区二：忽略Flash和RAM容量。ESP32的4MB Flash在启用OTA升级后可能不够用，需选择16MB版本或外扩SPI Flash。
- 误区三：STM32选型时只看主频，忽略外设复用冲突。例如同时使用多个UART和ADC时，可能发生引脚冲突，需提前查阅数据手册的AF映射表。
3.2 传感器与执行器选型：接口匹配与信号调理
核心原理：传感器选型的关键是“信号链”而非单个器件
传感器输出信号分为数字信号（I2C、SPI、UART）和模拟信号（电压、电流、电阻变化）。数字传感器内部已完成放大和ADC转换，直接输出工程单位（如温度值），开发简单但成本较高；模拟传感器（如热敏电阻、光敏电阻）需要主控的ADC配合外部电阻分压电路，成本低但需自行校准。执行器方面，继电器适合开关型负载（如水泵、加热器），舵机适合角度控制（如阀门），直流电机需要H桥驱动（如L298N或DRV8833）。选型时需确认主控的GPIO驱动能力——ESP32的GPIO最大输出电流约40mA，直接驱动继电器线圈可能烧毁引脚，必须通过三极管或光耦隔离。
判断方法：传感器选型五步法
- 确定测量范围与精度：例如土壤湿度，电容式传感器（如SKU: SEN0193）输出模拟电压0~3V，对应湿度0~100%，精度约±3%。
- 确认供电电压与逻辑电平：3.3V主控搭配5V传感器时，I2C上拉电阻需接3.3V，避免灌入过高电压。
- 检查采样频率与数据量：加速度计MPU6050输出6轴数据，若以100Hz采样，每秒产生约1200字节，对UART或I2C带宽要求不高，但若用BLE传输则需考虑吞吐量。
- 评估环境适应性：户外场景需选择IP65以上防护等级，工业现场需考虑-40℃~85℃工作温度。
- 计算总功耗：传感器待机电流与工作电流差异很大，如SHT30待机仅0.2μA，而PMS5003激光粉尘传感器工作电流高达100mA，不适合电池供电。
案例拆解：智能家居中控面板的传感器与执行器组合
场景：设计一款墙面中控面板，需要检测环境温湿度、人体存在（用于自动亮屏）、控制两路灯光（继电器）和一路窗帘（舵机）。
选型过程：温湿度选用SHT30（I2C接口，精度±0.3℃，待机功耗低）；人体存在选用毫米波雷达模块HLK-LD2410（UART输出，可检测微动，比PIR更灵敏）；灯光控制采用5V继电器模块（低电平触发，带光耦隔离）；窗帘舵机选用MG996R（工作电流500mA，需外部5V供电，不能由主控直接供电）。
关键问题：舵机启动瞬间电流可达2A，若与ESP32共用3.3V电源会导致电压跌落，引起Wi-Fi断连。解决方案是采用独立5V/3A电源模块，并在舵机电源线上并联470μF电解电容。
结果：系统稳定运行，未出现复位或通信异常。复盘经验：执行器的峰值电流必须单独核算，不能只看平均功耗。
风险提示：模拟传感器（如土壤湿度探头）长期通电会产生电化学腐蚀，缩短寿命。建议采用间歇供电方式——通过MOSFET开关控制传感器电源，仅在采样前100ms上电，采样后立即断电，可延长传感器寿命3~5倍。
3.3 通信模块选型：Wi-Fi、LoRa、NB-IoT、Zigbee的决策矩阵
核心原理：通信选型由“距离、速率、功耗、成本”四维决定
四种主流物联网通信技术各有明确边界：Wi-Fi适合室内固定设备，速率高但功耗大、穿墙能力弱；LoRa工作在Sub-1GHz频段，灵敏度高达-137dBm，可实现城市级覆盖，但速率仅0.3~50kbps，适合低频小数据包；NB-IoT依托蜂窝网络，覆盖深、安全性高，但需要SIM卡和运营商资费，模块成本约30~50元；Zigbee基于802.15.4，支持Mesh组网，节点可达数百个，但需要网关协调器，且协议栈开发复杂。选型时还需考虑频段合规性——中国LoRa使用470~510MHz，NB-IoT使用Band 8（900MHz）或Band 5（850MHz）。
判断方法：通信选型决策树
| 决策条件 | 推荐方案 | 理由 |
|---|---|---|
| 设备固定且有市电，传输视频或大文件 | Wi-Fi 5/6（ESP32或外挂模块） | 带宽>50Mbps，开发简单 |
| 电池供电，每天上报<10次，距离>1km | LoRa（如SX1262） | 发射电流约120mA，休眠<1μA，免执照 |
| 地下车库/偏远山区，需运营商级覆盖 | NB-IoT（如BC26） | 覆盖增益20dB，支持PSM省电模式 |
| 智能家居多节点（>50个），需Mesh自组网 | Zigbee（如CC2530） | 低功耗，自动路由，但需协调器 |
| 移动设备（如手持终端），需实时双向通信 | 4G Cat.1（如Air724UG） | 速率10Mbps，全国覆盖，资费约10元/月 |
实战场景：智慧园区停车位检测系统
背景：某园区有500个地面停车位，需要检测每个车位是否被占用，数据实时上传至云平台。现场无Wi-Fi覆盖，车位分散在约2万平方米区域。
方案对比：若采用Wi-Fi，需部署至少20个AP，且车位检测器（地磁传感器）电池供电，Wi-Fi功耗过高不可行。若采用NB-IoT，每个车位需一张SIM卡，年资费约60元/卡，500个车位年成本3万元，且地下车库信号可能不稳定。最终选择LoRa方案：每个车位安装地磁传感器（如RN2483 LoRa模块），通过3个LoRa网关覆盖全园区，网关通过4G回传至云平台。
关键参数：LoRa扩频因子SF7，带宽125kHz，发射功率14dBm，实测通信距离约800m（园区内），单次上报数据包仅12字节，发射时间约50ms，平均电流约30mA（含传感器），电池（19000mAh锂亚电池）理论寿命超过5年。
结果与复盘：系统上线后误报率低于2%，电池续航已运行18个月无故障。复盘经验：LoRa的“低速率”不是缺点，而是省电的代价。如果业务需要频繁上报（如每10秒一次），LoRa的占空比限制（1%）会成为瓶颈，此时应改用NB-IoT或Cat.1。
经验提醒：通信模块选型时，务必确认模块的AT指令集是否完整支持你需要的功能。例如，某些LoRa模块仅支持透明传输，不支持LoRaWAN协议栈，需要自行实现MAC层，这会显著增加开发周期。建议优先选择已通过LoRaWAN认证的模块（如SX1262系列）。
常见误区与总结
- 误区一：认为Zigbee比Wi-Fi更省电。实际上Zigbee终端节点确实省电，但路由节点需要常供电，且Zigbee的OTA固件升级非常慢（几百KB可能需要数小时）。
- 误区二：忽略通信模块的“冷启动时间”。NB-IoT模块从PSM模式唤醒到注册网络可能需要3~5秒，如果业务要求秒级响应，需保持模块常在线，但功耗会上升至10mA以上。
- 误区三：不检查频段合规性。使用欧洲频段的LoRa模块（868MHz）在中国属于违法使用，可能干扰广电业务，选型时必须确认模块支持中国频段。