农业项目上线之后，设备装好、数据能上来了，剩下的工作通常被认为只剩运营。我们接触到的现场告诉我恰好相反：系统真正开始出问题，是从数据看上去「一切正常」的时候。
这篇文章把我这几年在现场碰到的质量问题整理成一套可做的处理办法，讲清一个点位到底有没有按时上报，探头是不是在慢慢偏，明显不合理的值怎么处置，也说清这套东西在什么情况下不成立。
农业物联网的数据质量问题通常是三种
一种是缺采，设备或者网络出了问题，数据根本没上来。一种是漂移，数据一直在上报，但探头的基准慢慢偏了。一种是越界，数值明显超出物理可能范围，却仍在正常入库。
这三种有一个共性：它们都不报警。系统的界面照样有五颜六色的曲线，告警音量照样是零。一套系统的数据从准确变成不可用，中间不会有一个明确的时刻提醒任何人，等发现的时候已经是半年后。
所以数据质量这件事，靠人偶然发现是不成立的，得让系统自己带出结论。这也是我们的农业环境监测模块里，质量判定和曲线展示是两套独立逻辑的原因。
数据缺失怎么判定：上报周期、期望到达时间与心跳
判断缺采，先要给每个点位定义它自己的上报周期。同一个农场里，水温变化慢，十五分钟一条不影响任何判断；叶面温湿度变化快，几分钟的缺口就可能错过一次通风动作。周期一旦定义清楚，缺采的判定就是算数题：按照周期推一个期望到达时间，超过约定的周期数还没有数，就标记为缺采。
这里有个反面做法值得单独说：拿上一个收到的值把缺口填上。页面确实好看，某些系统还做得更细，用插值把曲线补平。问题在于填上之后，下游没有任何一处知道这段是编的。均值被稀释，日累计偏高，报表看着完整，实际上建立在一段虚构之上。
我们最终选择了留空加标记，也就是说，图上就是要有断口。这是一个主动放弃观感的决定，代价是客户第一眼看会觉得数据不全，需要解释。换来的是任何一个看报表的人都能看见系统不知道什么。
网关离线还是探头坏了，原因要分开记
缺口本身还不够，缺的原因得跟着一起记。我们夏天碰到过一个典型场景：一个园区的网关装在配电箱里，箱内温度上到六十度上下，两个月里掉线十一次。每次掉线，下游点位全部缺口。当时的处理逻辑把缺口都按「探头异常」派了工单，维修的人到现场换了两回探头，换完数据还是缺。根因是网关过热，探头是好的。
根因不在设备，在我们把不同层级的故障压成了同一种缺口。修法是缺口带上来源：网关离线造成的整片缺口是一类，单个探头超时是另一类，供电波动导致的重启是第三类，不同的类别走不同的处理人。事后我们加的防线是，验收阶段就把这几类故障各演练一次，确认系统能分辨出来，而不是只验证「掉线会报缺口」这一个点。
传感器零点漂移怎么发现：横向对比与历史基线
阈值型告警对漂移基本无效。漂移后的值仍然落在量程里，落在正常区间里，它只是常年偏。很多项目把「探头上报超量程」当成质量监控的全部，等于把最隐蔽的一类问题放过去了。
判漂移靠比较，方向有两个。一个是横向，同一个棚、同一类型的点位放在一起看，长期偏离群体的那个先被拎出来。另一个是纵向，一个点位跟它自己历史同时段的基线比，比如跟上个月同一时刻的平均水平比。两条路径一起用，再叠加「偏离持续了多久」这个条件，可以把偶发波动排掉，剩下的就是值得去现场看一眼的。
这里有一个我认为值得争论的判断：漂移只该提示，不该由系统自动修正。技术上是能做到自动纠偏的，用群体中位数或者历史基线去校正偏移，曲线会自动恢复好看。我不做，理由是自动校正会在修正偏差的同时把真实的环境突变一起抹掉。等哪天有人要复盘「那几天棚里到底发生了什么」，事实已经被改写过了。宁可让探头带着已知偏差继续记数，并把偏差量记录在案。
顺带说一个本地经验。北方冬季棚室的内外温差大，湿度探头容易在棚膜结露的位置结雾，短时间内给出接近饱和的读数，随后回落。这类「上冲再回落」的形态在数据上很像异常值，其实是物理现象，值得保留。判断这类形态要结合同期气象和棚内通风记录一起看，单看点位曲线容易误删。我们的农业气象与墒情数据和点位数据是放在一起对照的，这类判断才做得成。
异常值怎么过滤：量程校验、跳变率与持续时间
数值过滤的判据不多，缺的常常是最笨的那一条。量程校验必须做，湿度回百分之一百二、土壤含水率跳成几百，这类值根本不该入库。第二条是跳变率，相邻两次上报之间的变化幅度超过物理上可能的速度，就值得怀疑。第三条是持续时间，它决定处置方式。
闪一下就走的值通常是通信噪声，或者采集程序在读取寄存器时的一次错位，按噪声丢弃可以，但必须留痕，不能静默消失。持续超限的值是另一回事，多数是设备本身的问题，该走告警和维修。把这两类混成一套处理，结果要么设备坏了没人知道，要么每个噪声点都报一次警，值班的人两三天就对告警免疫了。
过滤应该放在采集端还是云端
放采集端的好处是省流量省电，野外靠太阳能供电的点位尤其明显。代价是规则每改一次都要把配置推到现场，而且被丢掉的值在现场就没了，排查问题时少一层证据。
我们的划分是：采集端只做最粗的量程剔除，目的是别把明显不可能的值传上来占带宽；其余判断放云端，包括跳变率、持续时间这些依赖上下文的规则。这不是理论上最优的划分，是拿运维便利换回来的。规则的复杂度会持续变化，放在能改的那一侧更现实。也正因为如此，点位接入时上报周期和量程这些元数据必须一次配准，后面所有质量规则都建立在它们之上，这块的配置入口在设备接入管理。
设备时间戳不准会带来什么后果
有些现场设备断电重启之后时钟回到出厂日期。数值是对的，时间是错的。这批数据进库之后顺序全乱，按天统计的报表直接错位，有的日累计算出来翻倍。麻烦在于图上看起来数据很密，想不到是时间出的问题。
我们的处理是把两种时间语义分开存：网关实际收到数据的时刻，和设备自己声称的采集时刻。统计与报表只认前者，后者只用于诊断设备时钟。这条经验我认为可以迁移到任何时序场景：时间戳的可信度分级，比数值精度更值得先解决。数值差一点，报表还能用；时间错了，报表处处是错的，而且看不出来。
数据质量标记要贯穿采集、告警与报表
这套做法里最容易被做坏的地方，是质量标记只做了一半。展示层画了断口，告警判定却在用被填充过的数据视图；报表按天汇总时又把缺口当成零参与计算。任何一个环节丢掉标记，下游就全部失真，而且是安静地失真。
我们的原则是标记随数据走完全链路，同时让判定视图和展示视图分开，互不借用。判定只认真实到达的点，缺口在判定里就是缺口，不参与运算。
什么规模下这套做法不再适用
点位规模是硬边界。几十到上百个点位，逐点写规则没问题，甚至靠人每天扫曲线也能发现大部分异常。点位上千之后，逐点配规则本身就不可维护，必须把质量规则挂到设备型号或者物模型上统一生效，并且让质量标记成为每条数据自带的语义。我们目前处在从逐点向按物模型过渡的阶段，还没到可以下结论的规模，所以这一段我只能给方向，给不了实测数据。
刀口也没那么锋利。农业现场探头失准的成因很杂，有安装位置的原因，有结露和鸟啄，也有肥料腐蚀。系统能告诉你有问题，省掉的是天天盯曲线的工夫，省不掉带着标准器具到现场做一次核查。谁跟你说数据质量做好了就不用管探头，那是不成立的。
写到这儿回到我自己用了很久的一个标准，判断一套监测系统好不好，看的不是它的曲线多漂亮，而是它敢不敢告诉你哪个数它不敢用。