智慧灯杆上的设备全部离线？通信链路排查从哪下手

智慧灯杆上的摄像头、显示屏、环境传感器、单灯控制器同时从平台上消失，第一反应是"这批设备不行"。实际查下来，设备一起坏的概率很低，它们共用的一段链路断了才是常态。

先按掉线范围定方向

这一步在办公室就能做，能省掉大半出勤。

判断依据就是平台上的离线清单：按时间排序，看是不是同一时刻发生的；再按点位排序，看是不是连成一片。

杆内：先摸综合箱的供电

杆上设备都从综合箱取电，箱内一般分成几路，照明、显示屏、摄像头、网关各走各的空开。所有设备一起消失，先量箱内进线有没有电，再看总空开是不是跳了。

漏电保护器跳闸是常事。杆上设备多、线缆长、雨天受潮，漏保灵敏度选高了就频繁跳，跳了还不容易复现——天晴了送电就正常，一下雨又掉。这类故障在平台上看起来完全随机。

还有一种是箱内的直流开关电源坏了。照明走交流，灯还亮着，其他设备全掉。平台上表现为"亮灯率正常、设备全离线"，到现场一看灯是亮的，很容易被误判成通信问题。

网关：整根杆就这一个出口

杆上的数据通常都经一台网关出去。网关死机、固件卡死、上行的物联网卡状态异常，整杆设备就全掉，而设备本身都是好的。

查的顺序是：先 ping 网关地址，能通说明链路在，问题在应用层；ping 不通，进交换机看端口灯；端口灯正常但不通，看网关的管理页面还能不能打开；打不开就现场重启。

重启能恢复、过几天又犯，多半是固件或上行卡的问题，不是供电。这种情况别反复上杆断电，换固件或换卡更省事。

上行链路：光纤和专网

以有线为主的项目走光缆。排查顺序是从近到远：先看汇聚交换机的端口灯，再读光模块的收发光功率，光缆排在第三位。

常见的故障点就那几个：熔接点损耗大、法兰适配器松、尾纤弯折半径过小、接头端面脏。施工回填时压伤的光缆当时是通的，几个月后衰减慢慢变大才彻底断，表现是信号时好时坏，拖一阵子彻底不通。这种最难查，因为故障点和故障时间对不上。

环网结构断一处还能通，断两处整段掉。这个特征容易被误判成平台故障——因为掉的是一整片，看起来很像平台挂了。

平台侧：最容易背锅，也最该先排除

设备全掉但现场看着都正常，先把平台怀疑一遍：

• 服务进程挂了，或者数据库连接打满。
• 域名证书过期。设备用加密连接上平台，证书一过期就是批量拒绝，不是零星掉线。
• 设备时间漂移。杆上设备长期运行，内部时钟走偏之后，证书有效期判断出错，表现为批量掉线且现场重启无效。这一条很隐蔽，因为重启设备不会让时钟自动校准，只有平台侧做了时间容错才好。
• 账号或密钥被改过，MQTT 连接数打满。
• 出口策略变了：防火墙、访问控制、IP 白名单被调整过。

判断办法很直接：掉线是不是"同一时刻、全项目、点位无规律"。三条都对，就别上杆了。

断网以后灯还得亮，这条要在招标里写

杆载网关断链之后，灯是保持原样还是全灭，取决于设备有没有本地策略。带本地策略的网关能按预置的经纬度时间表自己开关灯、自己调光，链路断了灯照常亮，只是平台上暂时看不到数据。没有本地策略的，链路一断整杆失联，路灯跟着失控。

这个差别在验收时当场就能试：把上行拔掉，看灯是不是还按时间表动作。断链能自治的设备，运维压力小一大截——通信故障可以慢慢修，不用连夜出车。

招标阶段建议直接写成条款：断链状态下照明应能按预置策略继续运行，恢复通信后数据补传。补传这一条同样要写，不然断链期间的电量、告警、开关记录就丢了，报表对不上账。

责任边界怎么划

这类故障处理慢，多数不是技术难，是没人认领。建议在招标和验收阶段就把链路切成几段，一段一个责任人。

在线率这个指标尤其要写清口径：什么算在线、按什么周期统计、谁出报表、离线多久开始计时。口径不统一，验收时双方拿出来的数字对不上，扯皮能扯半年。

什么时候别查了

• 雷雨后一批杆的设备同时掉，端口多半被打坏，直接换模块，调参数没用。
• 施工围挡内的光缆被挖断，报修等修复，现场查不出结果。
• 平台证书过期，改的是平台，跟杆上的设备没关系。

排查顺序记住三步：一看掉线范围，二从平台往回查，三才上杆。反过来干，一天爬十几根杆也找不到原因在哪。