1. 需求到底在哪把粮仓监测这件事想明白再动手1.1 粮堆内部的三类风险决定了要测什么粮仓这行外人看着简单几万吨粮食堆在仓里平时也没人动。但真正在粮库待过的人都知道最麻烦的是那种看不见的变化。粮堆是个活的体系粮食本身在呼吸微生物在活动外界气温一波动内部的热量和水汽就开始重新分布。这种变化在表层看不出来等你站在仓门口闻到霉味往往已经晚了半个月。归结起来智慧粮仓监测系统真正要盯的是三类东西。第一类是粮堆内部的温度分层因为热量是从中心或者局部开始积累的单一测点的数值没有意义只有纵向分层的温度曲线才能反映趋势。第二类是仓内空气的温湿度它决定了粮堆表层会不会结露结露是霉变的直接诱因。第三类是环境与设备的联动状态比如通风机、环流熏蒸设备在什么条件下该开、开多久这决定了监测数据到底只是看还是能用。这三类需求对应到硬件上就是粮堆内部测温电缆、仓内温湿度传感器、以及外部环境气象站三套采集体系。很多人做方案的时候只做了第一类结果系统上线后粮库的人看了一眼就不用了因为它回答不了我要不要现在开风机这个问题。1.2 人工测温的三个绕不过去的短板传统粮库的测温方式是扦样器加人工记录或者用便携式测温杆。这套办法在十年前还行现在越来越撑不住。第一个短板是采样点太少、周期太长。人工测温一般一周一次一个仓抽十几个点这个密度根本抓不到局部发热的早期信号。粮堆发热从一个小区域开始可能三五天就能扩散到几十平方米等你下周再去测已经错过最佳处理窗口。第二个短板是数据不成体系。手写记录本上的数字很难做纵向对比和趋势分析。同一根电缆不同深度、同一深度不同电缆之间的关系肉眼看不出来。第三个短板是劳动强度和覆盖范围。一个储备库几十个仓每个仓都要人进去爬粮面、插测温杆夏天仓内温度四十多度冬天又要防结露人员成本高不说安全性也差。所以智慧粮仓监测系统替代的不是测温这个动作而是整套发现异常—判断趋势—触发处置的闭环。这个定位如果不清楚做出来的东西就是个高级温度计。1.3 一套系统落地前必须钉死的几项指标动手之前有几项指标必须先定下来不然做到一半改需求返工成本极高。我一般会跟业主确认这几条指标项常见取值说明单仓测温点数量60~150 点按仓型、跨度、装粮高度定温度测量精度±0.5 ℃ 以内分辨率要求 0.0625 ℃采集周期10 分钟~2 小时可配越短功耗越高需要权衡单节点电池寿命≥ 3 年免维护是核心诉求数据保存年限≥ 3 年部分库要求 5 年报警响应时间≤ 采集周期的 1.5 倍含重传余量这里面最容易被低估的是电池寿命。很多人算功耗的时候只算了平均电流忽略了无线发射瞬间的峰值电流和电池在低温下的容量衰减最后实测下来一年半就要换电池维护成本直接把方案的经济性打没了。2. 系统架构感知、传输、平台三层怎么分工2.1 感知层测温电缆和传感器的实际布法感知层的核心是测温电缆。一根电缆内部串接多个温度传感器通常按 1.0~1.5 米的间距布置具体间距取决于装粮高度和分层要求。比如装粮高度 5 米一般布 4 个点距粮面 0.3 米、1.5 米、3 米、4.7 米。靠表层那个点最关键因为结露和湿热扩散都发生在表层。平面布置上常见的做法是按仓房跨度划分网格。跨度 24 米的平房仓横向布 5 列纵向按 5~8 排一个仓就是 25~40 根电缆每根 4 个测点合计 100~160 个温度点。这个规模不是拍脑袋来的是根据粮堆内部温度场的相关半径定的布太密浪费成本布太疏抓不到局部热点。注意传感器在电缆内部的灌封工艺决定了长期可靠性。粮堆内部湿度长期在 70% 以上有些库还会做环流熏蒸磷化氢气体对普通封装有腐蚀。电缆接头必须用环氧灌封不能只靠热缩管。2.2 传输层无线测温网络的三条技术路线对比传输层是整套方案里最容易选错的地方。我踩过坑之后总结下来主要就三条路路线优点缺点适用场景有线 RS485稳定、无需电池、实时性好布线困难、易被机械损坏、改造仓不可行新建仓、平地仓无线 LoRa穿透好、自建网关、无月租、功耗低需自建网关、需规划频点绝大多数改造仓蜂窝物联网无需网关、覆盖依赖运营商有月租、室内信号不稳、功耗偏高分散小型库点选 LoRa 的核心原因是穿透能力。粮仓的结构里金属构件多彩钢板屋面、钢屋架、通风管道2.4 GHz 频段在这种环境里衰减非常厉害。而 470 MHz 频段的绕射和穿透明显更好加上粮堆本身是介电常数较高的介质低频段更适合穿粮堆传播。另一个原因是它不需要运营商的月租一个库里几百个节点走蜂窝的话年费不是小数目。2.3 平台层本地 C# 上位机与远程服务的边界平台层我一般做成本地为主、远程为辅的结构。本地是一台工控机跑 C# 上位机负责串口/网关数据接收、实时显示、本地入库、声光报警。这台机器必须能在断网情况下独立工作因为粮库的网络环境不一定可靠而报警不能因为断网就失效。远程部分是把汇总数据定时推送到中心平台供多个库点统一查看和上级监管使用。这里要注意的是推送的是汇总值而不是原始值否则网络带宽和中心库的存储压力都会很大。原始数据留在本地远程只传小时级的最大最小值、平均值和报警事件。这个分工的好处是本地系统很轻一台普通工控机就能跑远程系统也很轻只处理汇总数据。中间通过一个简单的同步任务衔接任何一端挂掉都不影响另一端。3. 低功耗无线节点硬件选型与电路细节3.1 为什么 STM32L 系列更适合电池供电节点节点主控的选型直接决定了功耗天花板。STM32F1 系列跑起来性能是够的但它的停止模式功耗在几十微安级别对电池节点来说太高了。我用得比较多的是 STM32L0 和 STM32L4 系列。STM32L051 在 STOP 模式带 RTC 运行下的典型电流是 0.8 μA 左右运行模式下大约 100 μA/MHz。这意味着节点绝大部分时间都在睡每次醒来只干几百毫秒的活。相比之下 F1 系列在同等条件下要多消耗一个数量级的电流电池寿命差距非常明显。另一个考虑是外设的自主运行能力。L 系列有 LPTIM 低功耗定时器可以在停止模式下计时并唤醒内核还有 LPUART 可以在低功耗下唤醒。这些外设让节点可以做到不采集时彻底不唤醒内核而不是靠软件循环等待。这一点在代码里体现得很明显。3.2 DS18B20 单总线挂载多节点串联的关键细节温度传感器我用得最多的是 DS18B20。原因有三个数字输出不需要额外的 ADC 和信号调理、单总线可以串联多个、出厂已校准。但它在粮仓场景下有两个必须处理的问题。第一个问题是总线电容。一根测温电缆上串 4~8 个 DS18B20加上几十米的电缆分布电容总线电容很容易超过 1 nF。标准推荐的 4.7 kΩ 上拉电阻在这种负载下上升沿会变得很缓导致读写时隙判断错误。实测下来电缆超过 30 米、挂载超过 6 个器件时上拉电阻要降到 2.2 kΩ甚至要加一个 MOS 管做主动上拉。第二个问题是温度转换时间。12 位精度下 DS18B20 需要 750 ms 完成一次转换。这段时间内节点如果保持运行状态功耗就上去了。我的做法是发出转换命令后立即进入 STOP 模式用 RTC 定时 800 ms 后再唤醒读取。这样转换期间的主控电流降到 1 μA 以下。复位时序微秒级 主机拉低总线 480 us 主机释放等待 15~60 us 器件拉低 60~240 us 表示在线提示DS18B20 的 CRC 校验千万别省。粮堆里的电磁环境不算干净尤其是通风机启动的瞬间单总线数据出错是常有的事。不做校验直接采信报警会乱跳。3.3 无线收发电路与瞬时电流缓冲无线部分用的是 SX1278 系列工作在 470 MHz 免许可频段。这个芯片的接收电流大约 10 mA发射时在 17 dBm 功率下瞬时电流可以达到 120 mA持续几十到几百毫秒。问题就出在这个瞬态电流上。如果用锂亚硫酰氯电池比如 ER185053.6 V / 3600 mAh它的自放电率极低、低温性能好、能量密度高看起来完美。但它的脉冲放电能力很弱内阻大直接给 SX1278 供电会在发射瞬间把电压拉下来导致复位或者发射失败。解决办法是在电池和射频电路之间并一颗 100~470 μF 的低 ESR 电容或者用一颗 0.1 F 的超级电容做缓冲。电池慢慢给电容充电发射瞬间由电容提供电流。这一颗电容加与不加现场表现天差地别我早期做过一批没加的返修率超过三成。3.4 一节电池能撑多久完整功耗预算算一下账。假设节点每 10 分钟上报一次每次唤醒工作的时序是阶段电流时长唤醒初始化2 mA5 ms温度转换睡眠态1 μA800 ms读取温度3 mA50 ms射频发射120 mA120 ms数据处理与休眠2 mA30 ms睡眠含 RTC1 μA剩余时间单次唤醒消耗的电荷量约为唤醒初始化2 mA × 5 ms 0.01 mAs读取温度3 mA × 50 ms 0.15 mAs射频发射120 mA × 120 ms 14.4 mAs处理2 mA × 30 ms 0.06 mAs合计约 14.62 mAs即 0.00406 mAh。每 10 分钟一次一天 144 次日耗电 0.585 mAh。睡眠电流 1 μA 一天消耗 0.024 mAh加起来约 0.61 mAh/天。3600 mAh 的电池理论可以撑 5900 天也就是 16 年。但这是理想值。实际要考虑电池自放电每年 1% 左右、温度对容量的影响低温下容量打七折、以及电池老化后的内阻上升。按三分之一折算实际可用寿命在 4~5 年满足三年免维护的要求是有余量的。真正吃掉寿命的往往是意外情况网关掉线导致节点反复重传、射频发射功率设得太高、或者采集周期被运维人员改成了 1 分钟一次。所以固件里要做重传次数上限和功耗保护连续失败一定次数就自动降频上报。4. 节点固件从采集到上报的完整实现4.1 低功耗主循环与任务调度整个固件的主循环其实非常简单就是睡—醒—干活—睡。关键是把干的活压缩到最短并且保证任何一步失败都能正确回到睡眠状态。int main(void) { HAL_Init(); SystemClock_Config(); MX_RTC_Init(); /* RTC 定时唤醒 */ MX_LPTIM_Init(); LoRa_Init(); Sensor_PowerOff(); /* 默认断电省电 */ for (;;) { Enter_Stop_Mode(); /* 进 STOP等待 RTC 或射频中断 */ if (Wakeup_By_RTC()) { Read_All_Temperatures(); /* 采集 */ LoRa_Send_Frame(); /* 上报 */ Schedule_Next_Wakeup(); /* 计算下次唤醒时间 */ } if (Wakeup_By_Radio()) { Handle_Downlink(); /* 处理网关下发的配置 */ } } }这里有个细节传感器供电我用了单独的 MOS 管控制采集完就彻底断电。DS18B20 待机电流虽然只有 1 μA 左右但一根电缆上挂 8 个再加上其他电路累加起来也是笔账。能断就断。4.2 温度采集代码与时序容错DS18B20 的时序容错是固件里最需要打磨的部分。微秒级时序受中断影响很大我一般把读写时隙放在关中断的临界区里做做完立刻开中断。uint8_t DS18B20_Reset(void) { uint8_t presence; OW_OUT_LOW(); delay_us(500); OW_OUT_HIGH(); delay_us(70); presence OW_IN_READ(); /* 0 表示器件在线 */ delay_us(430); return presence; } void DS18B20_WriteByte(uint8_t byte) { for (uint8_t i 0; i 8; i) { if (byte 0x01) { OW_OUT_LOW(); delay_us(6); OW_OUT_HIGH(); delay_us(64); } else { OW_OUT_LOW(); delay_us(60); OW_OUT_HIGH(); delay_us(10); } byte 1; } }采集流程我做了三层保护。第一层是每次采集前先做一次复位检测如果器件不在线直接标记该通道为故障不参与报警判断。第二层是转换后的数据做 CRC 校验不通过就重读两次。第三层是三次都失败上报的时候把这个通道标记成无效值而不是报一个假的温度。提示不要把读数失败处理成 0 ℃这是最常见的低级错误。0 ℃ 在粮仓里是个正常温度运维人员根本发现不了传感器坏了。无效值要用专门的标志位表示上位机收到后显示成灰色。4.3 自定义数据帧与 CRC16 校验协议我一般不用 Modbus因为 Modbus RTU 的帧开销对电池节点来说偏大而且灵活的扩展性不够。自定义帧结构做紧凑一点一个节点 8 个温度点加上地址和校验30 个字节以内能发完。| 0xAA | 0x55 | 地址(2B) | 命令(1B) | 长度(1B) | 数据(N) | CRC16(2B) |CRC16 用 Modbus 多项式 0xA001这是一个久经考验的选择各种语言都有现成实现。uint16_t CRC16_Modbus(const uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; while (len--) { crc ^ *buf; for (uint8_t i 0; i 8; i) { if (crc 0x0001) { crc 1; crc ^ 0xA001; } else { crc 1; } } } return crc; }帧头用两个字节而不是一个是为了降低误同步概率。粮仓环境里偶尔会有干扰单字节帧头容易被随机数据撞上双字节能把这个概率压到很低。4.4 上报重传与网关应答机制节点上报之后要等网关的 ACK。我的做法是节点发完立刻切到接收模式等 300 ms。收到 ACK 就结束本次周期没收到就等一个随机退避时间200~800 ms后重传最多重传 3 次。随机退避很重要。如果所有节点同时失败、同时又同时重传会在网关上撞成一团形成雪崩。加个随机量能把重传的时间打散。三次都失败怎么办节点把数据存到本地的一个小环形缓冲区里下次唤醒时把失败的记录补发上去。缓冲区存 64 条记录够撑一天的连续断网。这样一来即使网关临时故障数据也不会丢。5. C# 上位机收包、解析、入库、报警5.1 串口收包避开 UI 线程卡死的写法上位机用 C# 写是主流选择Windows 上部署方便WinForm 或 WPF 都能做。但串口收包这里有个经典坑SerialPort.DataReceived事件是在线程池线程上触发的如果你在事件里直接更新控件轻则界面卡顿重则直接抛异常崩掉。我的做法是双层缓冲。串口事件里只做一件事把收到的字节块塞进一个ConcurrentQueuebyte[]然后立刻返回。另起一个后台线程从队列里取数据、组帧、解析。解析完的结果通过Invoke或者数据绑定推给界面。private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { int len _port.BytesToRead; if (len 0) return; byte[] buffer new byte[len]; _port.Read(buffer, 0, len); _rawQueue.Enqueue(buffer); // 只入队不做任何解析 }组帧线程要做的是从字节流里找帧头、判长度、验 CRC。因为是流式数据跨包的帧是常态所以要维护一个Listbyte作为待处理缓冲每次新数据追加进去然后循环尝试提取完整帧。5.2 帧解析与数据对账解析的时候有个容易忽略的点节点上报的温度值需要做合理性校验。我遇到过节点因为传感器短路上报 85 ℃ 的情况如果不做范围过滤这个值会直接触发最高级报警半夜把值班员叫起来。private bool IsTemperatureValid(double t, out string reason) { if (double.IsNaN(t)) { reason 数据无效; return false; } if (t -40 || t 80) { reason 超出量程; return false; } reason string.Empty; return true; }另一件事是数据对账。每个节点每次应该上报固定数量的测点如果某个帧里的测点数不对说明帧解析可能出问题了要记录下来。我一般会统计每个节点的上报成功率低于 95% 的节点标出来让人去现场看。5.3 数据库结构与时序数据量估算数据库选型先算量。假设一个库有 20 个仓每仓 100 个测点采集周期 10 分钟每天记录数20 × 100 × 144 288,000 条每年记录数约 1.05 亿条这个量级用 SQLite 单表存是不行的查询会越来越慢。三个应对办法第一按时间分表一个月一张表第二只存变化量粮温变化慢如果某个点跟上次相比变化小于 0.2 ℃ 就只更新时间戳不新增记录第三分层存储原始数据保留 3 个月之后归档成小时级的最大/最小/平均值。表结构我自己用的比较简单字段类型说明IdBIGINT自增主键NodeIdINT节点地址PointIndexTINYINT节点内测点序号TemperatureDECIMAL(5,2)温度值CollectTimeDATETIME采集时间StatusTINYINT0 正常 / 1 无效 / 2 补发索引建在(NodeId, CollectTime)上因为查询模式基本都是某个节点某段时间的数据。5.4 三级报警与露点联动判断报警逻辑不能只看温度绝对值要看趋势和露点关系。我用的是三级预警单点温度超过 25 ℃或者 24 小时内温升超过 3 ℃报警单点温度超过 30 ℃或者相邻两个测点温差超过 5 ℃严重单点温度超过 35 ℃或者连续三次采集持续上升相邻测点温差这个条件特别有用因为局部发热的早期特征就是某个点比周围明显高绝对值可能还没到警戒线。露点判断是另一条线也是智慧两个字的体现。当粮堆表层温度接近仓内空气露点时就会结露。露点用 Magnus 公式算public static double CalcDewPoint(double tempC, double humidity) { const double a 17.27; const double b 237.7; double alpha Math.Log(humidity / 100.0) (a * tempC) / (b tempC); return (b * alpha) / (a - alpha); }拿表层粮温减去露点差值小于 2 ℃ 就预警。这个判断在春秋季节温差大的时候特别管用能提前半天到一天发现结露风险。注意以上温度阈值是常见的经验区间不同粮种、不同储粮技术规范下的具体要求不一样实际配置时一定要按当地技术规范和粮库自己的管理要求来定不要照搬。5.5 界面设计让值夜班的人愿意看上位机界面我做过多版最后稳定下来的布局是两个主视图。左边是仓房平面图用色块表示每个测点的温度绿色正常、黄色预警、红色报警一眼扫过去就知道哪个仓有问题。右边是单点趋势曲线点击平面图上的任意点就能看到这个点最近七天、三十天的曲线。颜色阈值要做成可配的不同粮库的要求不一样。另外一定要有个值班模式把界面简化成只显示报警和关键指标字号放大因为值班室的人经常是在夜里远距离看一眼屏幕。报表模块我建议做成 Excel 导出而不是在软件里做复杂的报表。粮库的报表需求千变万化每个月都可能改一次格式用 NPOI 或者 EPPlus 生成 Excel让用户自己在 Excel 里调格式比在程序里做模板灵活得多维护成本也低。6. 现场部署与联调从图纸到上线6.1 布点图怎么画才不返工布点图要在施工前就跟粮库确认并签字。我吃过亏电缆都埋进粮堆了业主说表层那个点应该再往上 20 厘米。返工要把整根电缆拉出来代价很大。画图的顺序是先确定仓房尺寸和装粮线高度再定纵向层数一般是 3~5 层然后定平面网格。网格间距一般 4~6 米跨度大或者有历史发热记录的仓要加密。图上一根电缆标一个编号编号规则要跟节点地址对应起来比如 03 号仓第 07 根电缆对应节点地址 0x0307这样后面对账的时候不会乱。图上还要标出网关的位置、节点机箱的安装位置、走线路径。网关尽量放在仓区几何中心附近的高处减少穿墙衰减。机箱要避开装卸作业区防止被叉车撞。6.2 施工顺序、防雷与接地施工顺序我一般这样排先装网关和机房部分调通链路再逐仓安装节点和电缆边装边测最后统一联调。这样做的原因是如果网关有问题早点发现比装完所有节点再发现要省太多时间。防雷是粮库这种高大建筑必须考虑的。仓顶、通风口都是突出物节点机箱在屋面上很容易被感应雷打到。要做的几件事机箱做金属外壳并可靠接地、天线馈线加装避雷器、电源线上串一个 TVS 管。接地电阻要实测一般要求小于 4 欧姆。电缆进仓的位置要做防水处理。粮库做熏蒸的时候会有气体渗出防水没做好湿气顺着电缆进到节点里几个月就氧化了。我用的做法是穿墙套管加防水胶泥套管向内倾斜 5 度防止雨水倒灌。6.3 联调三步走点对点、分组、全网上线联调不能一次性全开要分三步。第一步点对点只开一个网关和一个节点距离 10 米确认能正常上报、ACK 能正常收到、上位机能正确解析。这一步是为了排除固件和上位机的问题跟现场环境无关。第二步分组按仓逐个接入节点每接入 10 个节点做一次全网扫频看有没有丢包。这一步主要是验证覆盖特别是仓房之间、粮堆内部的衰减情况。第三步全网上线所有节点打开观察 24 小时重点看上报成功率、有无重传风暴、电池电压是否正常。我一般会让系统跑满 72 小时再交付因为有些干扰是周期性的比如白天风机运行、晚上关停只有跨过完整的运行周期才能发现问题。上线前还要做一次断电恢复测试。把网关和上位机同时断电等 10 分钟再恢复看系统能不能自动重新收敛。这个测试能暴露很多问题比如节点重连逻辑、数据库连接池恢复、网关配置持久化等等。7. 故障排查速查表与踩坑记录7.1 通信类故障通信问题占我遇到的所有现场问题的六成以上。列个速查表现象最可能的原因排查方法个别节点长期不上报电池耗尽或天线脱落现场测电压、看天线接口整组节点同时丢包网关死机或信道干扰重启网关、扫频看底噪上报时断时续信号处于临界值调发射功率或加中继数据乱码波特率或帧格式不匹配抓原始字节比对上报成功率白天低晚上高同频设备干扰换频点或跳频最后那条特别值得说。我遇到过一个库白天丢包率 15%晚上降到 2%。查了几天最后发现是库区外面有个工地在用电焊机同频段干扰。这种问题只能通过跳频或者避开频点解决单纯提高发射功率效果有限。7.2 采集类故障采集类问题相对少但一旦出现排查起来比较费劲因为涉及单总线时序。最常见的现象是某个测点常年显示固定值比如一直显示 25.0 ℃。这多半是传感器损坏后输出默认值或者是固件把这个通道的失败处理成了固定值。前面说过失败一定要标记成无效不要用默认值填充。第二种是温度跳变。某个点相邻两次读数差好几度过一会儿又回来了。这通常是 CRC 校验没做或者做了但重试次数不够。粮堆里的电缆很长噪声耦合进来很正常靠校验和多次采样取中值能解决。第三种是整根电缆全部无读数。这种情况先查电缆接头尤其是埋进粮堆之前的那个接插件。我见过因为接头处没灌封粮食粉尘进入导致短路的。7.3 供电类故障电池节点的供电故障主要有三类。第一类是电池选型错误用了脉冲放电能力不足的电池又没有加缓冲电容表现为发射时节点复位、上报时间戳错乱。第二类是休眠电流超标。设计值是 1 μA实测 50 μA电池寿命直接掉到半年。常见原因是某个外设没关、IO 口悬空导致漏电、或者稳压芯片的静态电流太大。这类问题一定要在样机阶段用高精度电流表测出来装到现场再查就难了。第三类是太阳能补充不足。有些库点想用太阳能板加锂电池的方案延长寿命结果板子被灰尘覆盖或者被建筑遮挡充电量远低于预期。用太阳能就要按最差情况设计比如连续阴雨 15 天还能撑住。7.4 几个印象深刻的坑第一个坑是网关的并发处理能力被高估了。LoRa 网关一般是单通道半双工理论上一个时隙能收一帧但实际上如果两个节点的信号同时到达且强度接近会互相压制两帧都收不到。我一开始按理想值算容量结果 200 个节点的时候丢包率飙升。后来加了 TDMA 式的时隙分配让每个节点在自己固定的时隙里上报冲突立刻降下来了。第二个坑是数据库的时间字段用了本地时间。断网补发的时候数据的时间戳会乱因为节点算的时间和服务器算的时间对不上。后来统一改成 UTC 存储、展示的时候再转本地时区补发数据的时间顺序才正确。第三个坑是报警没有做去重和静默。一个仓出问题的时候相邻的十几个测点会同时报警一次刷出几十条记录值班员的手机被短信轰炸。后来改成按仓聚合报警同一个仓 30 分钟内只发一条并且支持人工静默。第四个坑是固件的配置参数没有持久化到 Flash。有次升级网关节点需要重新下发配置结果一部分节点掉电后配置丢了全部回到默认的 1 分钟上报周期电池消耗速度翻了好几倍。后来所有配置项都写进 Flash并且加了版本号校验。我个人在实际做这类项目的时候最大的体会是硬件决定能不能用固件决定好不好用软件决定用户愿不愿意用。很多方案在实验室里跑得漂亮到了现场就各种问题根子往往不在技术难度上而在有没有真正站在粮库值班员的角度想问题。数据准不准、报警响不响、界面看不看得懂这三点决定了系统上线三个月后是被天天打开还是被摆在角落积灰。如果你正准备做类似的方案我的建议是先在现场待两天跟着测温员走一遍完整的巡检流程看看他们记什么、看什么、担心什么。这些观察比任何技术选型文档都值钱。