农业物联网基础：传感器、执行器、网关、通信协议（LoRa、NB-IoT、WiFi等）、云平台、数据流架构
农业物联网（AIoT）的本质，是将物理世界的农情参数（土壤、气象、虫害、水肥）转化为可计算、可决策、可执行的数据流。理解这一章，是编制任何一份可落地的SOP的前提——因为SOP中的每一个操作步骤，最终都要映射到具体的硬件接口、通信链路和数据字段上。如果对底层架构缺乏清晰认知，编制的SOP要么过于抽象无法执行，要么过于琐碎缺乏系统性。本章将围绕“感知—传输—处理—执行”四层链路，拆解农业物联网的核心组件与数据流转逻辑。
2.1 感知层：传感器选型与部署逻辑
核心原理：传感器是农业物联网的“五官”，其作用是将物理量（土壤体积含水量、空气温度、光照强度、CO₂浓度等）转换为电信号，再经模数转换（ADC）变为数字量。农业场景的特殊性在于：环境恶劣（高湿、高尘、温差大）、供电受限（野外无市电）、维护成本高。因此，传感器选型不能只看精度，更要看长期稳定性、防护等级（IP65以上）和功耗。
| 传感器类型 | 关键参数 | 典型精度要求 | 部署要点 |
|---|---|---|---|
| 土壤水分（FDR/TDR） | 体积含水量（%vol） | ±2~3% | 埋深10/20/40cm分层监测，避免紧贴根系 |
| 空气温湿度 | 温度/相对湿度 | ±0.3℃ / ±2%RH | 百叶箱内安装，高度1.5m，避免直晒 |
| 光合有效辐射（PAR） | μmol·m⁻²·s⁻¹ | ±5% | 水平安装，定期清洁透镜 |
| 水流量计 | 瞬时流量/累计流量 | ±2% | 前后直管段≥10D/5D，防止气泡干扰 |
操作流程：传感器部署应遵循“三步法”。第一步，网格化勘测：根据地块面积、地形起伏、土壤质地差异，将园区划分为若干监测单元（一般每10~30亩一个单元）。第二步，代表性点位选择：避开田埂、路边、树下等异常区域，采用“S形”或“对角线”布点法。第三步，安装与验证：安装后必须用便携式仪表或实验室法进行交叉校验，偏差超标的立即重装。
2.2 传输层：通信协议选型与网关配置
核心原理：传输层解决“数据怎么传回来”的问题。农业场景中，通信协议的选择直接决定了网络的覆盖范围、功耗、带宽和成本。目前主流协议包括LoRa、NB-IoT、WiFi、4G/5G等，它们各有优劣，适用于不同子场景。
| 协议 | 传输距离 | 功耗 | 带宽/速率 | 适用场景 | 成本（单节点） |
|---|---|---|---|---|---|
| LoRa | 2~15km（视环境） | 极低（电池供电） | 0.3~50kbps | 大田、果园、分散地块 | 中（需自建网关） |
| NB-IoT | 依托运营商基站 | 低 | ~100kbps | 有运营商覆盖的偏远地块 | 低（SIM卡计费） |
| WiFi | 50~100m | 高（需市电） | 高（>1Mbps） | 温室大棚、设施农业、视频监控 | 低 |
| 4G/5G | 不限 | 中高 | 高 | 视频回传、远程控制、应急通信 | 中（流量费） |
网关的定位：网关是感知层与平台层之间的“翻译官”和“集线器”。它负责：① 汇聚多个传感器节点的数据；② 完成协议转换（如将LoRa数据包转为MQTT/HTTP上报）；③ 执行边缘计算规则（如本地阈值判断、数据清洗）；④ 临时缓存数据，在网络中断时实现断点续传。
网关配置SOP要点：在编制SOP时，网关部分必须明确以下参数：① 信道频率与扩频因子（LoRa场景）；② 上行数据上报周期（默认15分钟，可远程调整）；③ 心跳保活机制（每5分钟发送心跳包）；④ 断网缓存容量（至少存储7天数据）；⑤ 远程管理通道（支持SSH或云平台远程配置）。
2.3 平台层：云平台架构与数据流设计
核心原理：云平台是农业物联网的“大脑”，负责设备接入、数据存储、规则引擎、可视化展示和告警通知。一个合格的农业IoT平台应具备三层能力：设备接入层（支持MQTT/CoAP/HTTP等协议，管理设备注册与鉴权）、数据处理层（时序数据存储、清洗、聚合、阈值计算）、应用服务层（提供API接口、可视化大屏、移动端推送）。
数据流架构：完整的数据链路为：传感器采集 → 网关汇聚 → 通信协议上传 → 平台消息中间件（如Kafka/RabbitMQ）→ 时序数据库（如InfluxDB/TDengine）→ 规则引擎触发 → 应用服务展示/告警 → 控制指令下发 → 执行器动作。这条链路中，任何一环的延迟或丢失都会影响最终决策。
// 数据上报示例（MQTT Payload JSON格式）
{
"device_id": "soil_001",
"timestamp": "2025-06-15T10:30:00+08:00",
"data": {
"soil_moisture_10cm": 28.5,
"soil_temp_10cm": 22.3,
"ec": 0.85
},
"rssi": -75,
"battery": 3.72
}规则引擎设计：平台侧应配置三类规则。第一类，阈值告警：如土壤水分低于25%时触发“缺水告警”。第二类，联动控制：如温度高于35℃且光照强度大于800μmol·m⁻²·s⁻¹时，自动开启遮阳网。第三类，数据质量规则：如连续3次上报数据超出合理范围（土壤水分>60%或<5%），判定为传感器故障并产生工单。
soil_前缀，所有气象站命名为ws_前缀。这样在后续数据分析、算法建模时，可以避免字段混乱。同时，要规定数据保留策略：原始数据保留至少3年，聚合数据（小时/日均值）永久保留。
2.4 执行层：执行器控制与闭环决策
核心原理：执行器是物联网的“手脚”，包括电磁阀、水泵、风机、卷帘电机、补光灯、杀虫灯等。执行器的控制方式分为三种：手动控制（通过App/Web远程开关）、定时控制（按预设时间表执行）、自动闭环控制（根据传感器数据自动触发）。在SOP中，必须明确三种模式的优先级和切换逻辑，防止冲突。
控制指令下发链路：云平台规则引擎 → 消息推送（MQTT Topic）→ 网关接收 → 网关通过RS485/继电器/GPIO控制执行器。这里的关键是指令确认机制：执行器动作后必须返回状态码（成功/失败/超时），平台侧记录操作日志，便于审计和排障。
案例拆解：智能灌溉闭环
某蔬菜基地（50亩连栋温室）部署了土壤水分传感器（埋深20cm）、水流量计和电磁阀。初始现象：番茄种植区频繁出现萎蔫，但人工巡检发现土壤表面湿润，判断为“表湿里干”。关键数据：传感器显示20cm深处土壤体积含水量仅为18%（适宜范围为25%~35%），而表层5cm处为40%。分析判断：由于滴灌带浅埋且灌溉时间短，水分未能下渗至根系层。
实际操作步骤：① 在云平台将灌溉策略从“定时定量”（每天9:00灌溉15分钟）改为“闭环控制”（当20cm土壤水分低于25%时启动灌溉，达到32%时停止）；② 设置单次最长灌溉时间30分钟作为安全上限；③ 增加水流量计校验，防止管道泄漏导致误判。结果对比：调整后一周内，番茄萎蔫现象消失，单次灌溉用水量从15m³降至9m³，节水40%。风险与代价：初期传感器数据波动导致频繁启停，后通过增加数据平滑滤波（取5分钟平均值）解决。复盘经验：闭环控制必须设置“死区”（启动阈值与停止阈值之间的差值），避免执行器频繁动作。
2.5 常见误区与总结复盘
- 误区一：重硬件轻数据。很多园区采购了大量传感器，但平台侧没有数据清洗和质控流程，导致“脏数据”进入数据库，后续分析完全不可用。SOP中应包含数据质量检查清单。
- 误区二：通信协议“一刀切”。试图用单一协议覆盖所有场景。正确做法是混合组网：大田用LoRa，设施内用WiFi，视频用4G/5G。
- 误区三：忽略网关的本地缓存能力。一旦网络故障，如果网关没有缓存，数据将永久丢失。SOP应规定网关缓存容量和补传机制。
- 误区四：执行器无反馈。只下发指令不检查执行结果，导致阀门故障时系统仍认为已开启。必须要求执行器返回状态码。