酒店前台做了一件事：客人预订了301房间→在PMS里办了入住→房卡做好了→客人刷卡进门。从PMS到房门这一路，数据经过了几个系统？怎么保证"客人刷了卡能进门、空调已经调到23度、灯光进入了入住模式"？
这不是一个系统完成的事，是三个系统协同工作的结果。中间的数据链路断了哪一环，体验就断在哪一环。
---
PMS→弱电系统的基本链路
| 步骤 | 谁干的 | 数据流向 |
| 客人预订 | PMS | 预订数据入库 |
| 办理入住 | PMS → 门锁系统 | PMS发指令→门锁写卡 |
| 客人刷卡进门 | 门锁 → RCU客控 | 门锁信号→RCU主机→执行"欢迎场景" |
| 灯光/空调/窗帘联动 | RCU客控 | RCU→灯光模块、空调面板、窗帘电机 |
| 退房 | PMS → RCU | PMS发退房指令→RCU关断所有设备 |
链路中三个关键接口：PMS↔门锁、门锁↔RCU、PMS↔RCU。三个接口打通了，客人的体验才无缝。
---
最关键的两个对接点
对接一：PMS ↔ 门锁——客人能开门的前提
前台在PMS办入住 → PMS把客人信息、房号、入住天数推送给门锁系统 → 门锁系统根据这些信息生成一张卡（刷卡或用手机开门）。
这个对接如果延迟超过3秒，前台办完入住客人跑到房间门口刷卡不开——然后客人打电话投诉前台。不是门锁坏了，是PMS和门锁之间的数据同步延迟了。
接口标准：PMS和门锁之间通常走TCP/IP网络协议。门锁系统厂家提供标准SDK或者API给PMS开发方。如果两家不是同一个品牌的——需要开发联调，联调时间通常3-5个工作日。
对接二：门锁 ↔ RCU——"插卡取电"之后的事
客人刷卡进门→门锁把"已开门"信号传给RCU主机→RCU触发灯光场景（缓亮到欢迎模式）、空调切入预设温度、窗帘缓缓拉开。
这个对接最容易出问题的是门锁和RCU之间信号协议不兼容——门锁是用韦根协议输出，RCU是用RS485或网络接收。中间需要加一个小转换模块——这东西便宜但容易坏。坏了之后插卡取电正常但灯光场景不触发——客人走进来一片暗，体验崩。
---
对接之前，PMS方和弱电方各要准备什么？
PMS方需要提供
- 标准API文档——门锁信息推送接口格式
- 测试环境——联调用的沙箱（不是直接在生产环境上调试）
- 接口联调联系人——一个能直接沟通的开发人员，不是销售
弱电方需要提供
- 门锁系统接口文档
- RCU主机接口文档
- 网络布局图——PMS服务器和弱电设备之间的IP地址网段规划
- 联调时间表——至少预留3-5个工作日
---
三个最常出现的对接坑
坑一：IP地址冲突
PMS服务器和客控系统不在同一个网段——理论上能通，但中间经过防火墙或者VLAN隔离后端口被拦了。联调的时候网络不通、排查半天、发现是交换机上做了端口隔离。弱电机房、PMS服务器、RCU主机必须在同一台核心交换机的可达网段内。
坑二：PMS升级后对接失效
酒店用了两年之后PMS升级了一个版本——升级前没和弱电方同步测试。升级完门锁对接失效了——不是弱电的问题，是PMS升级的时候接口参数变了。PMS和弱电系统的对接必须在维保合同里写死——PMS升级前72小时通知弱电方配合测试。
坑三：没有异常处理机制
正常情况下对接是通的——但网络断了怎么办？门锁收不到PMS的指令该怎么处理？叫客人别开了等网修好？对接方案里必须定义网络中断时的fallback策略：门锁本地缓存机制（网络断的时候用离线数据继续工作，网络恢复后自动同步）。
---
在山东皓宸电子有限公司的酒店弱电项目里，PMS对接是方案设计阶段就画在图纸上的数据流——不是设备全装完了才"你们帮我们对一下PMS"。三个系统的数据通路从方案开始就理清楚了，到联调的时候才不需要返工。