构建一个小农场用的土壤传感网络

我于2019年3月启动这个项目，当时有一个错误的假设：最困难的部分在于软件。到那时，我已经在企业网络和数据中心领域工作了十五年，而一个看似只需读取传感器数据并显示在屏幕上的项目，似乎只占几个晚上的时间。

结果却花了七年时间，几乎没有任何时间被用于我原本预期的方向。以下就是其中出现的问题，以及我所采取的应对措施。我写下这些内容，是因为失败往往无人记录，而正是这些失败让我付出了最大的代价。

我所关注的问题

根据土壤湿度数据而非日历来安排灌溉，可以节约用水，并保持产量稳定。这一点在文献中已有明确结论。2023年对美国农业水资源管理研究的系统性综述发现，在所有比较中均取得了节约效果，从约1%(相较于冠层温度方法)到38%(相较于传统排程)，以及20%(相较于蒸散发替代方案)。

但该技术尚未普及至小规模农场。美国政府问责办公室在2024年向国会报告称，2023年仅有27%的农场采用了精准农业技术，并指出了三个主要挑战：设备购置成本高、数据归属不明确，以及缺乏互操作性标准。美国农业部数据显示，随着农场规模增大，采用率迅速上升，而最小规模的农场则在各个类别中处于最低水平。

此外，我最初并未意识到的一个安全问题也存在。食品和农业是美国指定的关键基础设施领域，2018年国土安全部关于精准农业的一份报告指出，将农业与互联网连接显著扩大了威胁者可利用的攻击空间。

因此，目标并非更优的传感器。这是一条完整的解决方案：从地面探头到种植者可操作的数字信号，这种方案成本低廉，小规模运营即可负担，不会绑定单一供应商，也不会将所有传感器都接入互联网。

第一个问题就是：廉价的传感器。

我从大家普遍采用的方式开始，使用每块约5美元的电容式土壤湿度探头。这类设备在创客项目中随处可见，也适合在实验台上测试。但它们在与土壤接触的部位仅两到三周后就会出现腐蚀。

这一故障彻底改变了我的经济考量。在田间无人值守的节点上，一个使用寿命只有三周的部件绝非便宜之选——它意味着频繁的维护、不断更换，每次故障都会造成数据缺失。而那个5美元的探头显然成了昂贵的选择。

于是我转而采用工业级探头JXBS-3001，通过Modbus RTU协议经RS485通信，配备不锈钢针脚、环氧树脂密封外壳，防护等级达到IP68。它的价格为145美元，是故障部件价格的29倍，但却是更经济实惠的选择。

后来我发现，RS485接口带来的优势，是我原本未曾预料到的。Modbus 是一种几十年来一直稳定的工业标准，它通过 TTL 到 RS485 转换器与 ESP32 通信，完全无需任何协议处理。

第二个出问题的地方是：充电

该节点采用 LILYGO T-Beam 架构：一块板上集成了 ESP32、LoRa 无线电、GPS 和电池充电电路。按照参考设计，将太阳能板连接到内置的充电器上，就能实现自给自足的节点运行。

但我的节点无法稳定充电。

由于故障本身具有间歇性，因此需要一段时间才能找到原因。太阳能板输出会随着云层和太阳角度的变化而波动，而充电控制器需要更稳定的输入电压，而不是直接由面板提供的电流。在晴天时可以正常工作，但在阴天或多云天气下则无法充电，电池电量会逐渐下降，直到节点停止工作。

解决方案是在太阳能板与主板之间加装一个售价 8.50 美元的 Pololu 直流升压/降压调节器，为充电器提供恒定的 5 V 电压。正是这一部件，让自主运行从不可预测变为我能准确描述的数值。

我选择了带有可调低电压截止的版本，这背后有另一个重要原因。当电源故障时，电路板可能因过热而烧毁，导致写入错误状态或在看门狗无法检测到的情况下卡住。使用干净的截止设计，节点会直接关闭，直到面板恢复正常;而一个明显处于关闭状态的节点，比半工作状态的更易于设计，尤其是当你无法走到现场时。

我也测试了多个面板。大多数通用型号的输出远未达到其标称值。一个约二十厘米见方、售价十美元的Soshine 6V 6W设备，在有限光照条件下仍能提供可用电力，因此成为标准部件。

第三个出问题的地方是网关：

我的第一个网关是搭载LoRa模块的树莓派，它在桌面上运行良好，但不适合户外使用。天线输出功率太低，覆盖范围远远达不到我的需求。

2022年，我用RAK7249户外网关取代了它。测量到T-Beam节点的直线距离为5公里。该树莓派一直与之并行运行至2023年，其配置至今仍记录在我的网络服务器中，这也让我知道具体日期。

实际覆盖范围比外观看起来更重要。距离一个网关5公里处，农场一次性购买该网关，之后每个节点仅需支付节点本身的费用。这一特性使得在小规模应用中经济可行，因此无线通信层选择使用未授权频段的LoRaWAN，而非蜂窝网络。如果每个节点都配备蜂窝无线电，则意味着每个节点都需要订阅服务。

当前系统架构如下：

四层结构。

感知层：通过RS485传输Modbus RTU协议的JXBS-3001传感器、TTL转RS485适配器、搭载LiFePO4电池的ESP32芯片(安装于T-Beam板上)、经Pololu调节器供电的6瓦面板，以及仅在读取数据时将传感器电源从3.2V电池升压至5V的MT3608升压转换器。所有组件均安装在一个IP65户外箱内，箱体各穿孔处均配有IP65密封盖，并固定在桅杆上。

通讯层：LoRaWAN 1.0.3 A类，工作在US915频段，通道8至15以及65，支持空中接入，自适应数据速率，采用AES-128有效载荷加密，且每个设备拥有独立的密钥。上行链路通过RAK7249接收，并转发至运行在Docker中的ChirpStack 4.19.2网络服务器。在我的开发环境中，该服务器作为工作站，通过Cloudflare Tunnel从外部连接，因此没有开放任何端口对外部互联网。

存储层：ChirpStack负责对每帧数据进行身份认证和解密，JavaScript解码器解析42字节的有效载荷，解码后的字段则被写入InfluxDB Cloud。MongoDB Atlas用于存储用户、组织、种植园和传感器信息。

应用层：一个Node.js API提供React仪表盘服务。当API执行查询时，它会从已签名的登录令牌中获取农场的数据存储，而非直接从请求中获取，因此任何人都无法通过修改URL访问其他农场的数据。一个Flask服务使用Prophet进行单变量预测。阈值检查可在InfluxDB内部执行，每十五分钟一次检查，以及每小时一次任务通过SendGrid发送邮件。这些功能已实现，但在我的开发环境中已被关闭。

将其视为安全问题

这是我在2026年投入最多时间的部分，也最贴近我个人的职业发展。

拓扑结构首先。节点没有互联网地址，也不运行任何接受连接的服务。其固件在启动时会关闭ESP32的Wi-Fi和蓝牙功能，仅在自身发送数据后的两个短时间接收窗口内进行监听。因此，在农场中，唯一具备互联网连接的设备是网关，而添加节点并不会增加暴露面。二十个带有独立蜂窝调制解调器的传感器，相当于需要配置、监控和退役的二十个联网设备。

设备基线评估。我根据NIST IR 8259A标准，对节点进行了评估，该标准是NIST为联网设备设定的六项网络安全能力基准。其中两项满足：设备身份识别和接口逻辑访问。四项部分满足：设备配置、数据保护、软件更新和状态感知。最大的不足在于AppKey存储在闪存中未加密，任何物理接触节点的人都可以读取它;此外，固件更新未经过数字签名。

部署审查。2026年9月29日，我对正在运行的实例进行了组件参考配置的审查。除此之外，我替换掉了 ChirpStack 参考配置自带的占位符 API 密钥，将每个容器端口绑定到本地主机(除网关端口外)，移除了公共注册功能，使令牌验证失败时关闭连接，并在登录时添加了速率限制。目前仍有四项变更：预测服务仍运行在 Python 3.9 上，网关端口对整个局域网开放，InfluxDB 仅通过令牌访问，且凭据文件可被我的用户账户读取。

成本情况

一个可部署的节点价格为231.11美元。

探头的价格占总成本的63%，也就是腐蚀课程所花费的费用。这些是我实际支付的价格。网关价格为469美元，一次性购买，包含天线和备用电池，可覆盖其覆盖范围内的所有节点。

我想明确说明它能实现的功能以及无法实现的功能。集成的LoRaWAN土壤传感器售价约为145至150美元，因此每台设备的成本高于市场价，而大部分差距来自探头。差异在于成本结构的不同：没有节点需要订阅服务，持续性费用仅绑定在网关的互联网连接和服务器端，这种部署方式可在多个农场共享，因此扩展覆盖范围只增加节点本身的成本，不涉及其他部分。

什么不起作用

我宁愿自己说出来，而不是让别人去发现。

营养通道没有校准，温度和湿度是相对于参考值进行测量的。NPK(氮、磷、钾)数据未校准，且同一探头在两个不同单位中测得相同土壤的数值也不同。我读取并存储了NPK、pH和EC值，系统中的任何功能都不依赖这些数据。

节点每五十次上行通信后会自动重置，这是一种临时的解决办法。节点曾间歇性地与网络服务器失去连接，变得静默且无报警提示。我怀疑这是由于长时间运行导致的时间漂移，但尚未确认。重置会强制重新加入网络，大约每天白天每50分钟一次，从而恢复报告功能，仅缓解症状。

我之前因错误原因关闭了安全控制。在系统大部分生命周期中，服务器上的帧计数器验证功能一直被禁用，该功能可防止捕获的帧被重复播放。我以为周期性的重置会导致计数器失同步。2026年9月，当我检查固件时发现并非如此：计数器在重启后仍保存在实时时钟(RTC)内存中，每次重置都会导致新的加入，从而在双方都重新初始化计数器。我随后将验证功能开启，并于9月30日进行了测试。我学到的教训是，当你为了临时解决而关闭某个控制功能时，必须有一个测试来判断该临时方案是否不再需要。

整整一周的静默被忽视了。2026年9月23日至30日期间，节点耗尽电池电量并停止上报数据，却没有任何提示。阈值警报系统会评估读数，因此一个不发送任何数据的节点，其警报系统也就无从评估，最终这些警报自然被关闭。查询层会剔除空闲区间，所以一个沉默节点的图表就会直接结束。我是在一周后查看网络服务器时才发现这一点。接下来我要开发的功能中，静默检测是其中之一。

固件并未检查下行链路的长度。该节点最多接受五个三字节命令。版本30会将接收到的数据复制到一个三字节缓冲区中。只有网络服务器才能在设备密钥下发送下行链路，因此利用这一漏洞需要同时控制服务器或设备密钥，但这属于一个漏洞。版本31则恰好只接受三个字节的数据。目前，在撰写本文时，该版本尚未部署到任何节点上。

网关未进行身份验证，它使用Semtech的UDP数据包转发器，仅通过EUI(设备唯一标识符)来识别网关。解决方案是使用带有客户端证书的LoRa基础站，ChirpStack和RAK7249均支持该方案。我尚未将其移动。

IP65防护等级为制造商标准，而非我的测试结果。我未对已组装、钻孔并紧固密封圈的节点进行抗入侵测试，也未有节点在户外完整季节运行过。

续航时间仅以一个周期为基准测量：连续三天，每分钟上传一次数据，约六小时晴天充电。一分钟的间隔远比灌溉决策所需的时间更精细，因为土壤水分变化缓慢，较长的间隔应能显著延长续航时间。但我尚未实际测量其具体延长程度。

系统没有灌溉推荐引擎，而是报告当前环境条件，不主动告知何时需灌溉。要实现精准灌溉，必须依据土地管理指导方针验证阈值，而我在开发期间起草的这些方案仅为假设性工作，缺乏可靠来源支持。

运行情况

在厄瓜多尔瓜亚基尔市的一个封闭式温室中，使用盆栽容器，持续运行31天，共两个带传感器的监测点，种植单一作物，完成一个生长周期。从探头到无线电，再到网络服务器、云平台和仪表盘，整个流程完整运行，无需现场访问，且每五十次上行链路后自动重置，持续运行。

这是工程层面的成果，而非农学层面的成果。它展示了在受控条件下，该架构在小规模上的端到端运作情况。这并不说明在实际农场中能节约用水，我也不将其表现得好像如此。

本文编译自hackster.io