项目速览
- 行业：农业种植（冬小麦与棉花轮作）
- 交付内容：设备接入网关 + 数据平台 + 农事看板 + AI 简报生成 + 微信告警
- 周期：12 周（含 4 周设备联调）；团队 5 人 + 现场实施 1 人
- 技术栈：MQTT 接入、时序数据库、PHP 业务层、阿里云 OSS、定时任务与小程序或 Web 看板
背景
种植基地早期上了几家不同厂商的设备：土壤墒情、气象站、水肥一体机、摄像头。每家一个 App、一套账号、一份报表。技术员早上要打开四个系统抄数字，抄完手写在本子上，再决定今天灌不灌水。
更麻烦的是数据没人看：告警只推给装 App 的那个人，他一休假，整片田的预警就断了。
目标
- 数据统一：多厂商设备接入同一平台，字段对齐，历史数据可对比
- 告警可达：阈值告警进微信群，按班次推给值班人，未确认自动升级
- 决策可依：把「湿度 38%、未来 3 天无雨」翻译成「建议今晚滴灌 2 小时」
- 内容可产出：周报与对外宣传稿由 AI 生成初稿，人工校对后发布
系统结构
① 接入层
统一网关做协议适配（MQTT / HTTP 上报 / 厂商私有接口），把不同厂商的字段映射到标准模型：田块、设备、指标、时间、值。设备时钟漂移、重复上报、异常值（湿度 999）都在接入层清洗，不留给分析层兜底。
② 存储与分析
时序数据入库后按田块与设备两个维度聚合，支持「同田块同比 / 环比 / 多田块对比」。农事建议是规则引擎 + 阈值组合，不依赖模型：湿度过低 + 未来 48 小时无有效降雨 → 建议灌溉；连续阴雨 + 湿度高 → 提示病害风险。
③ AI 简报
把一周的读数变化、告警次数、农事操作记录喂给模型，生成「本周田块简报」：发生了什么、建议做什么、依据是哪几组数据。人只需要校对事实，不必从零写。对外宣传稿也是同一机制，但会增加一道人工事实核对——AI 写不出它没见过的产量。
现场实施里最花时间的部分
- 设备台账：240 台设备里，有 18 台的编号与现场标签不一致，靠人工逐台核对补齐——这部分工时不写在代码里，但必须算进预算。
- 断网补传：田间 4G 信号不稳，网关本地缓存 72 小时数据，恢复后按时间顺序补传并去重，否则曲线会出现锯齿。
- 告警疲劳：第一版阈值太敏感，一天推 60 多条，没人看。后改为「连续 N 次越界才告警 + 每日摘要 + 未确认 2 小时升级给负责人」，告警量降到每天个位数，反而被认真对待了。
结果
技术员从「早上抄四个系统」变成「看一份简报」，告警不再依赖某个人的手机；对外内容的生产从每周半天变成每周一小时校对。具体节水节肥与产量数据由基地掌握，本站不代为披露。
复盘
这个项目让我们确认了一件事：IoT 项目里「数据通」只占一半，另一半是「让人愿意看」。如果一开始就做简报和摘要，而不是先堆图表，客户的接受度会更高。
发表回复