简介这是一份围绕智慧农业物联网系统建设的完整方案文档面向农业园区规划者、设施农业工程师、物联网项目设计与投标人员重点解决温室、大田、水产养殖场景下环境精准监测、自动化控制与远程管理落地难题。内容以托普云农园区案例为蓝本覆盖无线信息采集、实时视频监控、物联网自动控制、病虫害信息采集预警和拼接屏展示等模块详细说明采集器布设、传感器耐高温高湿选型、光纤组网、24路智能控制柜配置及自动、定时、远程手动控制模式并兼顾基地平台与管理展示平台的分层建设思路提供系统性技术框架。资源为单个docx文件大小约1.01MB目前已有385人学习。若用于智慧农业园区规划、项目方案编写或设施农业课程设计可借鉴其中的系统架构、设备清单与控制逻辑减少前期调研与方案编制时间提升完整度和专业度。1. 智慧农业物联网系统建设先想清楚闭环再选设备我见过不少农业物联网项目第一批传感器装得满满当当半年后变成“电子标牌”因为只做了数据展示没有把采集和控制串成闭环。某个大棚基地就吃过亏风机继电器由人工看温度操作凌晨值班人员睡着棚温冲到 40℃一垄番茄苗全蔫。所以智慧农业物联网系统建设的第一件工作不是挑传感器而是定义闭环——从环境感知、数据传输、平台分析到设备控制哪些环节需要自动哪些只做告警。这篇文章按一条可复现的路径来讲先定架构与选型再落到硬件接入和平台配置最后给出一套验收和排错方法。适合农业园区信息化负责人、系统集成商、以及正在做物联网工程相关开发的人。2. 智慧农业物联网系统的四层架构与通信选型2.1 四层架构怎么划哪里放算力常见的做法是把系统分成感知层、传输层、平台层和应用层。感知层主要是土壤、空气、光照、二氧化碳等传感器加上采集控制器传输层解决数据怎么从地里出来包括短距离总线、低功耗广域网和互联网上行平台层负责设备管理、数据存储和规则运算应用层就是大屏、手机端、告警和控制。算力分配要看现场条件。大棚里供电方便可以在每个大棚放一个边缘网关用 Modbus RS485 把所有传感器串起来网关做轮询采集和阈值判断即使断网也能本地启停风机。大田地块分散、没有市电就要用电池供电的低功耗节点尽量只在数据变化超过门限时上报把算力放到云端。养殖舍环境相对集中但氨气、硫化氢这些气体传感器需要频繁校准通常把校准算法放在边缘云端只收趋势数据。另外无源物联网这两年慢慢从实验室走向试点利用环境能量采集给传感器供电对果园这种不便布线的场景很有吸引力但目前成熟度和成本还不适合作为主方案。2.2 传输层三种组网方式怎么选传输层是很多项目烂尾的重灾区。我一般会根据供电条件和地块面积来选。这里有一个常用的对比表组网方式典型设备覆盖范围功耗带宽/时延适用场景WiFiESP32 路由器/AP几十米中高/低大棚群、园区办公区LoRaLoRa 节点 网关1~5 公里低低/高大田、果园、分散地块NB-IoTNB 模块 运营商基站广域低低/中无网关覆盖的偏远田块4GDTU/工业网关广域中高中/低视频监控、实时控制WiFi 方案优点是开发调试快ESP32 生态成熟做环境监测的小规模试点基本一天就能跑通。LoRa 适合自己建网关、想长期不换电池的场景但要注意网关高度和天线位置2 米和 6 米高度覆盖差很多。NB-IoT 不需要自建网关但要注意运营商网络覆盖尤其是地下温室或半地下大棚信号可能很弱。4G 成本最高通常是给视频或大流量传感器用的。2.3 平台层选型的两个方向自建 Broker 还是用公有云平台层现在有两个主流方向。一种是自建消息服务典型的组合是 EMQX 时序数据库 Grafana适合对数据主权要求高、有运维能力的团队。另一种是接入公有云物联网平台平台自带设备影子、规则引擎和应用 SDK开发快但要考虑连接数计费和平台生命周期问题。我一般这样选项目节点数少于 200、现场有能跑 Docker 的工控机就自建超过 500 或需要多个基地跨地域接入优先用公有云。如果已选定的公有云平台停止新购迁到自建 EMQX 或者换一家云平台是常规操作迁移的主要工作量在设备端连接配置、Topic 映射和告警规则JSON 报文规范如果一开始就定义好这部分能省不少时间。自建时我用 Docker 起一个 EMQX 实例命令固定为docker run -d --name emqx \ -p 1883:1883 -p 8083:8083 -p 18083:18083 \ emqx:5.0端口 1883 是 MQTT 设备接入端口8083 是 WebSocket 端口给浏览器里的可视化大屏用18083 是管理控制台端口。启动后先登录控制台创建用户名密码并关闭匿名接入否则公网上的扫描器会不断尝试连接。镜像标签5.0按实际可用版本调整但建议固定大版本避免小版本升级带来行为差异。3. 感知层与传输层落地传感器配置、网关接入与数据上云3.1 传感器选型与接线从 RS485 到 I2C典型的大棚监测参数包括空气温湿度、土壤温度水分、光照强度和二氧化碳。下面是我常用的一组传感器选型参考传感器接口供电精度参考成本档位空气温湿度 SHT30I2C3.3V温度 ±0.3℃湿度 ±2%RH低土壤温度水分探头RS485/Modbus12V水分 ±2%中光照强度 BH1750I2C3.3V1~65535 lx低CO2 MH-Z19串口 UART5V±50ppm 读数的3%中土壤传感器多数是 RS485 接口、走 Modbus 协议空气温湿度用 I2C 的 SHT30 很划算光照用 BH1750CO2 用串口型 MH-Z19。接线时注意 RS485 是半双工总线A/B 线不能接反总线末端建议加 120Ω 终端电阻。一个采集节点上 IO 不够时可以用 TCA9548A I2C 多路开关扩展或者用 ULN2003A 驱动继电器避免 GPIO 直驱大功率设备。这些细节在基于 ESP32 的物联网环境监测项目里经常会踩坑。3.2 基于 ESP32 的采集节点代码框架先给一个最小可跑的 Arduino 代码框架采集空气温湿度并通过 MQTT 上报#include WiFi.h #include PubSubClient.h #include Wire.h #include Adafruit_SHT31.h Adafruit_SHT31 sht31 Adafruit_SHT31(); const char* ssid your_ssid; const char* password your_password; const char* mqtt_server your_broker_ip; const int mqtt_port 1883; WiFiClient espClient; PubSubClient client(espClient); char payload[128]; void setup() { Serial.begin(115200); Wire.begin(21, 22); // SDA, SCL if (!sht31.begin(0x44)) { Serial.println(SHT31 not found); } WiFi.begin(ssid, password); while (WiFi.status() ! WL_CONNECTED) { delay(500); } client.setServer(mqtt_server, mqtt_port); } void loop() { if (!client.connected()) { reconnect(); } client.loop(); float t sht31.readTemperature(); float h sht31.readHumidity(); if (isnan(t) || isnan(h)) return; snprintf(payload, sizeof(payload), {\temp\:%.2f,\hum\:%.2f}, t, h); client.publish(agri/greenhouse/01/env, payload); delay(10000); } void reconnect() { while (!client.connected()) { if (client.connect(esp32-gw-01)) { client.subscribe(agri/greenhouse/01/cmd); } else { delay(5000); } } }这段代码的逻辑是上电连接 WiFi创建 MQTT 客户端每 10 秒读一次 SHT31将温度湿度打包成 JSON发布到agri/greenhouse/01/env同时订阅cmd主题用于接收云端或网关下发的控制指令。注意client.connect(esp32-gw-01)里的 clientId 必须保证在同一 Broker 内唯一否则后连接的设备会顶掉前一个。如果后期要接多个传感器可以在同一个loop里把读数和发布拆成两个任务避免串行阻塞造成上报周期抖动比如用millis()做一个非阻塞的定时器。3.3 网关协议转换用 Python 脚本把 Modbus 数据转成 JSON大棚里如果有多路 RS485 设备直接用 ESP32 写轮询逻辑会很啰嗦。常见做法是让边缘网关比如工控机或树莓派用 pymodbus 轮询再统一以 MQTT 上送。下面是一个简化的读取循环import time import json import pymodbus.client as ModbusClient import paho.mqtt.client as mqtt # 连接 Modbus 从站设备串口 /dev/ttyUSB0波特率 9600 client ModbusClient.ModbusSerialClient( port/dev/ttyUSB0, baudrate9600, parityN, stopbits1, timeout1 ) client.connect() def read_sensor(addr, reg, count2): rr client.read_input_registers(reg, count, slaveaddr) if rr.isError(): return None # 两个寄存器拼成一个 32 位无符号数 return (rr.registers[0] 16) | rr.registers[1]代码里read_input_registers的第三个参数slave是从站地址需要在传感器配置和拨码开关上对应寄存器地址要查传感器手册比如土壤水分的寄存器是0x0006、温度是0x0007。拿到原始值后按手册里的量程公式换算成物理量再和其他传感器数据合并封装成 JSON 上报。这里的timeout1不能设得太小RS485 总线上设备越多轮询周期越长把超时设到 1.5 秒更稳妥。对于快速原型把 Modbus 转 MQTT 的网关也可以用 Node-RED 的 Modbus 节点拼出来但在字段较多、需要做单位换算的场合写脚本比拖节点更可控。3.4 LoRa/NB-IoT 模块的上报参数怎么配如果节点用 LoRa节点和网关要约定频点、扩频因子和带宽。常见的配置是 470MHz 频段、SF7、125kHz 带宽对应速率高、功耗低适合大棚这种近距离远距离大田可以用 SF10 以上但单包传输时间变长要注意不能超出当地无线电管理的占空比限制。LoRa 数据包建议控制在 64 字节以内JSON 要尽量压缩字段名和精度。NB-IoT 模块用 AT 指令连接网络时常见流程如下ATCFUN1 // 开启射频 ATCGATT1 // 附着网络 ATCEREG? // 查询注册状态返回值 1 或 5 表示已注册 ATQMTCFGrecv/mode,0,0,1 ATQMTOPEN0,your_broker_ip,1883 // 打开 MQTT 连接 ATQMTCONN0,nb-device-01 // 建立连接 ATQMTPUB0,0,0,0,agri/field/02/env // 发布主题 数据内容每个 AT 指令都有时序要求ATCGATT1之后要轮询ATCEREG?确认网络注册成功再去做 MQTT 连接否则会报错。如果模块连不上平台先发ATCSQ查信号强度返回值小于 10 基本就是信号问题要换天线位置或改外置天线。注意ATQMTPUB里的数据内容在发布结束要以十六进制方式发送结束符具体看模块手册写程序时不要漏掉这一步。4. 平台层与应用层建设数据入库、规则引擎与可视化4.1 Topic 设计与 JSON 报文规范设备接入前要先把 Topic 树定下来否则每加一种设备就要改一次代码。我用的规范是agri/{基地编号}/{棚号}/{节点类型}/{功能}比如下面这样Topic方向用途agri/001/G01/env/upload设备→平台上报环境数据agri/001/G01/cmd平台→设备下发控制指令agri/001/G01/alarm设备→平台上报告警事件agri/001/G01/config平台→设备参数配置下发JSON 统一用扁平结构方便规则引擎直接取字段{ time: 2025-01-15T10:30:0008:00, temp: 25.6, hum: 68.2, soil_moisture: 35.1, co2: 812, lux: 23000 }时间戳必须带时区字段名用小写加下划线单位固定温度摄氏度、湿度百分比、CO2 ppm、光照 lux。这样后面做数据清洗和建模时不用猜单位。还要约定异常值表达方式比如上报失败时用null而不是 0因为 0 在农业气象里是有意义的数值会把后续阈值判断带偏。4.2 数据入库MySQL 时序表与 InfluxDB 的取舍数据量不大时MySQL 也能扛住。一个 200 节点的基地每 5 分钟上报一条一天约 5.7 万条记录分区表加索引足够。下面的建表语句按天分区CREATE TABLE agri_env ( id bigint NOT NULL AUTO_INCREMENT, base_id varchar(16) NOT NULL, greenhouse_id varchar(16) NOT NULL, node_id varchar(32) NOT NULL, temp decimal(5,2) DEFAULT NULL, hum decimal(5,2) DEFAULT NULL, soil_moisture decimal(5,2) DEFAULT NULL, co2 int DEFAULT NULL, lux int DEFAULT NULL, event_time datetime NOT NULL, PRIMARY KEY (id,event_time), KEY idx_device_time (node_id,event_time) ) PARTITION BY RANGE (TO_DAYS(event_time)) (PARTITION p_start VALUES LESS THAN (TO_DAYS(2025-01-01)));这个表按event_time做 RANGE 分区之后可以定期用ALTER TABLE agri_env DROP PARTITION p_old删除过期数据避免 DELETE 造成大事务。如果以后要按天做多维聚合或者原始数据吞吐超过每秒几千条再换成 InfluxDB 这类时序库。InfluxDB 里建议用一个 measurement 存所有环境量tag 存base_id, greenhouse_id, node_idfield 存数值时间戳用纳秒。注意不要把设备名放 fieldtag 才适合做过滤条件否则查询会把所有序列都扫一遍。4.3 规则引擎阈值告警与自动控制逻辑4.3.1 边缘规则与云端规则的分工自动控制指令必须放在边缘因为云端链路一旦中断温控不能等。比如大棚温度超过 32℃ 启动风机边缘网关只需一条判断if (temp 32) gpio_on(FAN)云端规则适合做告警和联动比如连续 30 分钟土壤湿度低于 30% 时触发浇水建议。边缘规则要加“回差”比如温度降到 28℃ 才停风机避免继电器频繁吸合烧坏触点。云端规则用 Node-RED 或云平台规则引擎都能做。下面是一个等价的 Python 异步处理片段async def handle_env(msg): data json.loads(msg.payload) # 取最近 6 次上报即半小时窗口 history await get_history(data[node_id], 6) avg_hum sum(h[soil_moisture] for h in history) / len(history) if avg_hum 30 and data[soil_moisture] 30: await alarm_service.send(data[base_id], data[greenhouse_id], soil_dry, avg_hum)这里的get_history从 Redis 或数据库读取最近记录alarm_service.send负责把告警推到钉钉群或短信。注意云端的轮询窗口要考虑上报延迟和网络抖动不要用严格的“连续 N 分钟”去卡给一点容差比如允许 6 次里有 1 次缺失。还可以加最大次数限制防止告警风暴。4.4 可视化面板与告警推送的连通数据入库后给园区负责人看的东西决定项目能不能继续。Grafana 连 MySQL 或 InfluxDB 做监控大屏很成熟仪表盘按棚选时间范围展示温湿度曲线、土壤水分热力图。配置数据源时要设置min interval为 1m避免用户把时间范围拉太长导致数据库聚合出大量点数。告警推送到手机低成本方案是用钉钉或企业微信的自定义机器人 Webhook。规则引擎触发时 POST 一条 JSON 到 webhook 地址即可。注意限制频率同一设备同一告警类型 10 分钟内最多推一次否则凌晨连续抖动会让值班人员直接关掉告警。这里有一个简单的频率限制逻辑last_alarm cache.get(falarm:{node}:{alarm_type}) if last_alarm and time.time() - last_alarm 600: return cache.set(falarm:{node}:{alarm_type}, time.time(), ex600)cache可以用 Redis 或内存缓存600是秒数。告警文案里要带时间、棚号、当前值和动作建议不要只发一个“湿度低”。5. 从试点到复制智慧农业物联网系统建设的验收与排错5.1 最小闭环验证感知-上报-告警-控制一次跑通新装完一个棚先不要急着铺开。我会做这样的闭环测试把温度传感器握在手心等待 3 秒确认平台上温度曲线上升然后人为把阈值改到当前温度以上 1℃观察风机是否在 10 秒内启动最后把土壤传感器用湿布包住确认浇水电磁阀动作。这个测试同时验证了传感器精度、网关上报链路、云端规则和边缘控制任何一环卡住都能当场定位。5.2 设备离线与数据漂移的排查步骤设备离线先判断是“没上报”还是“上报失败”。命令行里用 MQTT 客户端订阅主题很快能看清mosquitto_sub -h your_broker_ip -t agri/001//env/upload -v如果能收到数据说明设备、网络、Broker 都没问题问题在平台接入或存储如果收不到再用tcpdump -i eth0 port 1883抓包看 TCP 握手和 MQTT PUBLISH 包确认数据是否到达网关。下面是一张常用排查表现象可能原因先查什么设备全部离线网关断电或网络中断检查交换机、SIM 卡流量单节点离线电源或天线信号弱查该节点供电和 RSSI有发布无存储平台订阅 Topic 不匹配查规则引擎的 Topic 过滤数据跳动大传感器进水或接线干扰查接线端子、屏蔽层接地数据漂移常见于土壤水分传感器长期埋在土里电极附近离子浓度变化导致读数偏高。每两个月把传感器洗净晾干在空气中读数再与标准盐溶液标定把偏移量写入边缘网关的补偿系数。5.3 参数整定上报频率、阈值回差与校准上报频率不是越快越好。大棚环境变化慢5 分钟一次足够极端天气时云端可以临时下发interval命令让节点加密上报事后再恢复。发布主题约定为agri/001/G01/cmd/intervalpayload 是一个 JSON 对象节点收到后修改自己的上报周期。阈值回差方面风机启动温度 32℃、停止 28℃温差至少 4℃否则继电器动作会过于频繁。CO2 与光照联动时要考虑控制顺序先补光再放风还是先通风再补光不同季节不一样。5.4 规模化复制时的网络规划要点从 1 个棚复制到 50 个棚时LoRa 网关要按扇区布局两个网关之间间隔保持在覆盖半径的三分之二以内避免边缘设备频繁切换每个网关建议最多挂 200 个节点并按位置分配不同的扩频因子同频发送时用不同信道错峰。WiFi 方案在大棚复制时别把所有 AP 都设成同一信道用 1、6、11 三个信道隔开。NB-IoT 节点要注意物联网卡的流量套餐按上报间隔估算单节点月流量一般 30 分钟一条、每天几十 KB 就够不用买大流量包。上线前最后一遍验收我习惯把这张表打印出来逐项打勾检查项达标标准设备在线率大于 98%数据延迟小于 30 秒控制指令时延小于 5 秒告警准确率连续 7 天无重复误报每一项都能量化才能判断系统是真正在干活还是只是“看起来在干活”。安装调试人员在现场按表执行比盯着平台看曲线更容易发现设备层面的隐患。本文还有配套的精品资源点击获取 智慧农业物联网系统建设：从架构设计到落地验收完整指南
简介这是一份围绕智慧农业物联网系统建设的完整方案文档面向农业园区规划者、设施农业工程师、物联网项目设计与投标人员重点解决温室、大田、水产养殖场景下环境精准监测、自动化控制与远程管理落地难题。内容以托普云农园区案例为蓝本覆盖无线信息采集、实时视频监控、物联网自动控制、病虫害信息采集预警和拼接屏展示等模块详细说明采集器布设、传感器耐高温高湿选型、光纤组网、24路智能控制柜配置及自动、定时、远程手动控制模式并兼顾基地平台与管理展示平台的分层建设思路提供系统性技术框架。资源为单个docx文件大小约1.01MB目前已有385人学习。若用于智慧农业园区规划、项目方案编写或设施农业课程设计可借鉴其中的系统架构、设备清单与控制逻辑减少前期调研与方案编制时间提升完整度和专业度。1. 智慧农业物联网系统建设先想清楚闭环再选设备我见过不少农业物联网项目第一批传感器装得满满当当半年后变成“电子标牌”因为只做了数据展示没有把采集和控制串成闭环。某个大棚基地就吃过亏风机继电器由人工看温度操作凌晨值班人员睡着棚温冲到 40℃一垄番茄苗全蔫。所以智慧农业物联网系统建设的第一件工作不是挑传感器而是定义闭环——从环境感知、数据传输、平台分析到设备控制哪些环节需要自动哪些只做告警。这篇文章按一条可复现的路径来讲先定架构与选型再落到硬件接入和平台配置最后给出一套验收和排错方法。适合农业园区信息化负责人、系统集成商、以及正在做物联网工程相关开发的人。2. 智慧农业物联网系统的四层架构与通信选型2.1 四层架构怎么划哪里放算力常见的做法是把系统分成感知层、传输层、平台层和应用层。感知层主要是土壤、空气、光照、二氧化碳等传感器加上采集控制器传输层解决数据怎么从地里出来包括短距离总线、低功耗广域网和互联网上行平台层负责设备管理、数据存储和规则运算应用层就是大屏、手机端、告警和控制。算力分配要看现场条件。大棚里供电方便可以在每个大棚放一个边缘网关用 Modbus RS485 把所有传感器串起来网关做轮询采集和阈值判断即使断网也能本地启停风机。大田地块分散、没有市电就要用电池供电的低功耗节点尽量只在数据变化超过门限时上报把算力放到云端。养殖舍环境相对集中但氨气、硫化氢这些气体传感器需要频繁校准通常把校准算法放在边缘云端只收趋势数据。另外无源物联网这两年慢慢从实验室走向试点利用环境能量采集给传感器供电对果园这种不便布线的场景很有吸引力但目前成熟度和成本还不适合作为主方案。2.2 传输层三种组网方式怎么选传输层是很多项目烂尾的重灾区。我一般会根据供电条件和地块面积来选。这里有一个常用的对比表组网方式典型设备覆盖范围功耗带宽/时延适用场景WiFiESP32 路由器/AP几十米中高/低大棚群、园区办公区LoRaLoRa 节点 网关1~5 公里低低/高大田、果园、分散地块NB-IoTNB 模块 运营商基站广域低低/中无网关覆盖的偏远田块4GDTU/工业网关广域中高中/低视频监控、实时控制WiFi 方案优点是开发调试快ESP32 生态成熟做环境监测的小规模试点基本一天就能跑通。LoRa 适合自己建网关、想长期不换电池的场景但要注意网关高度和天线位置2 米和 6 米高度覆盖差很多。NB-IoT 不需要自建网关但要注意运营商网络覆盖尤其是地下温室或半地下大棚信号可能很弱。4G 成本最高通常是给视频或大流量传感器用的。2.3 平台层选型的两个方向自建 Broker 还是用公有云平台层现在有两个主流方向。一种是自建消息服务典型的组合是 EMQX 时序数据库 Grafana适合对数据主权要求高、有运维能力的团队。另一种是接入公有云物联网平台平台自带设备影子、规则引擎和应用 SDK开发快但要考虑连接数计费和平台生命周期问题。我一般这样选项目节点数少于 200、现场有能跑 Docker 的工控机就自建超过 500 或需要多个基地跨地域接入优先用公有云。如果已选定的公有云平台停止新购迁到自建 EMQX 或者换一家云平台是常规操作迁移的主要工作量在设备端连接配置、Topic 映射和告警规则JSON 报文规范如果一开始就定义好这部分能省不少时间。自建时我用 Docker 起一个 EMQX 实例命令固定为docker run -d --name emqx \ -p 1883:1883 -p 8083:8083 -p 18083:18083 \ emqx:5.0端口 1883 是 MQTT 设备接入端口8083 是 WebSocket 端口给浏览器里的可视化大屏用18083 是管理控制台端口。启动后先登录控制台创建用户名密码并关闭匿名接入否则公网上的扫描器会不断尝试连接。镜像标签5.0按实际可用版本调整但建议固定大版本避免小版本升级带来行为差异。3. 感知层与传输层落地传感器配置、网关接入与数据上云3.1 传感器选型与接线从 RS485 到 I2C典型的大棚监测参数包括空气温湿度、土壤温度水分、光照强度和二氧化碳。下面是我常用的一组传感器选型参考传感器接口供电精度参考成本档位空气温湿度 SHT30I2C3.3V温度 ±0.3℃湿度 ±2%RH低土壤温度水分探头RS485/Modbus12V水分 ±2%中光照强度 BH1750I2C3.3V1~65535 lx低CO2 MH-Z19串口 UART5V±50ppm 读数的3%中土壤传感器多数是 RS485 接口、走 Modbus 协议空气温湿度用 I2C 的 SHT30 很划算光照用 BH1750CO2 用串口型 MH-Z19。接线时注意 RS485 是半双工总线A/B 线不能接反总线末端建议加 120Ω 终端电阻。一个采集节点上 IO 不够时可以用 TCA9548A I2C 多路开关扩展或者用 ULN2003A 驱动继电器避免 GPIO 直驱大功率设备。这些细节在基于 ESP32 的物联网环境监测项目里经常会踩坑。3.2 基于 ESP32 的采集节点代码框架先给一个最小可跑的 Arduino 代码框架采集空气温湿度并通过 MQTT 上报#include WiFi.h #include PubSubClient.h #include Wire.h #include Adafruit_SHT31.h Adafruit_SHT31 sht31 Adafruit_SHT31(); const char* ssid your_ssid; const char* password your_password; const char* mqtt_server your_broker_ip; const int mqtt_port 1883; WiFiClient espClient; PubSubClient client(espClient); char payload[128]; void setup() { Serial.begin(115200); Wire.begin(21, 22); // SDA, SCL if (!sht31.begin(0x44)) { Serial.println(SHT31 not found); } WiFi.begin(ssid, password); while (WiFi.status() ! WL_CONNECTED) { delay(500); } client.setServer(mqtt_server, mqtt_port); } void loop() { if (!client.connected()) { reconnect(); } client.loop(); float t sht31.readTemperature(); float h sht31.readHumidity(); if (isnan(t) || isnan(h)) return; snprintf(payload, sizeof(payload), {\temp\:%.2f,\hum\:%.2f}, t, h); client.publish(agri/greenhouse/01/env, payload); delay(10000); } void reconnect() { while (!client.connected()) { if (client.connect(esp32-gw-01)) { client.subscribe(agri/greenhouse/01/cmd); } else { delay(5000); } } }这段代码的逻辑是上电连接 WiFi创建 MQTT 客户端每 10 秒读一次 SHT31将温度湿度打包成 JSON发布到agri/greenhouse/01/env同时订阅cmd主题用于接收云端或网关下发的控制指令。注意client.connect(esp32-gw-01)里的 clientId 必须保证在同一 Broker 内唯一否则后连接的设备会顶掉前一个。如果后期要接多个传感器可以在同一个loop里把读数和发布拆成两个任务避免串行阻塞造成上报周期抖动比如用millis()做一个非阻塞的定时器。3.3 网关协议转换用 Python 脚本把 Modbus 数据转成 JSON大棚里如果有多路 RS485 设备直接用 ESP32 写轮询逻辑会很啰嗦。常见做法是让边缘网关比如工控机或树莓派用 pymodbus 轮询再统一以 MQTT 上送。下面是一个简化的读取循环import time import json import pymodbus.client as ModbusClient import paho.mqtt.client as mqtt # 连接 Modbus 从站设备串口 /dev/ttyUSB0波特率 9600 client ModbusClient.ModbusSerialClient( port/dev/ttyUSB0, baudrate9600, parityN, stopbits1, timeout1 ) client.connect() def read_sensor(addr, reg, count2): rr client.read_input_registers(reg, count, slaveaddr) if rr.isError(): return None # 两个寄存器拼成一个 32 位无符号数 return (rr.registers[0] 16) | rr.registers[1]代码里read_input_registers的第三个参数slave是从站地址需要在传感器配置和拨码开关上对应寄存器地址要查传感器手册比如土壤水分的寄存器是0x0006、温度是0x0007。拿到原始值后按手册里的量程公式换算成物理量再和其他传感器数据合并封装成 JSON 上报。这里的timeout1不能设得太小RS485 总线上设备越多轮询周期越长把超时设到 1.5 秒更稳妥。对于快速原型把 Modbus 转 MQTT 的网关也可以用 Node-RED 的 Modbus 节点拼出来但在字段较多、需要做单位换算的场合写脚本比拖节点更可控。3.4 LoRa/NB-IoT 模块的上报参数怎么配如果节点用 LoRa节点和网关要约定频点、扩频因子和带宽。常见的配置是 470MHz 频段、SF7、125kHz 带宽对应速率高、功耗低适合大棚这种近距离远距离大田可以用 SF10 以上但单包传输时间变长要注意不能超出当地无线电管理的占空比限制。LoRa 数据包建议控制在 64 字节以内JSON 要尽量压缩字段名和精度。NB-IoT 模块用 AT 指令连接网络时常见流程如下ATCFUN1 // 开启射频 ATCGATT1 // 附着网络 ATCEREG? // 查询注册状态返回值 1 或 5 表示已注册 ATQMTCFGrecv/mode,0,0,1 ATQMTOPEN0,your_broker_ip,1883 // 打开 MQTT 连接 ATQMTCONN0,nb-device-01 // 建立连接 ATQMTPUB0,0,0,0,agri/field/02/env // 发布主题 数据内容每个 AT 指令都有时序要求ATCGATT1之后要轮询ATCEREG?确认网络注册成功再去做 MQTT 连接否则会报错。如果模块连不上平台先发ATCSQ查信号强度返回值小于 10 基本就是信号问题要换天线位置或改外置天线。注意ATQMTPUB里的数据内容在发布结束要以十六进制方式发送结束符具体看模块手册写程序时不要漏掉这一步。4. 平台层与应用层建设数据入库、规则引擎与可视化4.1 Topic 设计与 JSON 报文规范设备接入前要先把 Topic 树定下来否则每加一种设备就要改一次代码。我用的规范是agri/{基地编号}/{棚号}/{节点类型}/{功能}比如下面这样Topic方向用途agri/001/G01/env/upload设备→平台上报环境数据agri/001/G01/cmd平台→设备下发控制指令agri/001/G01/alarm设备→平台上报告警事件agri/001/G01/config平台→设备参数配置下发JSON 统一用扁平结构方便规则引擎直接取字段{ time: 2025-01-15T10:30:0008:00, temp: 25.6, hum: 68.2, soil_moisture: 35.1, co2: 812, lux: 23000 }时间戳必须带时区字段名用小写加下划线单位固定温度摄氏度、湿度百分比、CO2 ppm、光照 lux。这样后面做数据清洗和建模时不用猜单位。还要约定异常值表达方式比如上报失败时用null而不是 0因为 0 在农业气象里是有意义的数值会把后续阈值判断带偏。4.2 数据入库MySQL 时序表与 InfluxDB 的取舍数据量不大时MySQL 也能扛住。一个 200 节点的基地每 5 分钟上报一条一天约 5.7 万条记录分区表加索引足够。下面的建表语句按天分区CREATE TABLE agri_env ( id bigint NOT NULL AUTO_INCREMENT, base_id varchar(16) NOT NULL, greenhouse_id varchar(16) NOT NULL, node_id varchar(32) NOT NULL, temp decimal(5,2) DEFAULT NULL, hum decimal(5,2) DEFAULT NULL, soil_moisture decimal(5,2) DEFAULT NULL, co2 int DEFAULT NULL, lux int DEFAULT NULL, event_time datetime NOT NULL, PRIMARY KEY (id,event_time), KEY idx_device_time (node_id,event_time) ) PARTITION BY RANGE (TO_DAYS(event_time)) (PARTITION p_start VALUES LESS THAN (TO_DAYS(2025-01-01)));这个表按event_time做 RANGE 分区之后可以定期用ALTER TABLE agri_env DROP PARTITION p_old删除过期数据避免 DELETE 造成大事务。如果以后要按天做多维聚合或者原始数据吞吐超过每秒几千条再换成 InfluxDB 这类时序库。InfluxDB 里建议用一个 measurement 存所有环境量tag 存base_id, greenhouse_id, node_idfield 存数值时间戳用纳秒。注意不要把设备名放 fieldtag 才适合做过滤条件否则查询会把所有序列都扫一遍。4.3 规则引擎阈值告警与自动控制逻辑4.3.1 边缘规则与云端规则的分工自动控制指令必须放在边缘因为云端链路一旦中断温控不能等。比如大棚温度超过 32℃ 启动风机边缘网关只需一条判断if (temp 32) gpio_on(FAN)云端规则适合做告警和联动比如连续 30 分钟土壤湿度低于 30% 时触发浇水建议。边缘规则要加“回差”比如温度降到 28℃ 才停风机避免继电器频繁吸合烧坏触点。云端规则用 Node-RED 或云平台规则引擎都能做。下面是一个等价的 Python 异步处理片段async def handle_env(msg): data json.loads(msg.payload) # 取最近 6 次上报即半小时窗口 history await get_history(data[node_id], 6) avg_hum sum(h[soil_moisture] for h in history) / len(history) if avg_hum 30 and data[soil_moisture] 30: await alarm_service.send(data[base_id], data[greenhouse_id], soil_dry, avg_hum)这里的get_history从 Redis 或数据库读取最近记录alarm_service.send负责把告警推到钉钉群或短信。注意云端的轮询窗口要考虑上报延迟和网络抖动不要用严格的“连续 N 分钟”去卡给一点容差比如允许 6 次里有 1 次缺失。还可以加最大次数限制防止告警风暴。4.4 可视化面板与告警推送的连通数据入库后给园区负责人看的东西决定项目能不能继续。Grafana 连 MySQL 或 InfluxDB 做监控大屏很成熟仪表盘按棚选时间范围展示温湿度曲线、土壤水分热力图。配置数据源时要设置min interval为 1m避免用户把时间范围拉太长导致数据库聚合出大量点数。告警推送到手机低成本方案是用钉钉或企业微信的自定义机器人 Webhook。规则引擎触发时 POST 一条 JSON 到 webhook 地址即可。注意限制频率同一设备同一告警类型 10 分钟内最多推一次否则凌晨连续抖动会让值班人员直接关掉告警。这里有一个简单的频率限制逻辑last_alarm cache.get(falarm:{node}:{alarm_type}) if last_alarm and time.time() - last_alarm 600: return cache.set(falarm:{node}:{alarm_type}, time.time(), ex600)cache可以用 Redis 或内存缓存600是秒数。告警文案里要带时间、棚号、当前值和动作建议不要只发一个“湿度低”。5. 从试点到复制智慧农业物联网系统建设的验收与排错5.1 最小闭环验证感知-上报-告警-控制一次跑通新装完一个棚先不要急着铺开。我会做这样的闭环测试把温度传感器握在手心等待 3 秒确认平台上温度曲线上升然后人为把阈值改到当前温度以上 1℃观察风机是否在 10 秒内启动最后把土壤传感器用湿布包住确认浇水电磁阀动作。这个测试同时验证了传感器精度、网关上报链路、云端规则和边缘控制任何一环卡住都能当场定位。5.2 设备离线与数据漂移的排查步骤设备离线先判断是“没上报”还是“上报失败”。命令行里用 MQTT 客户端订阅主题很快能看清mosquitto_sub -h your_broker_ip -t agri/001//env/upload -v如果能收到数据说明设备、网络、Broker 都没问题问题在平台接入或存储如果收不到再用tcpdump -i eth0 port 1883抓包看 TCP 握手和 MQTT PUBLISH 包确认数据是否到达网关。下面是一张常用排查表现象可能原因先查什么设备全部离线网关断电或网络中断检查交换机、SIM 卡流量单节点离线电源或天线信号弱查该节点供电和 RSSI有发布无存储平台订阅 Topic 不匹配查规则引擎的 Topic 过滤数据跳动大传感器进水或接线干扰查接线端子、屏蔽层接地数据漂移常见于土壤水分传感器长期埋在土里电极附近离子浓度变化导致读数偏高。每两个月把传感器洗净晾干在空气中读数再与标准盐溶液标定把偏移量写入边缘网关的补偿系数。5.3 参数整定上报频率、阈值回差与校准上报频率不是越快越好。大棚环境变化慢5 分钟一次足够极端天气时云端可以临时下发interval命令让节点加密上报事后再恢复。发布主题约定为agri/001/G01/cmd/intervalpayload 是一个 JSON 对象节点收到后修改自己的上报周期。阈值回差方面风机启动温度 32℃、停止 28℃温差至少 4℃否则继电器动作会过于频繁。CO2 与光照联动时要考虑控制顺序先补光再放风还是先通风再补光不同季节不一样。5.4 规模化复制时的网络规划要点从 1 个棚复制到 50 个棚时LoRa 网关要按扇区布局两个网关之间间隔保持在覆盖半径的三分之二以内避免边缘设备频繁切换每个网关建议最多挂 200 个节点并按位置分配不同的扩频因子同频发送时用不同信道错峰。WiFi 方案在大棚复制时别把所有 AP 都设成同一信道用 1、6、11 三个信道隔开。NB-IoT 节点要注意物联网卡的流量套餐按上报间隔估算单节点月流量一般 30 分钟一条、每天几十 KB 就够不用买大流量包。上线前最后一遍验收我习惯把这张表打印出来逐项打勾检查项达标标准设备在线率大于 98%数据延迟小于 30 秒控制指令时延小于 5 秒告警准确率连续 7 天无重复误报每一项都能量化才能判断系统是真正在干活还是只是“看起来在干活”。安装调试人员在现场按表执行比盯着平台看曲线更容易发现设备层面的隐患。本文还有配套的精品资源点击获取