商场空调全天候运转的问题我太熟悉了。之前接手一个6万多平的商业综合体光是空调系统的电费一个月就要吞掉小几十万物业经理看着电费单直摇头。商场这种业态特殊营业时间长、人流量波动大、内部隔间多中央空调经常是“一开全开、一关全关”再加上夜间值班区域、设备间恒温需求机组根本没法彻底停。这背后的核心矛盾就是制冷需求在空间和时间上高度不均匀而传统控制方式却是“一刀切”地按固定参数跑。这套能源监测系统的价值就是把“看不见摸不着”的冷量需求和用电情况变成可视化、可计算、可控制的数据流然后用动态调节策略去逼近“按需供冷”的理想状态。我基于实际项目整理了一套可参考的源码框架和部署思路下面展开讲讲。1. 项目整体设计与思路拆解1.1 商场能耗的真实痛点在哪里先说清楚商场空调为什么费电。商场的中央空调系统通常由冷源冷水机组、输配系统冷冻水泵、冷却水泵、冷却塔和末端设备风机盘管、空气处理机组三大部分组成。按经验数据冷源能耗约占整个空调系统的55%到65%水泵和风机又占20%到30%。传统控制方式有两种极端一种是“开机定频跑一天”早上八点开主机晚上十点关主机中间不管外面是暴雨还是暴晒、商场里是冷清还是爆满冷冻水出水温度恒定在7℃供回水温差可能在2℃到5℃之间大幅波动。另一种是“靠老师傅手感”有经验的暖通主管会根据天气和经验手动调几度出水温度但人的反应速度永远跟不上负荷变化的节奏而且晚上值班时段经常把主机开到最低负荷空转效率极低。真正的问题不是设备不够好而是没有一个系统告诉设备“现在到底需要多少冷量”。冷量给的多了浪费电给的少了顾客投诉热。过去的做法是靠“经验运气”现在要做的是用数据替代猜测。1.2 这套能源监测系统的整体架构整个系统分四层感知层、传输层、策略层、执行层。感知层负责采集三类数据——环境数据室内外温湿度、CO₂浓度、设备数据主机电流、冷冻水供回水温度、水泵频率、阀门开度、人流数据通过商场客流统计系统的进出人数。这些数据汇总后交给传输层。传输层在商场这种场景下有线方案优先选RS485总线接Modbus协议稳定可靠、抗干扰能力强末端传感器用PoE供电的网线串联也行。如果部分点位不好布线可以用LoRa无线方案但我要提醒一句无线方案在商场这种金属货架多、遮挡严重的环境里掉线率比想象中高关键点位建议必须有线。策略层的核心是一个动态负荷预测引擎。它根据室内外温差变化趋势、未来一小时人流预测曲线、围护结构蓄热特性算出下一控制周期比如15分钟的“目标供冷量”再倒推出最优的机组运行组合和出水温度设定值。执行层就是直接去控制冷水机组群控柜、水泵变频器、冷却塔风机变频器以及各楼层空调机组的电动阀门开度。整套系统的控制逻辑可以概括成一句话**“数据采集→负荷预测→策略寻优→指令下发→效果反馈”**的闭环每15分钟滚动执行一次。1.3 为什么动态调节能省下30%的能耗省电的核心抓手是三个字减冗余。商场空调系统平时浪费在哪里冷冻水出水温度设定过低。冷水机组出水温度每升高1℃机组COP能效比大约提升3%到4%。传统系统全年按7℃跑如果外界负荷不高时把设定值提到9℃甚至10℃主机耗电量会明显下降。水泵长期满频运行。冷冻水泵和冷却水泵的耗电与转速的三次方成正比转速降到80%功率直接掉到原来的51.2%。商用空调系统大部分时间负荷率只有60%到80%变频泵跟着负荷走电费立刻降下来。冷却塔风机盲目开满。冷却水温度越低主机冷凝压力越低、效率越高但冷却塔风机本身也要耗电有一个最优冷却水温度平衡点不是越冷越好。动态调节做的事情就是在保证室内舒适度的前提下不断寻找这几个参数的最优组合。按照行业里做过的多组实测对比冷源综合节能率做到25%到35%是合理区间前提是控制策略要跟建筑特性和气候条件对齐。2. 核心模块解析与实操要点2.1 数据采集模块的设计细节数据采集是所有策略的地基地基打不好上层算法再漂亮也白搭。温湿度传感器的位置选择最关键。室内回风温度探头装在空调机房回风口处要避开灯具发热区和阳光直射区误差控制在±0.3℃以内。室外温湿度探头装在北墙背阴面高度离地2米以上避免屋顶热辐射影响。冷冻水供回水温度用插入式PT1000铂电阻安装在主管道上注意要加装测温套管不能直接接触水流否则更换和维修时会很痛苦。数据采集频率上环境温度建议10秒采一次设备运行参数电流、功率、频率建议2秒采一次然后做30秒滑动平均后存入时序数据库。人流数据量级不一样商场客流系统一般5分钟更新一次这个频率用于负荷预测已经够了。有个坑我必须提一下电表数据的采集。很多商场总电表是电力局装的计量表不能随便接。实际项目中最好在空调系统各支路上加装独立电能表用Modbus RTU协议读取精度选0.5级变比要实测不能照抄铭牌。之前遇到一个项目施工队照着铭牌设置变比结果实际流量和表显数据差了将近一倍导致后面调试走了大弯路。2.2 负荷预测模型的选型与参数选取负荷预测是整个系统的“大脑”。在工业级实际项目中深度学习模型需要大量历史数据做训练冷站建完调试期只有夏季一两个月的运行数据模型很容易过拟合。更务实的做法是物理模型回归修正的混合方式。核心公式是基于建筑热平衡的简化模型Q_load K × (T_out − T_in) Q_people Q_equip Q_solarK是围护结构综合传热系数单位kW/℃需要根据建筑朝向、窗墙比、保温情况做估算后期用实测数据拟合修正Q_people根据人流量乘以每人散热量商场环境按轻体力活动约134W/人计算Q_equip是商场内照明、广告屏、厨电等设备散热可按照功率和同时使用系数估算Q_solar是太阳辐射得热跟朝向和玻璃面积直接相关可以用经验公式结合气象数据近似。我这套系统里围护结构传热系数K并不固定而是分三个时段取不同值。白天营业期因人员、设备负荷占比高围护结构传热约占30%夜间关店后降至15%左右早晨预冷阶段重新爬升。这种“分时K值”的做法比一整年用一个系数要准得多。2.3 动态调节策略的具体控制算法控制策略分两级机组群控级和输配系统级。机组群控级解决的是“开几台主机、每台带多少负荷”的问题。常见做法是先判断下一小时的目标负荷与当前运行机台的安全运行范围做对比。比如一台1000kW的离心机最小安全负荷是30%如果目标负荷只有200kW那开一台大机就是浪费应该切换到250kW的小螺杆机。在部分负荷率低于20%时甚至可以完全停主机靠蓄冷罐放冷或冷却水自然冷却维持。输配系统级解决的是“怎么把冷量精准送到末端”的问题。冷冻水泵频率的调节逻辑是实时计算供回水温差目标温差设定为5℃实际温差低于5℃说明水流量偏大或冷量供应不够当温差持续低于设定值时按每3分钟降低1Hz的频率来降泵速。冷却水泵和冷却塔风机则根据冷却水温差及逼近度冷却水出水温度与室外湿球温度的差值做联动调节。控制周期上主机群控建议15分钟一次水泵变频建议3到5分钟一次末端阀门调节可以做到1分钟一次。太频繁的设备启停会缩短主机和接触器的寿命这个大家要记住。2.4 各环节关键参数速查表控制对象核心参数常规设定范围调节周期优化目标冷水机组冷冻水出水温度7~11℃根据负荷动态调整15分钟保持主机在高效区运行冷冻水泵运行频率30~50Hz3~5分钟供回水温差稳定在5℃左右冷却水泵运行频率30~50Hz3~5分钟冷却水温差稳定在5℃左右冷却塔风机运行频率20~50Hz5~10分钟逼近度控制在3~5℃末端空调机组水阀开度30%~100%1分钟室内温度稳定在设定值±1℃特别提示以上参数是典型值实际项目要根据设备铭牌、建筑负荷特点、所在地区气候做针对性修正。照搬参数的后果往往不如不调。3. 实操过程与关键代码实现3.1 源程序目录与核心模块对应关系这套源码我按功能模块拆成了6个主要文件方便大家做二次开发时直接替换对应逻辑main.py主程序入口负责调度各模块运行data_collector.py数据采集模块对接Modbus设备和SQLite/时序数据库load_forecast.py负荷预测模块实现物理模型和回归修正strategy_optimizer.py策略寻优模块输出各设备控制指令device_control.py设备控制执行模块下发指令到变频器和阀门logger.py运行日志和能耗统计模块3.2 数据采集层的核心代码Modbus数据采集的部分我用pymodbus库来做。实际项目中要注意商场的设备品牌五花八门很多老设备不支持标准Modbus地址映射表需要根据厂商提供的点位表手动建立映射。from pymodbus.client import ModbusSerialClient class ModbusCollector: def __init__(self, port/dev/ttyRS485, baudrate9600): self.client ModbusSerialClient( methodrtu, portport, baudratebaudrate, timeout3 ) self.client.connect() def read_float_register(self, unit, address, count2): # 很多设备的32位浮点数是用两个连续寄存器存储的 # 注意字节序问题有的设备是ABCD有的是CDAB result self.client.read_holding_registers( addressaddress, countcount, slaveunit ) if not result.isError() and result.registers: raw_bytes b.join([x.to_bytes(2, big) for x in result.registers]) import struct return struct.unpack(f, raw_bytes)[0] return None这一段看着简单但字节序的坑会坑掉很多人。早先我做一个项目时读取某品牌的冷冻水温度读出来的数据忽大忽小后来用调试工具对比发现是该品牌的寄存器字节序是小端模式而很多默认解析用的是大端。我后来在配置表里加了字节序字段每次接入新设备先做一次数据标定。3.3 动态调节策略的核心代码策略模块是整个系统的灵魂。核心逻辑是在满足舒适度约束的前提下寻找耗电量最小的控制参数组合。我采用的方式是先根据负荷预测结果确定主机台数和出水温度基准再做水泵和风机的逐级寻优。def optimize_group_control(target_capacity, chiller_data): 根据目标冷量选择最优的机组组合和出水温度 target_capacity: 目标冷量, 单位 kW chiller_data: 各机组额定制冷量、能效曲线、最小负载率 返回值: 机组启停状态列表和出水温度设定值 best_solution None best_power float(inf) # 以两台机组的组合为例实际项目可能有3-5台 combinations [(0, 0), (1, 0), (0, 1), (1, 1)] for combo in combinations: total_cap 0 for idx, status in enumerate(combo): if status 1: total_cap chiller_data[idx][rated_capacity] # 安全运行区间检查负载率必须在某型号的30%~100%之间 if total_cap * 0.3 target_capacity or total_cap target_capacity: continue # 对开通的机组根据目标负载率和室外气温优化出水温度 for t_set in [7, 8, 9, 10, 11]: current_power 0 for idx, status in enumerate(combo): if status 1: load_ratio target_capacity / total_cap # 实际项目应该用厂家提供的COP曲线插值 cop estimate_cop(t_set, chiller_data[idx]) current_power target_capacity / cop if current_power best_power: best_power current_power best_solution (combo, t_set) return best_solution这个算法的计算成本很低组合数量有限可以保证每次控制周期内都完成寻优。项目落地时你会遇到机组性能曲线缺失的问题。多数厂商只提供额定工况下的COP部分负荷曲线和不同出水温度下的修正曲线都需要运行数据积累。我的做法是部署初期先用出厂默认曲线跑1到2个月之后用实际电耗数据反推修正系数效果会好很多。3.4 输配系统的变频控制代码水泵变频控制的核心逻辑是保证供回水温差稳定在目标值附近。我用差分比例积分控制来做但比教科书版本多了积分限幅和输出变化率限制防止阀门频繁动作。def pump_frequency_control(current_dt, target_dt, last_error, integral, kp1.2, ki0.05, max_step2): 冷冻水泵变频控制 current_dt: 当前供回水温差 ℃ target_dt: 目标温差 ℃ last_error: 上一周期偏差 integral: 积分项累计值 kp, ki: 控制参数 max_step: 单次调节最大频率变化量 Hz error target_dt - current_dt integral max(2.0, min(-2.0, integral error)) output kp * error ki * integral # 限制输出变化率防止频率剧烈波动 freq_adjust max(-max_step, min(max_step, output)) return freq_adjust, error, integral这个控制逻辑相当于“智能温控巡航”——温差偏大就自动加力温差偏小就自动收力而积分项的作用在于抹平温差长期存在的小偏差。实际运行中积分项很容易因为传感器噪声而持续累加导致“积分饱和”。所以我对积分项做了-2到2的限幅换来的效果就是系统在稳定工况下频率波动小于0.5Hz阀门执行器寿命明显延长。3.5 系统部署与环境要求部署这套系统不需要高性能服务器一台树莓派4B或配置好一点的工控机就够跑。数据量和计算量都不大瓶颈在传感器布点和网络施工。主机房内需要部署一台本地边缘计算盒子内置SQLite时序数据库双网卡设计一张网卡接设备控制网段一张接商场内部办公网段冷站控制柜内加装Modbus转以太网网关将主机、水泵、冷却塔的控制器统一接入各楼层空调机房部署温度采集器通过有线方式串联到楼层汇聚箱最后汇聚到冷站网关核心传感器至少做双备份特别是冷冻水供回水温度探头一旦故障直接导致控制策略失效。部署时间上一个6万平的商场传感器安装加网关调试大约需要2到3周策略调优至少需要2个月要跨越不同气候工况才能把参数校准。4. 常见问题与排查技巧实录4.1 传感器读数漂移与控制失灵问题现象系统运行三周后某几个点位温度读数明显偏高导致控制策略判断“热负荷大”而频繁增开机组电费反而涨了。排查思路先看同区域不同传感器的读数差。如果只有单点漂移大概率是传感器本身或接线问题如果整片区域数据都偏高再考虑机房环境因素或网关故障。解决办法给传感器做年度标定用冰水混合物校零点和恒温水槽校满点误差超过0.5℃的果断更换。我之前在泵房换过一个PT1000更换后供回水温差从“虚高”回归真实值控制策略立即恢复正常。4.2 策略下发延迟导致末端温度波动问题现象控制指令已经下发到阀门但实际开度变化滞后室内温度出现明显过冲。排查思路这里要分清是通信延迟还是执行器本身的动作时间。电动执行器从0%到100%的行程时间通常要90秒到120秒控制周期设成1分钟的话指令还没执行完就发新指令了。解决办法调整控制策略的逻辑——增加执行器动作状态检测在上一次动作未完成前不发送新的末端口指令。另外把末端水阀的调节周期从1分钟改为3分钟既满足控制精度又避免“指令打架”。4.3 夜间低负荷区主机频繁启停问题现象夜间负荷降到最低那台机组的30%以下机组在最低负荷运行和停机之间频繁切换主机启动电流冲击大接触器寿命受损。排查思路我加了一个“安全运行区间”的硬约束目标负荷低于最小机组安全负荷且持续时间超过60分钟才允许切换到更小机组或停机切换标记为预冷工况保留。解决办法之前有朋友问能否让机组在更低负荷区间运行答案是部分机组可以到25%但对冷冻油的回油、压缩机的润滑都会有负面影响得不偿失。多台小机组搭配大机组才是更好的方案。4.4 问题速查对照表问题现象常见原因优先排查项解决方案电费不降反升控制策略被传感器错误数据误导对比同区域传感器读数标定或更换异常传感器指令有效但执行不到位执行器行程时间过长观察阀门全行程动作时间延长该设备控制周期主机频繁启停低负荷区间未设安全约束查看负荷曲线和启停记录增加最小运行时间和安全负荷约束某些楼层忽冷忽热水系统水力失调检查支路平衡阀开度做一次水力平衡调试大屏显示数据与现场表计不符变比设置错误或寄存器地址映射错误核对点位表和铭牌参数重新做设备标定关于设备功耗策略我自己的感受是这套系统的成败不取决于算法多高级而是取决于基础数据可靠性和设备控制执行力。算法能找对方向但数据不准或不落地的调节就是空转前期在传感器、网络、执行器上的功课一定不能省。5. 项目落地心得与后续扩展建议如果你准备在真实商场里做这套系统我有几个基于实际踩坑总结的经验值得你先看看。第一控制策略的“安全模式”必须设计好。网络断了、传感器挂了、通信超时了系统要能自动回退到“按固定时间表运行”的保守模式绝对不能因为策略异常导致整个商场制冷瘫痪。我这边给边缘计算盒子设置了心跳监测连续3个控制周期没有收到有效数据就自动切换到本地定时模式温度和运行参数都保持在上次的保守设定值。第二调试期间一定要有暖通工程师参与配合。软件工程师能搞定逻辑但机组的冷凝压力保护值、冷冻油温控制、压缩机的加载减载速率这些细节没有暖通专业背景的人很难拿捏到位。我每次调策略参数之前都会和运维团队开个短会确认设备当天的运行状态是否健康防止在设备带病状态下学出错误调节模式。第三节能数据的统计口径要前后一致。系统上线之前你需要采集至少一个月的“基准用电量”统计时要把天气、人流、营业时间等因素控制住。打个比方拿六月份的高温数据跟十月份的凉爽数据对比即便节能50%也不能证明系统有效。我当时是记录了每个控制周期的“等效满负荷小时数”和“单位面积能耗指标准”用归一化的方法做对比出来的结果更有说服力。第四这套系统的扩展潜力很大。目前做的是冷源侧和输配侧的自动化调节下一步你可以把室内空气质量也加进来根据CO₂浓度实时调整新风比做到“既要省电又要舒适健康”。再往后可以接电力需求响应在电网负荷高峰期自动降载赚取需求响应补贴这就从“省钱”升级到了“赚钱”的层面。最后再分享一个细节。很多节能系统效果不错但验收困难问题在于缺少直观的对比界面。我在做这套系统时专门加大屏页面设计了一块“今日节电量”的滚屏区域把实时室外气温、供冷量、耗电量、预测节电率用曲线叠在一起展示。物业方、商场运营方每天经过大屏时都能看到效果管理层对投入产出的认可度立刻就不同了。让你的节能成果被管理层和业主“看见”是项目能持续运转下去的关键。