站房门禁有什么要求：平台收不到开门记录，八成是上传通道没配对
“门禁装好了，人在门口刷卡，本地记录一条不少，平台上一条都没有。”这是华东某化工园区一位运维工程师打来电话的原话。他先怀疑门禁控制器坏了，换了两个还是一样。我们的判断是：门禁本身没坏，坏的是“门禁事件怎么进数采仪、再以什么命令码上平台”这一段。多数站房门禁的开门记录不是由门禁控制器直接发出去的，而是先给到站房里的环保数采仪（比如 PS-S01），再由数采仪按 HJ 212 的报文格式打包上送。门禁与数采仪之间没握手、或者数采仪侧没配对应的上传通道和因子编码，平台端就算连接状态显示正常，也一条记录都收不到。
所以站房门禁有什么要求，第一条不是“锁要结实”，而是“记录要能完整、可追溯地送到平台”。下面按我们现场处理这类问题的顺序说。
站房门禁有什么要求，落到可验收的层面是这几条
- 人员可识别：至少记录卡号/人脸对应的持卡人身份、进出时间、进出方向，不能只有一条“门开了”。
- 事件可上传：开门、关门、非法卡、超时未关、门磁异常这些事件，要能被站房数采仪采集并上送平台，不是只存本地。
- 断网可续传：网络恢复后能按时间顺序补传，补传数据要带补传标志，平台端能区分哪些是实时、哪些是事后补的。
- 时间要准：门禁控制器、数采仪、平台三边时间一致，靠对时命令校准，否则补传记录的时间段对不上，查历史就是空的。
- 与视频、抓拍能对上：开门那一秒的抓拍图或视频片段，要能按同一时间点、同一门点位关联回去。
- 权限分级：运维、监管、企业管理分权限，避免一把通用卡开所有站房门。
门禁记录传不上去，按四层拆开看
协议层：报文对不对，平台一眼就知道
HJ 212 的报文结构是 ## 加四位数据段长度，接数据段，再接 && 和四位十六进制 CRC 校验。数据段里 QN（请求时间）、ST（系统编码）、CN（命令编码）、PW（访问密码）、MN（设备唯一标识）、Flag（数据标志）、PN（因子编码）、CP（数据内容）一个都不能少，顺序错了平台就是静默丢弃，既不回包也不报错。
门禁记录常见的走法有两种：一是挂在工况数据下，用 2051（上传工况实时数据）或 2061（上传工况分钟数据）带自定义因子编码上送；二是平台端约定一个扩展段做事件上报，历史补传走 3020。两种都行，问题往往出在“现场按实时数据配的，平台按事件记录查”。
还有 Flag 位。按 212 的字段定义，补传数据要在 Flag 里置对应位，平台才知道这是补的。没置位的话，平台会把它当实时数据，过了实时窗口就覆盖掉了，运维进历史记录一查，空白。
网络层：能 ping 通不等于能上传
站房通常是专线加 4G 双通道。能 ping 通平台 IP，只说明路由通；212 走的是 TCP 长连接，中间任何一级 NAT 会话老化、防火墙对非常用端口做了限速、APN 侧 IP 变了，都会让连接“看着在、实际发不出去”。判断方法是看数采仪的发送队列长度和重发次数。1000 命令里配的超时时间与重发次数如果被设得很小，一条报文发三次没回执就丢，队列里积压的开门记录会越堆越多。
设备层：门禁和数采仪根本没“说话”
这是最常见的。门禁控制器输出的是韦根、RS485 或干接点，数采仪要读到“谁、几点、哪扇门”，中间得有协议对接。现场经常是门禁厂家只做了本地管理软件，没开放数据接口；或者开放了，但数采仪的采集通道没配，串口波特率、从站地址、事件寄存器起始地址对不上。这种情况下门禁本地一切正常，数采仪侧一条事件都收不到。
另一种是门磁或出门按钮接成了“开门即触发”，一条开门动作产生两条记录，数采仪的事件缓冲区被刷满，反而把真正要传的记录挤掉了。
平台层：功能点没开、因子没建
数采仪这边报文发出去了，平台回了确认，但平台上就是查不到，大概率是平台侧没给这个站点建门禁功能点，或者因子编码表里没有对应的自定义编码。数据进了库，但不在任何一张查询视图里。
为什么排查顺序是先平台、再链路、最后门禁
现场的人习惯从门禁开始查，因为门禁看得见摸得着。但门禁是最不容易坏的，它坏了刷卡就没反应，人第一时间就知道。真正难查的是中间那段“看不见的路”。
我们的顺序是：先在平台上看这个站点最后一次收到门禁数据是什么时候、命令码是哪个、Flag 是什么；再看数采仪本地的发送日志和队列积压；然后抓一次报文看 CRC 和字段顺序；最后才去门禁控制器侧核对接口和点位。这个顺序的道理是从结果端往源头端倒推，每一层都能给下一层缩小范围。反过来从门禁往前走，你会在每一层都得到“看起来正常”的结论，最后回到原点。
每一步：现象、判断、动作
| 现象 | 判断 | 动作 |
|---|---|---|
| 平台设备在线，门禁记录为空 | 链路通，问题在协议字段或平台功能点 | 查平台该站点是否建了门禁功能点与因子编码 |
| 数采仪发送日志有记录，平台无回执 | 报文格式或 CRC 有问题，被静默丢弃 | 抓包核对长度字段、CP 内字段顺序、&& 后四位 CRC |
| 发送队列持续增长，重发次数打满 | 网络侧或平台响应超时 | 核对 1000 命令的超时与重发次数，检查专线 NAT 会话 |
| 数采仪收不到任何门禁事件 | 设备层对接未打通 | 核对门禁控制器接口协议、波特率、从站地址、事件寄存器 |
| 实时能查到，补传查不到 | Flag 补传位未置 | 检查数采仪补传策略，确认 3020 段的 Flag 设置 |
三个最容易误判的坑
坑一：看到心跳正常，就认定门禁数据也在正常发
心跳和门禁事件走的是同一条 TCP 连接，但周期完全不同。心跳按固定间隔发，能收到回执，只证明连接活着；门禁事件是触发型的，可能一整天只有几条。连接活着而事件发不出去，是常态，不是矛盾。判断要看事件队列，不要看在线状态。
坑二：把开门记录当实时数据配，平台按分钟数据存
2051 和 2061 传的是工况的实时值和分钟值，平台落库后按因子、按分钟聚合。开门记录是带时间戳的事件，配到这类命令里，平台上就只剩“某个因子某个时刻有个值”，出入记录页面永远查不到。这个坑最难发现，因为数据确实上去了。
坑三：门禁控制器时间被手动改过
调试时有人把门禁控制器的时间调快或调慢了几分钟，本地记录看着没问题，但上送后时间戳和平台对不上。平台按时间段提取历史时，超出窗口的记录不会返回，查历史就是空的。对时要用对时命令统一，别在设备面板上手动改。
FAQ
“我这个站房门禁到底要不要把开门记录传到平台？”
看你所在属地的监管要求。目前不少地方对污染源自动监测站房的门禁、视频有联网要求，具体以当地生态环境部门给的建设或验收口径为准。拿不准的时候，按“能传就传、留痕优先”做，比事后补装省事得多。站房门禁有什么要求，最终是验收那天说了算。
“门禁和数采仪不是一个厂家的，能对接吗？”
能，前提是门禁控制器开放数据接口，比如 RS485 Modbus、韦根转串口或者网络 API。对接前先确认三件事：接口类型、事件数据的字段（人员标识、时间、门点位、事件类型）、是否支持断网本地缓存。这三条谈清楚，再谈价格。
“断网几天，门禁记录会不会丢？”
取决于门禁控制器本地的存储容量和数采仪的缓存策略。选型时问清楚本地能存多少条事件、存满之后是覆盖还是停止写入。覆盖式的最坑，网恢复时你才知道丢了一段。
“开门抓拍的照片，走数采仪传还是走视频通道传？”
一般分开走：门禁事件这类结构化数据走数采仪上平台，抓拍图和视频走视频通道，两边靠时间戳和门点位关联。硬要塞进 212 报文里传图片，报文长度受限，不划算。