企业官网建设流程全解析

GogoAI健身场馆智能能耗控制系统落地实践分享

痛点分析

24小时自助健身场馆长期存在无效能耗问题，传统模式采用固定时间统一开灯、开空调，经常出现场馆无人但大功率设备持续空转。很多场馆独立安装灯控电表，和会员系统、门禁系统割裂，只能单纯看用电量，无法和入场、离场、约课数据联动。

同时存在这些落地难点：场馆分区复杂，力量区、有氧区、私教室、淋浴区能耗需求不一样；网络不稳定时云端下发控制指令失效，灯光空调失控；缺少能耗异常告警，线路漏电、电表跑数异常很难及时发现；连锁门店缺少统一能耗看板，总部无法横向对比各门店能耗水平；私教排课、团课预约场景不能提前预热对应区域，体验和节能很难平衡。单纯依靠传感器人体感应容易误触发，无法区分会员正常健身和短暂无人的场景。

GogoAI智能能耗控制系统基于原有IoT边缘网关搭建，和门禁入场、时段计费、私教排课模块打通，支持定时策略+入场联动+人体雷达辅助三重控制模式，分区管控照明、空调、新风、淋浴水控、大功率回路，实现有人自动开启、空场延时关闭，同时完成能耗采集、异常告警、多门店能耗汇总分析。

整体架构设计

系统分为四层：能耗感知执行层、边缘网关层、能耗服务层、业务应用层。
感知执行层包含智能计量电表、继电器控制模块、温控面板、人体雷达传感器、水控阀门；边缘网关部署在场馆本地，承担指令缓存、本地自动化逻辑、断网自治；能耗服务基于Spring Boot + MQTT，负责策略管理、指令调度、能耗数据聚合、异常判断；应用端分为门店后台、总部能耗看板。

按区域进行回路划分，每个区域绑定独立控制回路、独立电表；支持三种控制模式：固定定时、门禁入场联动、预约提前预热。
核心数据表：energy_zone区域配置表、energy_control_strategy能耗策略表、energy_meter_record电表读数流水、energy_alert能耗告警表。

能耗联动控制核心Java代码实现

监听门禁入场、离场事件，匹配区域策略下发控制指令，同时维护区域在场人数计数器，人数归零后启动延时关闭任务。

@Service @Slf4j public class EnergyLinkService { @Autowired private MqttTemplate mqttTemplate; @Autowired private EnergyZoneMapper zoneMapper; @Autowired private RedisTemplate<String,Integer> redisTemplate; /** * 处理会员入场事件，触发区域能耗设备开启 */ public void handleMemberEnter(String storeId, Long zoneId) { String countKey = "energy:zone:count:" + storeId + ":" + zoneId; // 区域人数+1 Integer count = redisTemplate.opsForValue().increment(countKey, 1); if(count == null || count == 1){ EnergyZone zone = zoneMapper.selectById(zoneId); // 下发开启指令 Map<String,Object> cmd = new HashMap<>(); cmd.put("deviceSn",zone.getCtrlSn()); cmd.put("action","ON"); cmd.put("zoneId",zoneId); cmd.put("timestamp",System.currentTimeMillis()); String topic = String.format("/gym/%s/energy/ctrl/%s",storeId,zone.getCtrlSn()); mqttTemplate.publish(topic, JSON.toJSONString(cmd),1); log.info("区域首次有人，开启能耗回路 storeId:{},zoneId:{}",storeId,zoneId); } } /** * 会员离场，人数减一，人数归零启动延时关闭 */ public void handleMemberLeave(String storeId, Long zoneId) { String countKey = "energy:zone:count:" + storeId + ":" + zoneId; Integer count = redisTemplate.opsForValue().decrement(countKey,1); if(count != null && count <= 0){ // 延时15分钟关闭，延时期间雷达检测到人则取消关闭 redisTemplate.opsForValue().set("energy:zone:delayoff:"+storeId+":"+zoneId,1, Duration.ofMinutes(15)); } } }

网关本地缓存这套人数逻辑，外网断开之后，入场离场事件依然可以在本地执行开关策略，不会因为断网一直耗电。

三种控制策略组合方案

第一种，定时基础策略。门店后台配置不同时段基础模式，凌晨低峰自动调低空调、只保留基础应急照明；高峰时段恢复标准功率，适合24小时场馆基础兜底。定时策略在网关本地执行，不依赖云端定时任务。

第二种，门禁入场联动，也是核心节能模式。会员刷码进入主区域，对应有氧、力量区回路自动开启；系统维护区域内实时人数，最后一人离场后延时关闭，延时时长门店可配置，搭配人体雷达做二次校验，避免会员短暂去卫生间直接关灯。

第三种，预约预热联动，适配私教、团课场景。课程开始前15分钟自动开启私教室灯光、空调新风；课程结束之后，签到离场全部完成再执行延时关停。预约数据直接读取排课模块的课表信息，不用人工手动开启设备。

三种策略支持叠加生效，优先级：预约预热 > 入场联动 > 基础定时。

能耗采集、统计与告警机制

智能电表按固定周期上报电压、电流、有功电量，系统按小时、按日、按月聚合能耗数据，存入时序数据表。后台生成能耗趋势报表，区分照明能耗、空调能耗、淋浴能耗，支持按门店、按区域对比。

内置异常规则：短时间用电量突增、回路电流超限、电表离线、长时间空场但设备持续耗电都会触发告警。告警分级推送，电流过载、漏电预警为高危告警，同步通知店长和运维；电表读数异常、离线为一般告警，汇总到能耗运维工作台。
同时支持阈值预警，门店月度能耗超过预设阈值时提前提醒运营排查。

连锁总部统一管控能力

在多门店管理基座之上，总部能耗看板汇总所有门店能耗数据，做横向对比、单位面积能耗排行。总部可以下发全局节能模板，门店可以在模板基础上微调区域延时、定时时段。权限隔离和原有体系保持一致：总部查看全部门店能耗，区域经理查看管辖门店，店长只能查看本店区域配置、电表数据、告警记录。

后台支持远程手动控制回路开关，门店设备检修、清洁场景可以远程开启或关闭回路，不需要到现场操作。所有远程控制操作写入审计日志。

和其他业务模块联动逻辑

和IoT门禁模块联动：接收入场、离场事件作为能耗联动触发源；
和私教排课模块联动：读取课程时间，提前预热私教室；
和访客临时入场模块联动：访客入场同样计入区域人数，触发灯光空调开启；
和时段计费模块联动：客流数据和能耗报表放在同一看板，方便计算单客能耗成本；
和消息推送模块联动：能耗告警、月度能耗汇总推送对应负责人。

落地踩坑与优化要点

第一，不要只依靠人体雷达作为唯一判断依据，雷达容易遮挡、误判，必须和门禁入场人数计数器组合使用；
第二，大功率空调回路不能频繁启停，策略增加最小间隔限制，避免频繁启停损坏设备；
第三，断网自治是刚需，策略、人数计数、延时逻辑都放在边缘网关，云端只做数据采集和告警；
第四，电表采集频率不要过高，高频上报会造成MQTT消息堆积，采用5~15分钟一次采集，事件类消息实时上报；
第五，淋浴区水控独立策略，超时持续流水触发告警，减少水资源浪费。

落地效果总结

这套能耗控制系统已经在多家24小时自助健身门店落地，分区联动的方案相比固定长开启模式，门店整体用电成本有明显下降。系统不单独作为孤立硬件管控平台，深度融入会员、门禁、排课业务链路，实现业务行为驱动能耗自动控制。

总部可以统一监控连锁门店能耗，快速定位高耗门店、异常回路；门店运维人员可以在后台查看能耗曲线、处理告警、远程控电。整套能耗能力和门禁IoT、访客入场、排课、多门店管理模块组合，完善无人场馆数字化运营底座。