LoRa 在养老院：穿墙是优势，也是限制

核心答案

LoRa 的穿透力适合老楼、砖墙多的养老院，组网不用布线。但它也有边界：网关位置选不好，某些房间会长期弱信号；节点多了之后，空中冲突会让丢包率上升。方案里要写清网关数量与位置、单网关带载节点数、以及弱信号点位的补点规则。

01AI 视频：七个算法里，哪几个真能用

方案里的算法清单通常很长，但落地效果差别极大。按“目标是否规整”排一下，实用性从高到低大致是：

算法	判断依据	落地难度
消控室脱岗 / 睡岗	画面里有没有人、姿势是否异常	低——场景固定、机位固定
疏散通道 / 消防通道占用	指定区域有没有堆放物	低——区域可画框
电动自行车违规充电	画面里有没有车、是否在充电位	中——车型多、遮挡多
烟火识别	火焰颜色纹理、烟雾扩散	中——受光照与蒸汽干扰
违规用火用气	明火、灶具状态	中高——厨房油烟干扰大
人员跌倒	人体姿态突变	高——遮挡、多人、误报多
夜间离床	床区人体位置	高——被子、护栏干扰

规律很清楚：目标越规整、场景越固定，越靠谱。前三类（脱岗、通道占用、违规充电）装在固定机位、盯着固定区域，效果稳定；后两类涉及人体姿态，误报率高，只能当辅助线索，不能当单独依据。

应答准确率时，必须带三个限定：测试集是什么、测试环境是什么、最小可识别目标多少像素。脱离这三个条件的“准确率 95%”，在验收时无法复现。

部署位置怎么选：摄像机内置算法省带宽、响应快，但升级要逐台刷；平台侧解析利旧摄像机，但占服务器算力、传视频费流量；边缘盒子介于两者之间。三家机构以内用前两种都行，机构多了要算总带宽账。

02县级中心，是一个县一个，不是一院一个

县级养老机构消防安全管理中心的形态，容易被想成“每家大一点的养老院装一套”。不是。它是县级建一个中心，把全县正常运营的养老机构连进来——中心在县里，机构端只放感知设备和传输设备。

层级	放什么	谁值守
县级中心	平台、大屏、值守席位、值班电话	民政部门委托的值守方（自建或购买服务）
机构端	传输装置、独立烟感、水压水位、AI 摄像机、门磁	机构自己的值班人员
监管端	数据接口，不落地设备	消防救援机构、民政上级部门

这个结构决定了三件事：平台只需要一套（不是每家机构一套）；告警要跨过两层人（机构值班室 → 县级中心 → 责任人）；网络是薄弱环节（机构多在乡镇，宽带质量参差）。后面所有技术选择，都是被这三件事推出来的。

先定规模再定功能。一个县 5 家机构和 40 家机构，平台架构完全不同：前者一套标准 SaaS 就够，后者必须考虑分片区、分批值守、账号权限树。规模没定就比功能清单，比出来的结论没有意义。

03工单闭环：四个节点，一个都不能省

“中心预警—机构确认—处置反馈—销号归档”，这四步听起来像流程描述，实际上是四个时间戳。系统里没有这四个时间戳，这条流程就是纸上的。

节点	系统要记什么	为什么必须记
预警产生	告警时间、来源设备、原始值	后面所有时长的起点
机构确认	确认人、确认时间、是否属实	算“响应时长”；区分误报与真实
处置反馈	处置人、措施、现场照片	验收时要看凭证，不能只有文字
销号归档	销号人、销号时间、归档编号	形成可追溯的闭环

四个节点之外，还有一条最容易漏：升级规则要可配置。不同类型、不同时段、不同机构的超时阈值不该一样——白天 15 分钟、夜间 5 分钟是常见设置；失能老人多的机构阈值应该更短。写死一个统一值的系统，用半年就会被要求改。

处置凭证只收文字等于没收。现场照片要带时间和定位，整改记录要能关联到具体隐患条目。验收时抽查十条工单，如果三条以上只有一句“已处理”，这套闭环就是不合格的。

04本地服务：滇西这类地方，路程就是指标

县域项目谈服务能力，不谈“7×24 响应”这种口号，谈三件事：谁在当地、多久能到、能做几组。

能力项	要给出什么
本地服务主体	合作服务商全称、注册地、成立时间、社保人数、原厂授权书
到场时效	勘测响应、远程响应、现场到场分别承诺；县城与乡镇分别写最长时限
技术团队	常驻省内工程师人数与所在地；是否有注册消防工程师
实施经验	近三年省内同类项目数量、单机构平均工期、单日可并行施工组数
质保与备件	质保年限、备件库所在地、故障件更换时限、续保费用标准

这几项里最实的是“单日可并行施工组数”。它直接决定工期：5 家机构、每组一天装一家，一组要 5 天，三组并行两天收工。写“工期 30 天”但只有一组人的，属于自我暴露。

另一个现实约束是施工窗口。西南山区 11 月到次年 4 月多雨雾，乡镇道路条件差，加上年底考核节点，实际可用工期比合同期短得多。方案里应该把“雨季备选方案”“设备提前到场”“分批验收”写进去，而不是只写总天数。

到场时限要分两级写：县城 2 小时、乡镇 4 小时是常见承诺，但“乡镇”里还有更远的村点。把最远的那个机构单独列出来承诺，比笼统写“全县 4 小时”可信。

05自查清单：12 项

逐条打勾。勾选状态保存在本机浏览器，下次打开接着用；本页不上传任何数据。

0 / 12

06常见问题

AI 准确率怎么写才算数？

必须带三个限定：测试集是什么、测试环境是什么、最小可识别目标多少像素。脱离这三个条件的“准确率 95%”在验收时无法复现，评审通常会要求补充测试报告。

工单闭环必须有哪几个节点？

预警产生、机构确认、处置反馈、销号归档，四个节点对应四个时间戳。缺任何一个，“响应时长”“处置率”这类指标都算不出来。另外升级规则要可配置，白天夜间、不同机构不该用同一个阈值。

机构画像的评级维度有哪些？

常见四组：风险基础（建筑年代、层数、住养人数、失能比例）、设施状态（报警系统、电气线路、消防水源、疏散条件）、管理执行（巡查完成率、整改率、培训演练、告警确认及时率）、历史事件（告警次数、误报占比、被督办次数）。

一院一档要建几类台账？

常见六类：机构基本信息、责任人与岗位责任清单、日常巡查与电子巡更、培训演练记录、设施维保与检测、隐患库。建议先上前三类中最必要的（信息、责任人、隐患库），跑三个月再补其余。

台账为什么容易做成空表？

因为没想清楚谁填、什么时候填、填了有什么用。尤其是日常巡查：纸质表改成手机打卡，形式上完成了，内容全是“正常”。要让它有价值，巡查发现的问题必须落成隐患条目并可统计。

传输装置一体机好还是分体好？

一体集成省事，但 4G 模块坏了要整机返修；分体坏哪个换哪个，代价是多一个盒子、多一组接线。机构分散、维修路程远的县，建议分体。

水压采集一定要破管吗？

不一定。优先找已有的压力表接口或预留三通，实在没有再破管。破管要停水、报备、恢复试压，一家机构可能多花半天，方案里应该写明改造方式而不是默认破管。

县级中心要对接哪几个平台？

三个方向：消防救援机构监管平台（通常 RESTful API、GB/T 26875.3 或地方标准）、民政部门的统计口径（报表或接口）、全国养老服务信息系统（预留）。三者的字段口径完全不同，不能一套字段打天下。

适用范围与本页说明

本页面向集成商与主机厂商做接入方案与应答准备。文中对协议、接口、点位的写法属技术方法，具体主机型号的协议版本须现场确认；提及的品牌仅用于说明差异，不构成推荐。养老机构存量主机品牌杂、年代杂，接入前应逐台核对，不宜按品牌统一处理。

接入方案要先做一台样机验证：取信号、对点位、跑告警、验时延全流程走通，再批量复制到其余机构。

本页内容随政策与标准更新可能调整，具体条款请以正式文本为准；涉及具体项目的建设内容、接入范围与验收要求，请以属地主管部门口径与合同约定为准。