GogoAI 24小时自助健身，软硬件集成落地案例
痛点分析
24小时自助健身房的最大难点不在于单独开发后台或者单独采购门禁硬件，而在于软硬件打通后的协同稳定性。很多落地项目出现这些问题：门禁、摄像头、灯光电表、储物柜来自不同厂商，协议不统一，对接工作量巨大；云端强依赖网络，宽带一断整个场馆无法入场；硬件上报事件和业务订单、权限不同步，出现扣款成功开不了门、没有权限却开门的情况。
硬件侧缺少统一网关管理，设备状态分散，故障无法实时告警；软件侧只做简单开门指令下发，没有AB门防尾随、人流统计、超时滞留、消防联动等安防逻辑。连锁门店批量交付时，每家门店都要单独调试协议，部署周期长，运维成本高。同时，入场、计费、告警、订单数据割裂，财务对账、事件追溯缺少统一数据源。
本案例为连锁品牌落地多家24小时自助门店，采用云端业务平台+本地边缘网关架构，统一接入多类IoT硬件，把门禁、AI摄像头、灯光、电表、储物柜、烟感报警器接入系统，打通小程序、总部后台、硬件设备整条链路，实现无人场馆稳定闭环运营。
整体集成架构
整体分为四层：感知硬件层、边缘网关层、云端业务层、终端应用层。 硬件层包含AB门门禁、人脸扫码终端、AI摄像头、门磁、智能照明、电表、储物柜、烟感、UPS电源；边缘网关部署在场馆本地服务器，采用Docker容器化部署，负责协议转换、本地离线校验、消息转发；云端是Spring Boot微服务集群，包含权限、订单、时段计费、安防告警、消息推送、总部权限模块；终端端为会员小程序、教练端、总部运营后台。
通信协议统一规划：门禁、储物柜、传感器优先MQTT；部分老设备使用TCP串口，网关内部做协议转换；视频流走RTSP，AI分析在边缘侧完成，减少云端带宽压力。网关和云端保持长连接，网络断开时进入边缘自治模式，缓存入场记录、计费会话，网络恢复自动同步上云。
边缘网关核心对接代码示例
网关作为软硬件中间枢纽，接收云端下发开门指令，转发给门禁控制器；同时采集硬件事件上报到云端MQTT主题。
@Service @Slf4j public class GymDeviceGatewayService { @Autowired private MqttTemplate mqttTemplate; // 下发开门指令到门店门禁设备 public ResultDTO sendOpenDoorCmd(String storeId, String deviceSn, AccessDTO accessDTO) { // 先调用云端权限校验接口 ResultDTO checkResult = accessRemoteApi.checkAccess(accessDTO); if(!checkResult.isSuccess()){ log.warn("权限校验不通过，拒绝开门 storeId:{}", storeId); return checkResult; } Map<String,Object> cmdMap = new HashMap<>(); cmdMap.put("deviceSn",deviceSn); cmdMap.put("cmd","OPEN_DOOR"); cmdMap.put("memberOpenId",accessDTO.getOpenId()); cmdMap.put("timestamp",System.currentTimeMillis()); String topic = String.format("/gym/%s/device/%s/cmd",storeId,deviceSn); mqttTemplate.publish(topic, JSON.toJSONString(cmdMap),1); return ResultDTO.success("开门指令下发成功"); } // 接收门禁上报通行事件，投递业务队列 public void handleDeviceReport(String payload){ DeviceReportDTO report = JSON.parseObject(payload,DeviceReportDTO.class); if("DOOR_PASS".equals(report.getEventType())){ rabbitTemplate.convertAndSend("device_event_exchange","access.record",report); }else if("TAILGATE_ALARM".equals(report.getEventType())){ rabbitTemplate.convertAndSend("device_event_exchange","security.alarm",report); } } }硬件联动业务流程（AB门防尾随）
会员在小程序获取动态二维码或者刷人脸，终端把凭证上传到本地网关；网关优先本地缓存权限白名单做快速校验，校验通过下发A门开门指令；会员进入缓冲区后，AI摄像头做人数识别，确认缓冲区只有一人，才打开B门；如果识别到尾随，不开启B门，直接触发安防告警，推送消息给管理员。
门磁持续上报门状态，长时间门未关闭、非法撬门都会触发告警。入场成功之后自动创建时段计费会话，灯光根据门店配置自动开启对应区域；会员离场识别完成，自动结束计费、关灯、锁定门禁。整套流程在网关本地可独立流转，外网中断不会阻断入场和基础计费。
离线兜底与数据同步方案
这是无人场馆落地最关键的一环。网关定时从云端拉取门店有效会员、预约权限、临时通行码，加密缓存到本地数据库，缓存有效期可配置。外网中断后，所有门禁校验、入场记录、计费会话全部在网关本地落地存储；所有事件写入本地缓存队列，网络恢复后按照顺序批量同步到云端业务库，同步时做幂等去重，避免重复生成入场流水和账单。
同时配置UPS后备电源，断电之后网关、门禁、摄像头持续工作一段时间，防止突然断电锁死场馆；电源状态、电压信息实时上报后台，运维人员提前收到电池告警。
设备统一管理与运维看板
所有接入硬件在总部后台统一注册，绑定门店、设备类型、SN编号，实时在线状态采集。运维看板展示设备在线率、信号强度、最近上报时间、告警次数。支持远程下发操作：远程开门、重启设备、同步白名单、升级固件。
告警分级处理：普通告警（灯光故障、储物柜异常）记录日志；高危告警（撬门、尾随、烟感报警）同时推送小程序消息、短信给门店负责人和运维。所有硬件事件和业务数据关联，一条入场记录可以直接关联对应的摄像头抓拍图片，方便纠纷复盘。
和业务模块打通逻辑
硬件网关不单独做复杂业务，只负责指令转发和事件上报，业务逻辑全部复用之前开发好的模块：
- 权限模块：校验卡片、预约、时段、门店通行权限，控制是否下发开门指令；
- 时段计费模块：入场创建会话、离场自动结算扣费，生成账单；
- 消息推送模块：开门成功、结算账单、安防告警、设备故障自动推送通知；
- 订单异常模块：断网期间产生的账单同步到云端后，走统一订单状态机；
- 总部权限模块：运维、店长、总部人员只能看到自己权限范围内门店的设备和告警。
落地踩坑与优化方案
第一，不同厂商门禁协议差异巨大，前期不要直接采购多品牌混合硬件，优先统一硬件SDK，或者在网关层做适配适配器，新增设备只新增适配器，不改动主流程； 第二，不要完全依赖云端校验，高延迟和断网直接导致门店瘫痪，边缘本地缓存是刚需； 第三，防尾随不能只依靠摄像头算法，需要AB门+门磁+AI识别组合校验，单一方案误报、漏报概率高； 第四，硬件上报频率高，做好消息限流、丢弃无效心跳，防止MQTT消息堆积压垮网关； 第五，视频流不上传云端，边缘侧做AI分析，只上传告警抓拍图片，节省带宽成本。
落地效果总结
这套软硬件集成方案已经在多家连锁24小时自助健身门店交付上线，网关容器化部署，新店交付时只需要导入门店配置，1-2天即可完成硬件调试上线。边缘自治架构解决了宽带不稳定、外网中断导致门店停业的痛点，AB门联动降低蹭卡、尾随的安全风险。
硬件事件和会员、计费、告警、订单数据统一打通，运营人员在一套后台就能完成卖卡、约课、看客流、查设备、处理告警、财务对账。整套方案可以平滑扩容，门店数量增长后可以把网关集群化管理，和之前的排课、套餐营销、权限管理模块一起，形成一套完整可复制的自助健身数字化方案。
