做智能井盖这个项目最初是被一个很笨逼的场景打动的城市里井盖数量巨大丢了、被撬、被水冲开、井下气体超标全靠人工巡查效率低还容易漏。我们团队用AIR780E Cat.1 4G模块加微信小程序配合腾讯云MQTT做了一套轻量级智能井盖监测系统。这个连载想完整记录这套方案从硬件选型、云平台配置到小程序开发把每一步的决策原因、踩坑过程和可用代码都摊开讲。如果你正在做类似的物联网项目或者刚接触Cat.1模块和MQTT这篇可以当作一份直接能抄作业的参考。这期连载01先把整个系统的骨架搭起来为什么选Cat.1而不是NB-IoT为什么用腾讯云MQTT传感器和电源怎么设计小程序端如何展示和告警最后是联调阶段最常见的几个坑。后面几期会深入AT指令、设备接入的具体代码、小程序完整工程结构。1. 项目整体架构与技术选型为什么是AIR780E小程序腾讯云MQTT1.1 场景里的真实痛点井盖管理到底难在哪井盖管理不是“盖子盖好就行”这么简单。城市里路灯井、排水井、燃气井、通信井分布在主干道、人行道、绿化带甚至河道边数量动辄几十万。传统巡检是一组人开着车沿路看井盖有没有破损、有没有被偷、井内有没有积水全靠肉眼。暴雨天水位上涨井下管道倒灌井盖被顶开现场如果没人及时发现就是行人和车辆的安全隐患。另一个痛点是“事后追溯难”。井盖丢失或被非法开启往往过了很久才发现等找到现场重要线缆可能已经被破坏。如果有一套系统能在井盖被掀开、倾斜、水淹、气体异常时几秒内产生告警再联动地图定位就能把问题从“事后处置”变成“事中干预”。还有一个现实约束井盖分布极广不能依赖有线供电和有线网络绝大多数位置没有稳定的外部电源也没有Wi-Fi。设备必须靠电池或低功耗策略运行通信网络必须覆盖广、功耗可控、部署简单。这些约束条件决定了技术选型的大方向。1.2 Cat.1、AIR780E和腾讯云MQTT各自解决什么问题第一版方案考虑过多种通信方式最终选择了LTE Cat.1。Cat.1是基于4G LTE网络的一种低速率物联网通信标准理论下行速率10Mbps、上行5Mbps实际跑个几十Kbps就足够用。它最大的优势是直接复用现有4G基站不用自建网关也基本不存在“信号死角比NB-IoT多”的尴尬。NB-IoT在很多地下场景信号覆盖确实好但是速率低、时延偏大有些地区还受运营商频段和策略影响LoRa需要自建网关井盖分布广网关成本一下子上来了。AIR780E是合宙推出的一款Cat.1模块支持LTE Cat.1 bis尺寸很小LGA封装内置丰富的AT指令和低功耗PSM模式。选它有三个理由一是模块本身功耗控制得好待机可以到微安级别配合电池供电能跑很久二是开发方式灵活既可以用AT指令快速调通网络和MQTT也可以用Open方式在模块内部跑自己的逻辑适合不同水平的开发者三是社区资料和示例代码多遇到问题基本能搜到解决方案。小程序作为用户端解决了“要不要单独做个App”的问题。井盖巡检人员、市政管理人员、应急调度员分布在多个部门让他们各自安装一个App光版本更新就够折腾。微信小程序点开即用扫码就能看到井盖状态还能接收告警通知学习和维护成本低很多。腾讯云MQTT承担了设备与云端、设备与小程序之间的消息枢纽。设备端通过MQTT协议连上腾讯云IoT Explorer上报状态和传感器数据小程序端通过云函数或者WebSocket订阅需要的主题拿到数据后展示在地图和列表里。选择腾讯云而不是自建MQTT服务器最直接的原因是省掉了一套要维护的服务器集群同时腾讯云IoT Explorer本身有设备管理、Topic管理、规则引擎设备数量上来之后不用自己写管理后台。2. 硬件核心拆解AIR780E与传感器、电源的低功耗设计2.1 AIR780E模块到底要接哪些东西AIR780E作为主通信模块硬件上除了模块本体还需要外围电路配合。供电是最容易出问题的一环。模块的VBAT工作电压范围一般在3.4V到4.2V之间典型值是3.8V最大峰值电流可能到2A级别。这个特性决定了不能用普通LDO直接供电LDO在大压差下发热严重且带不动瞬时大电流。我实测下来用支持2A以上输出的DC-DC降压电路或者直接锂电池供电再配合大容量钽电容和瓷片电容做滤波是最稳定的方案。SIM卡电路虽然看起来简单但接触不良、ESD防护不到位会导致设备频繁离线。建议使用推入式Micro SIM卡座或Nano SIM卡座卡座旁边加ESD防护器件数据线走线尽量短。AIR780E还支持eSIM方案量产时可以减少卡座成本但调试阶段还是实体SIM卡方便。天线部分不能省。Cat.1模块需要LTE主天线如果带定位功能还需要GNSS天线。天线的位置很讲究装在井盖内部金属腔体里会严重屏蔽信号最好把天线延伸到井盖侧面的非金属区域或者使用外置天线引出到井口。实测中天线贴在金属井盖内部时RSRP能差20dBm以上直接导致联网失败。模块与MCU之间通过UART串口通信标准做法是AT指令。如果需要直接驱动传感器也可以用模块的GPIO和ADC不过为了后续扩展我习惯在AIR780E外面再接一颗低功耗MCU比如STM32L系列或合宙自家的低功耗方案把传感器采集、数据处理、状态判断放在MCU里AIR780E只负责网络通信和MQTT上报。2.2 井盖状态监测到底需要哪些传感器智能井盖不是只有一个“开/关”状态。实际场景里我们最关心的几类事件包括井盖被非法开启或移位、井内水位过高、井下可燃或有毒气体超标、井盖发生小角度倾斜但未完全掀开。对于“井盖被打开”这种最核心的事件最简单可靠的方案是干簧管加磁铁。把磁铁装在井盖边缘干簧管装在井座井盖闭合时磁铁吸合干簧管井盖被掀开时干簧管断开产生中断信号唤醒设备上报。这种方案零功耗、抗干扰强成本很低。如果还想检测“倾斜但没有完全打开”的中间状态可以再加一颗三轴加速度计比如MPU6050或更低功耗的LIS3DH。通过计算重力加速度在三轴上的投影判断井盖是否倾斜角度阈值可以按场景标定。水浸检测用的是电极式传感器两根电极暴露在井内底部水位上升接触到电极后电阻变化MCU通过ADC采集到电压跳变。这里要注意电极的防腐蚀处理长期泡在污水里普通铜电极几个月就会氧化失效建议使用不锈钢电极并定期校准。气体检测要按井的类型区分。燃气井和污水井对甲烷、硫化氢比较敏感可选催化燃烧式或电化学式传感器。这类传感器的通病是功耗高不能一直通电我通常用MOS管控制供电只在采样时刻开启采样完立即断电能省掉大量功耗。还有一个传感器容易被忽略电池电压检测。通过MCU的ADC分压采集电池电压每次上报时把电量一起发到云端这样后台能看到哪些设备快没电了安排人员集中更换电池而不是等设备离线才被动响应。2.3 电池寿命怎么估算低功耗策略怎么落地井盖埋在路边不能三天两头换电池所以功耗是硬指标。AIR780E有PSMPower Saving Mode模式进入PSM后模块几乎不耗电但代价是网络连接会断开需要唤醒后重新附着。我用的是“事件唤醒周期心跳”双策略平时MCU和模块都睡死干簧管或者加速度计发生中断时立刻唤醒上报一条告警同时每24小时或者12小时主动唤醒一次上报心跳和电池电量让云端知道设备还活着。传感器供电用MOS管控制采样前才打开。以水浸传感器为例每次采样通电500ms采样完断电静态功耗可以忽略不计。MCU选用低功耗型号休眠时电流控制在10uA以内。整机实测下来静态电流大约在20uA左右一次完整上报包含入网、建链、发数据平均消耗约30mAh如果按一天一次心跳加偶尔告警来算一块4000mAh的锂电池理论上可以支撑数月到一年以上具体要看告警频率。不过这里有个坑要提醒入网和建立MQTT连接是耗电大户一次入网可能消耗几十毫安时的电量。如果设备频繁掉线重连电池寿命会急剧缩短。所以不要盲目缩短心跳间隔也不要让设备在信号差的地方反复重试。我后来给代码加了一个“失败退避”逻辑连续N次入网失败后延长下次尝试间隔到10分钟、30分钟、1小时避免在弱信号区死循环耗电。3. 云端链路设计腾讯云MQTT与数据协议的完整方案3.1 为什么直接选腾讯云IoT Explorer而不是自建MQTT物联网项目一旦设备量超过几十台自建MQTT的成本和维护压力会突然变大。要处理的不仅有服务器本身还有证书管理、设备鉴权、Topic权限控制、离线消息存储、规则引擎等。腾讯云IoT Explorer把这些能力以产品化方式提供设备端只要拿到三元组ProductID、DeviceName、DeviceSecret用MQTT协议接入就能完成认证和通信。另一个加分项是它的腾讯生态。小程序云开发、云函数和移动端SDK都有现成对接省去了“云平台只提供原始MQTT上层要自己写一堆胶水代码”的麻烦。而且腾讯云IoT Explorer有免费额度对于原型验证和中小规模项目非常友好具体免费策略以官网最新说明为准。3.2 Topic怎么划分数据格式怎么定Topic设计直接决定后续的扩展性。我的做法是分三类上行数据、下行命令、系统事件。设备上报状态数据用一个专门的主题所有传感器数据打包成JSON一次上报而不是一个传感器一个主题。这样减少网络交互次数也方便云端规则引擎用一条规则处理。数据格式大概是这样的{ deviceId: cover_001, timestamp: 1717390800, type: report, position: { lng: 116.397, lat: 39.908 }, status: { lidOpen: false, tiltAngle: 3.2, waterLevel: 0, gasPpm: 12 }, battery: 86, signal: 22 }deviceId是业务编号便于后台显示position字段由设备端或云端根据井盖编号补充status里每个字段对应一组传感器的状态。这里有一个细节字段命名尽量统一用驼峰小程序端拿到之后不用做太多转换。如果是告警事件比如井盖被打开type字段改成alert同时云端规则引擎会触发告警推送。下行控制用另一个主题比如远程控制设备重启、校准传感器阈值。控制指令下发后设备端返回执行结果格式类似{ deviceId: cover_001, type: response, cmd: restart, result: ok }系统事件主要指设备上下线通知。腾讯云IoT Explorer本身就支持上下线Topic后台可以订阅这些事件当设备离线超过阈值时自动生成工单。这部分我建议不要自己造轮子直接使用平台提供的系统Topic。3.3 设备认证、心跳保活和离线判断设备认证使用腾讯云IoT Explorer的密钥认证。设备端需要计算的MQTT三要素是ClientId、Username、Password其中Password是用DeviceSecret对特定字符串做HMAC-SHA256后得到的。直接用官方SDK或者合宙的AT指令固件它会自动计算不需要自己手动实现加密算法。但如果你用的是AT指令手动连接MQTT就需要在代码或服务端实现一遍签名算法注意密钥不要硬编码明文尽量放在安全存储区域。心跳保活对井盖这种低功耗设备尤其重要。MQTT本身的KeepAlive机制是在连接层发PINGREQ腾讯云一般要求KeepAlive的间隔在30到120秒之间。但井盖设备平时处于PSM省电状态不可能每30秒发一次心跳。所以我的方案是设备在线时用MQTT KeepAlive进入PSM前主动发送一条offline准备消息同时让平台基于“最后一次心跳”时间判断离线。简单说不要只依赖协议层心跳要在业务层设计“状态过期时间”。后台如果超过15分钟没有收到某设备任何消息就判定离线。离线判断的阈值要结合上报策略调整。如果设备设计成30分钟上报一次心跳后端15分钟判定就会误报。我最终用的是“上报周期乘2加5分钟”的动态阈值既不会漏报也不会频繁误报。4. 小程序端开发从地图展示到告警中心的完整实现4.1 小程序直连MQTT还是通过API转发很多人一上来就想着小程序直接通过MQTT over WebSocket连腾讯云这样消息可以实时到手机。想法没错但实际会碰到几个麻烦一是设备密钥不应该下发到小程序端会泄露二是小程序在弱网环境下长连接不稳定一旦断线重连逻辑没写好用户会一直看到“连接中”三是微信小程序对网络连接有并发限制长连接数量太多会影响其他请求。所以我的架构是“设备上报到云端云端存库小程序通过云函数/API读取同时监听告警事件”。具体路径是AIR780E通过MQTT上报数据腾讯云IoT Explorer规则引擎把数据写入云开发数据库小程序通过云函数查询数据。需要实时告警时小程序端订阅云开发数据库的watch事件或者用定时器轮询最近的告警记录。这个方案牺牲了一点点实时性但换来的是稳定、安全、易维护。4.2 用uni-app开发小程序导航栏和页面结构怎么设计开发小程序我选了uni-app用HBuilderX创建项目。选uni-app的好处是以后如果想出App端代码可以复用很大一部分不必从头再来。整个小程序的页面分成四块首页地图总览、井盖列表、告警中心、我的。首页地图是核心。用腾讯地图小程序SDK把井盖位置渲染成自定义Marker正常状态用绿色告警状态用红色。点击Marker跳转到井盖详情页。列表页则按区域、状态筛选项展示井盖支持搜索井盖编号。告警中心按时间倒序展示所有告警未读的加红点提示。页面标题这里有个小程序开发的常见细节不同井盖的详情页标题如果都叫“井盖详情”用户根本分不清。我在井盖详情页onLoad里拿到设备编号后用uni.setNavigationBarTitle动态修改标题比如“井盖详情市政路12号井”这样分享到微信群里时别人一眼就能看出是哪个井盖。如果你用的是微信原生小程序对应的接口是wx.setNavigationBarTitle效果一样。顶部导航栏高度的问题也值得一提。不同机型状态栏高度不一样有些还带灵动岛如果自定义导航栏需要获取系统信息里的safe area再把胶囊按钮的位置考虑进去否则自定义按钮会被刘海遮挡。我的做法是直接保留微信原生导航栏不再自定义省掉大量适配工作。只有在需要顶部放自定义金额条或扫描入口的页面才自定义并且用uni.getSystemInfoSync()拿状态栏高度去做占位。4.3 告警推送和通知逻辑怎么做告警通知设计了两个渠道。第一是微信“订阅消息”用户主动订阅一次平台就能推送一次消息。这个接口的限制是一次订阅只能推送一条所以我在用户点击订阅时默认让他订阅“告警通知”模板每次有新告警通过云函数调用subscribeMessage.send发送。对于市政管理人员这个通知够用了如果需要多次通知就得引导用户每次收到后再次订阅。第二是企业微信群机器人。井盖告警很多情况下需要在工作群里同步我在云函数里加上webhook推送告警产生时往指定的企业微信群发一条带地图链接的消息。这个对现场调度特别管用因为值班人员通常都盯着工作群。小程序端还需要处理“告警风暴”的问题。如果某个井盖因为传感器误报一分钟发10条告警用户会被打扰疯掉。我在云端加了一层合并逻辑同一个设备在5分钟内只产生一条告警后续同类告警只累加次数不重复推送。设备恢复后再发送“已恢复”状态通知。这需要在规则引擎或云函数里做状态机判断不要指望设备端来解决。5. 联调过程中踩过的坑与排查方法实录5.1 AIR780E注网和数据上报失败先查这4个位置联调第一步是让模块能正常入网。用串口把AIR780E连接到电脑发送AT指令最常用的是ATCGATT? // 查询是否附着4G网络 ATCOPS? // 查询当前运营商 ATCEREG? // 查询注册状态0或1表示未注册5表示已注册 ATCSQ // 查询信号强度值越大越好如果ATCGATT返回0先看SIM卡是否插好、是否有欠费停机。我遇到过一个很隐蔽的问题SIM卡没有开通物联网卡的专用APN导致附着失败。合宙模块一般默认自动选APN但如果失败可以手动配置ATCGDCONT1,IP,CMNBIOT // 以联通物联网卡为例接入腾讯云MQTT失败时首先要检查MQTT三元组签名是否和后台一致。一种常见情况是设备端用了Wi-Fi网络的时钟和当前时间不匹配导致HMAC签名的有效期校验失败。AIR780E内部没有RTC电池断电后时间复位必须在每次上报前通过NTP或基站时间校准。这个问题排查了整整一晚上最后发现模块时间停在1970年签名当然验不过。如果模块频繁重启多半是供电不够。你可以在VBAT引脚示波器抓波形正常供电应该在掉电时有平滑下降曲线而瞬时跌落会有明显毛刺。换大容量电容或调整DC-DC输出电压能解决。还有一点SIM卡座和数据线尽量不要飞线连接我用杜邦线连SIM卡时信号稍弱就掉线改成PCB直焊后稳定很多。5.2 小程序连接后端和MQTT的典型异常小程序端最常见的坑出现在“不校验合法域名”和“实际真机请求”之间的差异。开发工具里勾选“不校验合法域名”能请求到接口但真机一点就报“request:fail url not in domain list”。解决办法是在微信公众平台后台配置request合法域名必须是HTTPS且域名备案过。如果你的小程序只是体验版也要在后台临时配置不然真机照样访问不了。第二个高频问题是订阅消息授权失败。在开发者工具里点击订阅能弹窗但真机上如果用户之前拒绝过授权再次调用subscribeMessage会直接走fail回调不会弹窗。接口文档没有明确说这个逻辑我是踩了坑才发现的。解决办法是在页面里放一个引导按钮如果用户拒绝过就跳转到“设置”页让他手动打开订阅消息权限。如果你坚持在小程序端直连腾讯云MQTT over WebSocket要注意不能用http明文必须用wss并且“socket合法域名”也需要配置。小程序从基础库2.x开始WebSocket连接数量也有限制多个页面同时连接会被断开。这再次验证了我之前说的能走后端API就走后端API长连接这个口子尽量少开。5.3 调试工具怎么配合用才能快速定位问题我调试AIR780E用的是合宙的串口调试软件输出AT指令和模块日志。只要开了Modem日志模块内部的注册流程、网络附着状态、TCP连接情况都会打出来定位问题非常快。云端的排查用腾讯云IoT Explorer控制台左侧在线调试里有设备日志能查到设备每一次上行消息如果设备上报了但控制台没记录那问题一定在设备端发送环节。小程序端我用Charles做代理抓包查看云函数的请求和返回。只要装上Charles的HTTPS证书就能看到小程序的网络请求体。注意真机调试时需要在手机上配置代理并且确保手机和电脑在同一局域网。抓包不是用来做违规事情而是看接口返回和请求参数是否正常这个方法在正式开发调试里非常常见。联调阶段最容易出现“设备上行成功小程序看不到数据”的割裂情况。我的排查顺序是设备日志确认MQTT发送成功云端控制台确认数据进入规则引擎数据库确认数据已经写入云函数确认返回结果最后小程序确认渲染逻辑正确。逐层排查比在一堆日志里瞎猜高效得多。6. 连载01收尾目前跑通的效果和下一期预告6.1 当前原型系统跑通了什么到这期结束我们已经有一个能跑的原型井盖设备通过AIR780E上报状态到腾讯云IoT Explorer规则引擎把数据写入云开发数据库小程序展示井盖列表、地图和告警中心。测试环境下设备模拟开盖事件从传感器动作到小程序告警中心出现记录实测耗时为1到2秒。调度群收到企业微信推送也在同一时间范围。电池方面用4000mAh锂电池供电的实验板在一天3次心跳、偶尔模拟告警的情况下运行两周电压下降约6毫伏按这个趋势估算使用大半年问题不大。当然这还只是原型数据真正量产还要做高低温、振动、防水等可靠性测试。6.2 下一期连载准备深入什么下一期连载02会直接把AIR780E的AT指令流程和腾讯云MQTT的完整接入代码贴出来包括设备端状态机的设计思路、PSM唤醒和心跳上报的具体代码写法。如果你正在卡在“模块能上网但MQTT连不上”或“上报了几条数据就再也连不上”这两类问题上下一期应该能帮你直接解决。另外我打算在后续连载里补充一个真实部署案例市区一条主干道装了30个井盖设备的试运行数据包括信号覆盖统计、报警准确率、电池消耗趋势以及那些在大雨天被水淹没后依然能上报的设备表现。物联网项目只有经过真实环境反复捶打才算真正“能用”。最后分享一个我在实际项目里最深的体会不要一开始就追求把所有功能做完先把“一个井盖异常打开后从设备到小程序到通知群整条链路能不能跑通”跑出来再逐步加智能化。链路通了后面所有优化才有意义。这个项目当前版本最大的功臣反而是那些不起眼的地方干簧管加磁铁的开关检测、失败退避联网策略、告警合并逻辑。这些细节看着简单但对系统的稳定性影响最大也最值得花时间去打磨。