最近空调集控的项目总算是完成了大半的吧，可以算是基本结束了。这个项目从23年就开始，基本上一直做到了24年底，项目做的真是..... 就如我在朋友圈发的，这个项目是让我在同一个地方吹了春天的风、晒了夏天的太阳，享受了秋天的明媚，甚至每年为数不多的一场雪都没错过。
整个项目涉及6个园区，总计六十几栋楼，采集点位10W+，边缘终端设备采样频率为1分钟，云平台的监控数据的采样频率为5min，项目运行接近两年，目前云平台的采样数据总量为：83,516,041。边缘终端联机设备总计为42台设备。
年中的时候，看到系统每天都在采集着大量的数据，某天就想，如果做一个空调节能策略怎么样，说干就干。 目前市面上节能策略，基本都习惯于采用大数据回归的方式，其实就是在数据拟合，将历史上的温湿度、风等天气数据，和当日的空调能耗数据进行拟合，从而得到一个拟合参数，然后使用这个拟合参数进行控制，例如：多年来此地的这个日期段的天气数据拟合出来的结果是：温度调整为24°即可，然后节能策略就会依据这个参数进行设置，将今日的温度设置到24°。 由于这种数据拟合算法需要大量的历史数据在数据模型中进行投喂，并需要对参数进行调整，这复杂的过程，我也没那水平去使用。所以我提出了一个更为简单的策略，我把它称之为马斯克策略。 马斯克在做管理，做产品问题的时候，其实一直有一个基础策略：产品组装复杂不好解决、公司人员太多，那就先砍掉一半，看能不能用，能用能运转，就就说明另外一半不需要。这个策略在他处理Twitter的人员问题的时候，就很明显。砍掉了Twitter一半的人，Twitter没宕机的部分，说明这个业务线不需要那另外一半的人，宕机的部门，再招人回来，说明这些人不能裁。 我使用的策略也采用同样的道理。我不去管今天多少度，也不管历史大家喜欢夏天开的温度是多少，我都会在自动在他们设置的温度上，升高一度（这里是夏天）。如果升高一度后，半个小时内没有人将其调低，系统就会自动再将其温度调高一度，继续观察半个小时；如果依旧没有人调低，那就将温度继续调高一度，直至将温度调整到一个匹配温度。匹配温度计算是采用去年的温湿度数据和天气数据计算的此地最高值（不超过25°）；并且设置空调20°的下限温度设置不超过半个小时；半个小时后，系统会自动进行对温度进行调整到22°开始；当在调整的过程中，如果有人调整，则会尝试三次，例如：当将温度上调一度，房间内人员在半小时之内又将温度调整回来；则系统会在半个小时后，继续尝试将温度上调一度，如果再继续被调低，如此这样来回三次，则系统认为这房间里面人是真的需要这个温度；但是如果还是系统在连续两次调高之后，房间内的人员才反复三次都调低温度，则系统默认为房间温度为第一次调高后的温度为适宜温度。 依据此策略，将某园区的前后两栋楼AX、AY楼作为实验对象，一栋楼东、西两侧楼只控制一侧，另外一侧作为参考对照。选取策略执行时间为2024年8月xx日到 2024年8月xx日。 AX楼选择东侧为实验对象、AY楼选择西侧是策略实验对象；两栋楼的另外一侧为参照对象。下面是执行后结果对比： AX楼东侧有运行中的空调内机136个，西侧有运行中的空调内机145个；AY楼东侧有运行空调内机86个，西侧有运行的空调内机113个。
AX东侧修改比例为：21.7%；AY西侧为：15.1%；
AX东侧修改比例为：26.6%；AY西侧为：19.9%；
AX东侧修改比例为：43.5%；AY西侧为：53.1%；
AX东侧为3.2%；AY西侧为：2.4%
AX东侧为0.2%；AY西侧为：0.4%
能耗降低了17.5%
能耗降低了22.3%
能耗低3.4%
能耗低2.2% 由上面两个对比图可以看出来，能耗降低还挺明显（本来是想详细列出来数据结果，但是后来觉得容易被曲解，就只写了最后的计算结果）。
某日和以前在电网行业的朋友聊天的时候，说起了空调节能的这个事情，当时说了能耗降低貌似还挺明显，奇怪的是各地为啥不做这种东西，而是在电网行业内，更看重的是需求侧负荷控制。朋友说了这样一番话：用电指标是衡量一个地方经济的重要指标；除非是夏天高峰期逼不得已，因为供电能力跟不上，这时候才需要需求侧负荷控制，平时的时候，电网肯定没动力干这个活，因为人家难道嫌赚的少；园区也没动力干这个事情，因为节能后的钱，也不会给园区，而用你的这个系统，还要额外的费用，为什么要花自己的钱，帮别人省钱；园区内的公司更没有动力干这个事情，买系统能省多少还不知道，但是系统的钱是真正花出去了，而且一般公司，就算真能省钱，才能省几个钱。 节能归根结底还是经济问题，经济问题不就是看钱么。
