上周面了一个简历特别漂亮的候选人三年物联网经验做过两个完整的 STM32 网关项目还写着“精通 FreeRTOS、熟悉 MQTT 协议”。我本来挺期待结果聊了不到二十分钟就确认这位大概率是个“水货”。倒也不是完全不会而是一问到设备监控里那些躲不开的硬问题就开始“这个、那个、可能、大概”技术深度基本停留在跑通 Demo 的层面。其实物联网设备监控这个方向面试官最爱考察的技术挑战来来去去就那几类组网架构、协议选型、网关实现、数据可靠性、上线后的排查能力。但能把每一层都讲扎实的人真的不多。这篇文章就借那次面试的现场把物联网设备监控里那些必须想清楚的技术点挨个拆一遍。不管你是准备面试、在做毕业设计还是已经在搞 STM32 物联网网关开发应该都能从里面找到点对自己有用的东西。1. 面试开场扒开简历里的“物联网经验”水分1.1 简历话术与真实项目的差距候选人简历上写着“独立完成物联网设备监控系统”我一般会先问一句这个系统从传感器到云端完整跑通的数据链路是什么样的这里就能筛掉一批人。真正做过项目的人会直接说出来传感器通过 RS485 或者 WiFi 把数据传给网关网关跑 FreeRTOS把数据解析、打包成 JSON通过 MQTT 发布到云平台平台那边再做存储和告警展示。水货的回答往往是另一个画风“嗯……就是那个传感器采集温度湿度然后传到 STM32 上再通过 4G 模块发到服务器上服务器上能看到数据。”听起来好像也没错但细节完全没有。问传感器和网关之间走的什么协议不知道问上报频率和数据量怎么估算没想过问断网了数据怎么办愣了半天说“应该会丢吧”。实话说很多简历上的“独立完成”其实就是照着开发板例程把 Demo 跑通了把例程里的代码改改再配一个现成的上位机或者云平台就写在项目经历里了。1.2 快速识别“背题型”候选人的三个问题我面物联网岗喜欢问三个很基础但很致命的问题基本能快速判断对方是做过还是背过第一个MQTT 的 QoS 0、1、2 分别是什么意思你的项目里用的哪个为什么第二个网关和传感器之间是怎么发现对方、怎么通信的如果传感器是 WiFi 模组它的 IP 地址和网关的 IP 地址是什么关系第三个传感器离线了你是怎么判断的是靠平台那边没有新数据还是网关主动去检测这三个问题看着不难但都指向真实工程里必须处理的细节。背过八股的人往往能说出 QoS 的定义但一问到“你的项目里为什么选 QoS 1 而不是 QoS 0”就卡住了。做过的人会告诉你环境监控数据偶尔丢一条没关系用 QoS 0 最省流量但设备控制指令必须 QoS 1甚至要在业务层再做一次确认。2. 架构层面设备监控的链路到底怎么搭2.1 从传感器到平台的四层链路物联网设备监控不管形态怎么变底层逻辑都是四层感知层、网络层、平台层、应用层。感知层就是各种传感器温度、湿度、烟雾、水浸、电流、振动等等。网络层是通信通道可能是 WiFi、4G、NB-IoT、LoRa也可能是最传统的 RS485 有线总线。平台层负责接收数据、存储数据、做规则引擎和告警。应用层就是监控大屏、手机 App、微信告警推送这些。这个四层模型不算新鲜但真正值得深入想的是每一层之间的边界。比如传感器和网关之间到底谁主动谁被动网关和平台通信断了传感器还在采集吗平台收到重复数据怎么去重这些问题要是没想清楚做出来的监控系统在演示环境一切正常一上生产就各种问题。2.2 网关与传感器的 IP 关系很多人栽在这里这里重点说说“网关与传感器的 IP 关系”这个点。很多做物联网的人在这个概念上特别模糊面试或者实际组网的时候特别容易踩坑。先说最常见的场景传感器是一个 WiFi 模组比如 ESP8266它通过路由器接入局域网会被分配一个内网 IP比如 192.168.1.100。网关比如 STM32 4G 模组 WiFi 模组也接在同一个路由器上它也有自己的内网 IP比如 192.168.1.50。网关要读传感器数据可以直接通过 HTTP 或者私有 TCP 协议去访问 192.168.1.100 的某个端口。但云平台部署在公网它拿到的 IP 是公网 IP。内网 IP 192.168.1.100 是私有的公网上的服务器根本没有办法主动发起连接访问到它。这就是为什么很多新手会产生困惑明明传感器有 IP为什么平台不能直接连它答案就是在绝大多数物联网架构里平台永远不主动去连设备而是设备主动连平台。传感器把数据交给网关网关作为“代理”把数据重新封装后通过 MQTT 等协议上行到平台。网关在这里承担了协议转换和地址映射的功能对内它知道传感器的内网 IP对外它只维护一条到云平台的长连接。如果面试时你能把这一段讲清楚再补一句“如果传感器和网关不在同一个局域网而是通过 4G 或者 LoRa 接入那网关侧的通信方式就完全不同了”那基本能让面试官眼前一亮。2.3 交换机、路由器在物联网组网里的角色再延伸到组网层面很多毕业设计和实际项目里会用到一个词叫“物联网的交换机与路由器连接”。传统的 IT 网络里交换机和路由器分工明确交换机工作在二层负责局域网内设备之间的数据交换路由器工作在三层负责不同网段之间、内外网之间的数据转发。而在物联网监控场景里这个关系稍微有点变化。一个典型的工厂物联网监控项目现场几十个传感器通过 RS485 总线接到几台串口服务器串口服务器再通过网线接到工业交换机工业交换机汇聚后上联到路由器路由器再走公网或者专网连到云平台。这时候交换机的角色就是把分散的串口服务器、网关、NVR 摄像头全部汇聚到一个二层网络里路由器负责把整个现场的网络和云端打通。这里有个实操经验如果现场设备比较多一定要规划好 IP 地址段和 VLAN。不要所有设备全扔在一个网段里监控摄像头一路、传感器网关一路、办公电脑一路这样既能避免广播风暴也方便排查故障。遇到过好多次工厂现场网络卡顿最后发现是有几十个设备在同一个网段里疯狂广播把交换机 CPU 打满了。3. 网关实现STM32 FreeRTOS 的硬功夫3.1 任务划分与优先级别把一切塞进主循环聊到网关实现我一般会问你的 STM32 网关程序结构是什么样的主循环加中断还是上了 FreeRTOS水货的回答往往是“用了 FreeRTOS创建了几个任务一个读传感器一个发数据。”再问任务优先级怎么定、任务栈给多大、任务之间怎么同步就答不上来了。FreeRTOS 用得好不好差距其实很大。一个成熟的物联网网关任务划分至少有这几块传感器采集任务周期性读取传感器数据通过 Modbus 或者私有协议解析优先级中高因为数据时效性重要数据缓存任务把采集到的数据放进队列或者环形缓冲区负责写入 Flash 缓存防止断网时丢数据网络通信任务维护 MQTT 长连接接收平台下发的指令发布上行数据优先级中低看门狗喂狗任务独立处理保证系统异常时能自动复位任务之间用信号量、消息队列、事件标志组这三种 FreeRTOS 机制来同步而不是用全局变量加延时。这里有一个很关键的细节不能在 MQTT 回调函数里做耗时操作。很多人写代码习惯在收到平台下发指令的回调函数里直接处理逻辑比如解析 JSON、操作 Flash、控制继电器结果一个指令下来其他任务全部卡住。正确的做法是在回调里只把数据复制到队列然后立刻返回由专门的任务去处理。3.2 数据采集、缓存与断线重连网关最核心的能力不是采集数据而是数据不丢。面试时我特别喜欢问一个场景网关连着平台但网络不稳定平台断连了半小时这段时间传感器的数据怎么处理干过实际项目的人通常会这么答采集任务照常运行数据带时间戳写入本地的 Flash 或者 SD 卡用环形缓冲区管理只保留最近 N 条同时保持一个用于标识断网期间数据段的时间区间。等网络恢复、MQTT 重连成功后按顺序把缓存的数据补发上去同时把新采集的实时数据正常上报。这里有几个技术细节第一Flash 存储要用环形缓冲区的思路存满以后覆盖最老的数据不能无限增长。第二每条数据必须带设备 ID 和时间戳不仅为了排查更为了解决补报时平台端的时序问题。第三断线重连需要做指数退避第一次失败等 5 秒第二次 10 秒第三次 20 秒最大到几分钟就停住不要用死循环疯狂重连否则模组容易被搞死。聊到断线重连不能不说 MQTT 的心跳和遗嘱。网关和平台之间有心跳保活机制正常情况下网关会按固定间隔发 PINGREQ。如果平台在约定时间内没收到心跳就判定网关下线。更高级的做法是设置遗嘱消息LWT网关异常断线时平台能立刻收到一条遗嘱把设备状态标记为“离线”然后在监控大屏上触发告警。3.3 低功耗与看门狗的取舍另外一个考察重点是 STM32 网关的低功耗设计。尤其是电池供电的场景这个点直接决定产品能不能用。低功耗的关键不是让单片机睡眠而是整个系统的功耗统筹。传感器能关就关WiFi 模组不用就断电LoRa 或者 NB-IoT 的发射窗口要严格控制。FreeRTOS 有 Tickless 低功耗模式进入空闲任务后可以停止系统节拍定时器需要的时候再唤醒能显著降低平均功耗。但低功耗和看门狗之间有个矛盾系统睡眠时间太长看门狗会超时复位。解决思路有两种一种是在进入低功耗前“暂停”看门狗计数唤醒后再恢复另一种是调整看门狗的超时时间让它大于最长睡眠时间。我比较推荐第一种因为看门狗本来就是为了防程序跑飞不能因为省电把保护机制废掉。就这个点我还遇到过候选人和我抬杠说低功耗模式下就不该喂狗。实际上很多成熟产品是在 RTC 定时唤醒的周期里喂狗既保证系统不睡死又保证程序异常能被发现。这就是工程经验和书本知识的差距。4. 协议与平台MQTT、物模型和 ThingLinks 落地4.1 MQTT QoS 怎么选附报文示例面试中必问的还有 MQTT 的细节。很多人的理解停留在“MQTT 是物联网常用的消息协议”这个层面一问深就露馅。MQTT 有三种 QoS 级别。QoS 0 是至多一次消息可能丢失适合周期性的遥测数据比如温度上报丢一条影响不大。QoS 1 是至少一次消息保证到达但可能重复适合设备状态上报和控制指令需要业务层做幂等处理。QoS 2 是恰好一次消息不丢不重但握手开销大、性能最差实际物联网项目里用得很少。我自己的习惯是传感器遥测用 QoS 0设备上下线和告警事件用 QoS 1固件升级指令可以考虑 QoS 1 加业务确认。再看报文结构。一条标准的 MQTT 上报消息大概长这样{ deviceId: GW-STATION-01, timestamp: 1719827345, type: telemetry, data: { temperature: 26.5, humidity: 58.2, battery: 3.7 } }平台收到之后不是只存起来就完事还要做规则引擎处理温度超过阈值就告警电池低于某个值就提醒维护。这些规则可以在平台侧配置也可以在网关侧做本地判断。最好两边都做一层平台负责全局策略网关负责本地紧急响应比如温度超高时现场直接切断电源不能等数据绕一圈再到云端处理。4.2 设备上云与开源平台 ThingLinks现在做物联网毕业设计、比赛或者小规模商业项目很多人不会自己写整个云平台而是用现成的物联网平台ThingLinks 就是其中一个比较常用的开源方案。ThingLinks 这类平台做的事情是把设备接入、设备管理、数据存储、告警规则、可视化大屏这些都封装好。开发者只需要在平台上创建产品、定义物模型然后把设备三元组产品 ID、设备名称、设备密钥写进网关配置里设备就能接入。这里有几个实际开发中会踩的坑第一物模型定义要做减法。不要一上来就定义一百个属性先只定义监控真正需要的属性后续再扩展。第二平台侧的数据流转规则要提前想好数据是直接落库还是先经过规则引擎做清洗和转换如果字段格式和设备上报不一致后面排查问题会很痛苦。第三设备密钥不要硬编码在前端或者容易被反编译的固件里至少要做一层简单的加密存储。ThingLinks 这种平台的优点是上手快能快速把设备监控、告警、可视化全部打通非常适合做物联网毕业设计和技能大赛。但要注意大赛和毕设看重的是你对整个系统的理解不要光会拖组件搭大屏背后的 MQTT 接入过程、物模型映射逻辑、数据存储设计一定要能讲明白。4.3 监控面板与告警机制的工程细节平台侧还有一个容易忽略的问题监控面板的数据是实时的吗很多人的毕业设计里所谓实时监控其实是前端每隔几秒轮询一次数据库数据延迟大、数据库压力也大。正规的做法是平台收到 MQTT 消息后一方面写入时序数据库用于历史查询另一方面通过消息队列推给 WebSocket 服务前端实时刷新。告警也是这样规则引擎触发后通过短信、邮件、钉钉/企业微信机器人推送出去而不是靠人盯着大屏看。另外监控大屏上的设备在线状态不能简单用“最近一次收到数据的时间”来判断。比如一个传感器本来 10 秒报一次如果只是上报频率调到 1 分钟一次最近一次数据时间是 10 秒前并不意味着离线。要用心跳机制结合遗嘱消息来判断设备在线状态再配合平台侧的“预期上报间隔”做动态判定。5. 面试官的灵魂拷问现场排查与开放性难题5.1 “网关莫名其妙离线”的排查思路面试进行到这里我会抛一个非常实战的问题现场反馈有一台设备监控网关每天凌晨三点左右离线过几分钟又自动恢复。你怎么排查这个问题没有标准答案考的就是排查思路和工程经验。正常的思路应该是先别急着改代码按照链路一层层排除。第一步看平台侧日志网关离线前有没有收到异常报文或者心跳超时第二步看网关本地日志断线时模组返回的错误码是什么是网络断开还是服务器无响应第三步看网络环境凌晨三点是不是现场有定时任务比如摄像头定时重启、交换机定时重启导致网络闪断这里有一个非常常见的坑很多网关用的是 4G 模组而 4G 模组在信号差的时候会主动断网重连但有些模组的重连逻辑写得不好或者 SIM 卡休眠策略设置不对就会造成“看起来离线了但程序还在跑”的假象。排查时一定要让网关把模组的状态信息信号强度、注册状态、SIM 卡状态定期上报到平台否则只能干瞪眼。我实际处理过一个类似问题最后发现是交换机的节能以太网功能EEE在凌晨低流量时段把网口协商到了低速率状态网关的 TCP 连接被交换机静默丢弃了。关掉 EEE 之后问题彻底消失。这种问题没有日志和排查思路靠猜是永远猜不出来的。5.2 “重启后数据丢了”和“重复数据”的坑再问一个数据层面的问题网关断电重启后发现重启前一段时间的数据丢了可能是什么原因很多人的第一反应是写 Flash 太慢、没来得及存。这个答案不全面。更常见的原因是采集的数据先存在内存缓冲区还没来得及写 Flash 就断电了或者写了 Flash但没加掉电检测和掉电保护写入到一半断电数据损坏。完整的做法是关键数据不仅放在内存还要定期写 Flash写 Flash 时使用双备份机制两个扇区交替写同时硬件上增加掉电检测电路利用大电容维持几毫秒的供电在这几毫秒内把关键上下文保存完。这就是一个很典型的“看着简单实际全是坑”的点。另外还有一个高频问题补报数据和实时数据撞在一起平台那边出现重复记录怎么办网关侧要做好消息去重每条消息生成唯一的消息 ID平台侧在写入数据库时也要按设备 ID 加消息 ID 做去重。多一层保险数据才干净。5.3 无源物联网与规模化监控的下一站最后我会聊一个有延展性的开放题也是近几年物联网圈子里经常被提起的方向无源物联网。无源物联网这个概念简单说就是节点设备没有电池也不接电源线而是从环境中获取能量来工作。能量来源可以是射频信号、太阳光、温差、振动等等。比如一个温度标签靠读写器发射的射频能量供电被读取的时候才上电工作、把数据传回来平时完全是“零功耗”状态。这个方向对设备监控意味着什么意味着大量的感知节点可以做到免维护、免换电池部署成本大幅下降。现在一个电池供电的无线传感器几年后换电池的人工成本可能比传感器本身还贵。无源节点如果能解决通信距离和能量收集效率的问题非常适合农业大棚、仓储物流、电力设备温度监测这种需要大量布点的场景。当然无源物联网目前的限制也很明显通信距离短、数据量小、无法保证实时在线。所以它不会是现有物联网监控体系的替代而是补充——在那些“不着急、数量大、布线难、换电难”的场景里无源节点会先把活儿干起来。面试里我抛出这个开放题不求候选人给出多完整的答案更希望听到他愿意去思考技术边界和实际落地场景的态度。做物联网这行技术更新快今天主流是 WiFi 和 MQTT明天可能就有新的能量收集方案和传输协议冒出来。保持对新技术的敏感比死记硬背几个协议重要得多。面完这位“水货”候选人我心里也挺感慨的。物联网设备监控最锻炼人的地方在于它没有一夜速成的捷径必须把硬件、网络、协议、平台、现场排查这些环节一个个啃下来。简历上的项目可以写得很漂亮但实际面聊一聊、场景题问一问水分立刻就挤出来了。对于想入行或者正在做相关项目的朋友我建议多花点时间把网关到传感器这条物理链路彻底搞明白再多想想断网、断电、离线、丢数据这些“不正常”的情况因为这些才是设备监控真正的技术主战场。