这套系统的雏形来自我前两年实际做过的一个项目办公楼三到七层的空调早上八点半全功率启动晚上六点以后新风还在全速送风会议室没人坐着也能稳定打在20℃。做楼宇节能的人都知道能耗往往不是被单个设备浪费掉的而是被响应太慢、决策太粗浪费掉的。所以我这次把前面几篇用过的存算一体架构直接搬进智能楼宇环境感知与节能控制系统里做成了一个能就地推理、就近决策的边缘节点而不是把所有数据都塞回云端再去计算。如果你正在做楼宇自控、边缘计算或者节能改造这篇应该能给你一条完整的落地路径。这次的系统没有依赖大型服务器感知层用常规传感器采集温度、湿度、CO2浓度、光照和人员活动计算层用存算一体架构做轻量推理控制层直接驱动空调阀门、新风机组和灯光回路。整套代码和部署流程我会在正文里逐步拆解包括数据清洗、人数估算、控制策略以及我实际踩过的几个坑。适合谁看适合有一定嵌入式或物联网基础、想把AI推理真正放到设备端去跑的开发者也适合做楼宇节能改造的工程人员参考。1. 楼宇能耗去哪儿了中心化方案的瓶颈与存算一体的机会传统楼宇自控的典型套路是现场布置一堆传感器和执行器全部汇到中控室或者云端服务器由中心节点统一做逻辑判断。这种方式在几十个点位的规模下问题不大一旦扩大到一个楼层、一栋楼瓶颈就非常明显。首先是数据搬运成本。楼宇里的传感器数据往往以秒级频率在产生几千个点位全部上传带宽、存储、服务器计算压力都是实打实的开销。更麻烦的是很多数据传到中心节点只是为了判断一个很简单的动作这个房间要不要把空调调高一度。为了这个判断数据在网络上绕了一大圈。其次是控制延迟。从传感器采集到数据到中心节点下发指令再到执行器动作中间隔着网络往返和中心节点的排队处理。在楼宇这种热惯性很大的系统里延迟十几秒可能看不出什么但要应对人员突然涌入会议室、CO2浓度快速上升这类场景反应就是慢半拍。能耗浪费往往就发生在这种慢半拍里。再说可靠性。楼宇的网络环境没有机房那么干净Wi-Fi抖动、交换机重启、光纤被施工挖断这些事都真实发生过。一旦中心节点失联整个楼的控制就瘫了设备要么傻转要么全停能耗和安全都成问题。所以我一直坚持一个原则末端节点必须能在本地完成决策通信断了也只是少上报几次数据控制逻辑不能中断。存算一体架构正好踩在这些痛点上。它把存储和计算放在同一个物理单元里数据不需要在内存和ALU之间来回搬运尤其适合跑那些参数密集的神经网络推理任务。对于楼宇这种感知数据量大、要做的判断其实很小的场景存算一体能把推理功耗压得很低同时把延迟控制在微秒级。更重要的是它可以作为边缘节点的一部分让感知-推理-决策整条链路在本地闭环而不是把每个环节都拆开送到远端。这个思路放到实际系统里就是本文要做的这套东西每个区域放一个控制节点先把传感器数据读进来在本地完成特征提取和轻量推理再把控制指令直接发给执行器。云端只负责看数据、调参数、收统计不参与逐秒控制。这样既保留了集中管理的便利又把关键决策放到了离现场最近的地方。2. 系统拆解与硬件搭建一个能就地想的端侧节点这套系统的主体是一个个区域控制节点。每个节点负责感知一片区域比如一间办公室、一个会议室、一条走廊推理出当前状态再决定空调、新风、灯光怎么调。节点之间相对独立个别节点挂了不影响其他区域。2.1 传感器选型感知层的数据质量决定控制上限控制做得再好传感器数据不准后面全是白搭。我这套系统里用了四类传感器全部走I2C接口接线简单也方便MCU统一读取。温度湿度传感器选的是常见的数字温湿度模块精度大约正负0.3℃和正负2%RH放在空调回风口附近不要放在阳光直射或者出风口正对着的位置不然测出来的不是房间温度是设备体温。CO2传感器我用的是一款NDIR原理的模组量程0到5000ppm精度正负50ppm加减读数的3%。注意CO2传感器一定不能放在靠窗的位置新风和开窗影响会干扰人数估算。光照传感器选数字光照度模块量程0到65535 lux放在办公桌面上方朝向窗户的反方向测的是人工照明补充需求不是窗外阳光强度。人员感知用的是被动红外人体传感器挂在天花板或墙角。执行层方面空调控制我用的是电动两通阀加风机盘管调速信号新风机组控制一个继电器开关和一个模拟量风阀开度信号灯光控制则是220V的继电器模组每一路灯用一个回路。整套下来单个节点的硬件成本大概几百块不含人工比直接用商用楼宇自控的DDC模块便宜不少。2.2 存算一体节点把存和算压在传感器旁边为什么这套系统叫存算一体架构实战而不是普通物联网项目关键在于计算节点的设计。我没有用一个普通单片机硬扛所有逻辑也没有把所有数据丢给云端而是把计算任务拆成两部分。一部分是实时采集和时序控制这部分我用MCU来做。传感器数据要按固定周期读执行器要按指令切状态这些任务的实时性要求高逻辑简单MCU跑起来稳定可靠。另一部分是环境状态推理比如根据CO2变化曲线估算人数根据温度变化趋势判断是否需要提前关停空调。这类推理我放在了存算一体评估板上。这块板子支持轻量神经网络部署参数直接存在计算单元附近跑一次推理的功耗远低于同级别的MCU加外部内存方案。任务切分的逻辑很简单确定性任务交给MCU判断性任务交给存算一体推理。MCU每10秒采集一轮数据把原始数据缓存到一个环形队列里每1分钟取最近5分钟的数据窗口送去推理推理结果转换成控制指令由MCU执行。这样的切分让系统在Wi-Fi断开时依然能自主运转只是少了云端统计而已。我实际测试下来存算一体节点空闲时的整机功耗比树莓派加云通信方案低了将近一半推理延迟从原来的几十毫秒压到几毫秒。这还不是最关键的最关键的是功耗峰值的下降在要求直流供电或带电池备份的节点上这个优势会直接被放大。3. 从传感器裸数据到可控特征环境感知算法怎么做传感器读出来的是一串串原始数值但控制系统要的不是数值而是现在房间里大概几个人温度是在升还是在降天黑了但灯没开这类判断。这中间的转化就是环境感知算法的活。3.1 数据清洗传感器异常值、缺失值和毛刺处理传感器数据没有想象中干净。设备上电初期、电池电压波动、I2C总线受到电磁干扰都会产生毛刺。我的做法是每类传感器配一套独立的清洗规则。温度湿度变化慢我用中值滤波取窗口内5个样本的中间值可以滤掉脉冲干扰。CO2数据偶尔会突然跳高几百ppm有人对着传感器打了个喷嚏都会跳这个不能简单滤掉因为短时间快速升高恰恰是人员涌入的特征。所以我用了变化率限幅相邻两次读数变化超过每10秒80ppm的标记为可疑点用一个卡尔曼滤波的预测值替代。光照数据则要好处理得多白天和夜晚的量级差异远超干扰取滑动平均即可。清洗完的数据会统一写入一个时序缓存保留最近30分钟。这一步是整个感知算法的基础数据不干净后续的估算都是失真。3.2 区域人数估算从CO2读数变化反推人员密度会议室有没有人靠红外传感器就能判断但会议室里有几个人红外做不了。我用CO2浓度来做人数估算原理很简单人多呼吸导致CO2上升新风系统又在稀释CO2稳态下CO2浓度和人员数量之间存在近似线性关系。简化模型是这样的室外CO2基准浓度约400ppm一个成人静坐状态下CO2产生率约0.3到0.5 L/min新风供给量可以从新风机组的状态估算比如一台额定新风量300立方米/小时的机组折算下来就是5000升/分钟。按这个推算每增加一个人稳态CO2浓度大约增加几十到上百ppm。但我不会直接用稳态值因为新风量随时在变门窗开闭也会影响。实际项目里我采用了一个动态修正公式estimated_people max( 0, (co2_avg - co2_floor) * room_volume / (person_co2_rate * 1000.0 * (1.0 - closure_factor)) )这里co2_floor取当天凌晨无人时段的CO2基线值room_volume是房间体积person_co2_rate取每人每分钟0.4升closure_factor是门窗密闭度系数默认0.3开窗多就往下调。结果再用一个5分钟滑动平均去平滑避免人数忽大忽小导致控制抖动。这套估算的误差在静坐办公场景下大约正负1到2人已经足够支撑有人/人多/没人这种三档判断了。3.3 照明需求的判定光照与人员活动组合判断灯光控制不能只看有没有人还要看自然光够不够。下午阳光好的时候会议室没人当然要关灯但有人、自然光又够灯也可以不全部打开。我的判断逻辑分三层。首先看人体红外传感器如果连续10分钟没有检测到活动整片区域灯光切到待命档保留应急照明。其次看光照度传感器桌面亮度低于300 lux且区域有人开始补偿照明但补偿多少按当前亮度和目标亮度的差值比例来差值小于50 lux就不动避免灯光频繁微调。最后结合时间表在午休时段和下班时段强制降档。这三层组合下来灯光系统基本能做到该亮的时候够亮不该亮的时候一盏不多开。4. 节能控制策略三段式决策、联动调节与防止振荡感知做好了控制策略才有底气。这套系统的控制策略可以概括成三档模式、两个联动、一条铁律。4.1 舒适、节能、待命三档运行模式每种运行模式下空调、新风、灯光都有不同的目标参数。舒适模式区域有人且人数超过两人空调夏季设定26℃、冬季设定20℃新风按CO2阈值控制灯光补偿到400 lux。 节能模式区域有人但人数较少或者处于午休时段空调设定值夏季上调到28℃、冬季下调到18℃新风只按最低换气次数运行灯光降到200 lux。 待命模式区域无人超过10分钟空调停止制冷制热但保留风机微循环新风关闭灯光全部熄灭。模式切换不是一个瞬间的动作。我从节能模式切到舒适模式会先把空调设定值逐步往目标调每分钟调0.5℃而不是一步到位。快速降温看着爽但造成的过冲和压缩机高频启停反而是能耗黑洞。实测下来缓慢调整比一步到位的方案日均能耗低了8%左右。4.2 空调设定值优化与新风机组的联动空调和新风在楼宇里其实是一对冤家。空调在拼命降温除湿新风系统在新风除湿之后又往房间里送湿热空气等于互相打架。我做了两件事来缓解。第一件事把新风量从恒定运行改成按CO2浓度调节。CO2在800ppm以下新风阀开度维持25%保底换气800到1200ppm之间开度线性升到60%超过1200ppm开度全开。这样在大多数没人又没活动的时段新风机组不再全速空转。第二件事在控制逻辑里加了一次补偿修正。当空调处于深度制冷设定26℃但实际室温已经到29℃以上时新风阀开度会延迟加大避免引入过多高温高湿空气当室温接近目标时新风阀开度可以正常跟随CO2变化。简单说高温时段优先保制冷其余时段优先保空气品质。4.3 负载调度优先级与提前关停策略控制执行的时候不是所有设备同时动。我给每类负载排了优先级灯光优先然后是新风最后是空调。原因很简单灯光响应最快对舒适度影响最直接新风影响空气品质但滞后明显空调热惯性最大调一次要好久才见效所以尽量不频繁动。提前关停策略是节能的大头。楼宇下班前的30到60分钟人员陆续离开但室内热负荷还有惯性。我让空调在下班前30分钟切到待命利用建筑的蓄冷蓄热效应很多人根本感觉不到温度变化空调却少跑了半小时。新风在下班前15分钟关闭灯光按红外感应逐个区域熄灭。这一步在实测里贡献了整个节能量的很大一部分。模式切换还需要防止振荡。控制动作一旦落下去10分钟内不允许反向操作空调设定值单次最多调整1℃新风阀位单次最多调整10%。现实中压缩机和风阀都有物理寿命频繁动作省下的那点电费还不够修设备的。5. 核心代码实现采集、推理、控制三件套下面这份代码是我在这个项目里实际跑过的核心逻辑。为了便于展示我把MCU上的采集逻辑用Python伪代码形式写出来存算一体推理部分封装成接口调用实际工程中你可以把采集部分换成C语言接口不变。5.1 传感器采集与滑动窗口import time import collections import threading # 统一传感器接口 class SensorHub: def __init__(self): self.temp None self.humidity None self.co2 None self.lux None self.motion False def read_all(self): # I2C读取这里简化成函数占位 self.temp read_temperature() self.humidity read_humidity() self.co2 read_co2() self.lux read_lux() self.motion read_motion() return self # 30分钟环形缓存 history collections.deque(maxlen180) def collect_loop(stop_event): hub SensorHub() while not stop_event.is_set(): data hub.read_all() history.append({ ts: time.time(), temp: data.temp, humidity: data.humidity, co2: data.co2, lux: data.lux, motion: data.motion, }) time.sleep(10)这个环形队列是整个感知链路的数据底座。窗口大小设成180个样本对应30分钟足够支撑人数估算和趋势判断又不会占用太多内存。5.2 存算一体推理接口封装存算一体评估板在系统里承担特征推理的任务。我给它封装出了一个统一接口外部只关心输入特征向量和输出结果。class ComputeNode: 存算一体推理节点封装 def __init__(self): self.model load_compiled_model(env_energy_model.bin) def infer(self, feature_vector): # 将特征向量送入存算一体设备返回推理结果 # 内部通过NPU驱动完成延迟一般小于5ms result self.model.predict(feature_vector) return result def build_feature_vector(window_data): 从滑动窗口数据提取特征作为推理模型输入 co2_list [d[co2] for d in window_data] temp_list [d[temp] for d in window_data] lux_list [d[lux] for d in window_data] motion_count sum(1 for d in window_data if d[motion]) return { co2_current: co2_list[-1], co2_rate: (co2_list[-1] - co2_list[0]) / (len(co2_list) * 10), co2_max: max(co2_list), temp_current: temp_list[-1], temp_trend: temp_list[-1] - temp_list[-5] if len(temp_list) 5 else 0, lux_current: lux_list[-1], motion_count: motion_count, }我用一个轻量分类器在存算一体板上判断当前区域处于三个模式中的哪一个。训练数据来自之前人工标注的几十天历史数据特征就是上面这些。实际部署后板端推理占用的资源非常少整板功耗比普通RTOS方案低一截这也是我坚持用它而不是云端推理的原因。5.3 控制策略引擎推理结果出来之后控制策略引擎负责把它翻译成指令。MODE_COMFORT comfort MODE_ECO eco MODE_STANDBY standby class ControlEngine: def __init__(self): self.current_mode MODE_STANDBY self.last_action_ts 0 self.min_action_interval 600 # 10分钟最小动作间隔 def decide(self, mode, env_state, locked): 生成控制指令 now time.time() actions [] # 防振荡距离上次动作不足10分钟只做微小修正或不动 if now - self.last_action_ts self.min_action_interval and not locked: return actions if mode MODE_STANDBY: if env_state[fan_status] on: actions.append((fan, off)) if env_state[valve_status] open: actions.append((valve, close)) actions.append((light_level, 0)) elif mode MODE_ECO: actions.append((cool_setpoint, 28.0)) actions.append((light_level, 200)) elif mode MODE_COMFORT: actions.append((cool_setpoint, 26.0)) actions.append((light_level, 400)) # CO2联动新风 co2 env_state[co2] if co2 800: actions.append((fresh_air, 25)) elif co2 1200: actions.append((fresh_air, int(25 35 * (co2 - 800) / 400))) else: actions.append((fresh_air, 100)) self.last_action_ts now return actions这里的防振荡锁很重要。我之前第一版代码没加最小动作间隔结果空调设定值在26℃和27℃之间反复横跳压缩机一小时启停好几次吓得运维师傅直接把我系统切到手动。加了这个锁之后至少10分钟内控制目标稳定设备寿命和舒适度都保住了。6. 部署指南、调参记录与实测数据代码写完接下来的部署才是真正的考验。我部署时踩了不少坑把关键过程、参数和实测数据整理在这里。6.1 部署拓扑与软件准备整体拓扑是三层最下面是传感器和执行器中间是各区域控制节点MCU加存算一体板最上面是本地MQTT Broker和可视化看板。云端只接收聚合统计不参与实时控制。软件方面我用的是轻量Linux系统Python运行控制逻辑MQTT做消息总线。部署时按下面几步走的# 1. 安装依赖 sudo apt update sudo apt install -y python3-pip mosquitto mosquitto-clients pip3 install paho-mqtt pyyaml numpy scipy # 2. 将控制决策脚本放入边缘节点 sudo mkdir -p /opt/envcontrol sudo cp sensor_hub.py compute_node.py control_engine.py /opt/envcontrol/ # 3. 配置开机自启systemd服务示例 sudo tee /etc/systemd/system/envcontrol.service EOF [Unit] DescriptionEnv Control Node Afternetwork.target [Service] WorkingDirectory/opt/envcontrol ExecStart/usr/bin/python3 /opt/envcontrol/main.py Restartalways [Install] WantedBymulti-user.target EOF sudo systemctl enable envcontrol sudo systemctl start envcontrol我建议在正式上线之前先在房间里连续跑48小时观察数据确认采集正常、推理结果和人工判断一致再让控制引擎生效。第一版系统我就是省略了这个步骤结果人体红外传感器的误触发率比我预想高得多一个上午被幽灵人员折腾了好几轮温度调整。6.2 参数量表以下是我调完以后用着最顺手的初始参数。参数取值说明采集周期10秒太快毛刺多太慢响应迟钝推理周期1分钟用5分钟滑动窗口做特征输入人数估算平滑窗口5分钟滤掉短时波动无人判定时间10分钟红外无触发才切待命CO2保底新风阈值800ppm低于此值新风保持25%开度CO2高浓度阈值1200ppm高于此值新风全开空调最小动作间隔10分钟防压缩机频繁启停空调设定值单次调整1℃缓慢逼近目标灯光补偿启动亮度300 lux低于此值才补光目标亮度400 lux办公场景参考值提前关停空调时间下班前30分钟利用建筑蓄热余冷这些参数不是定死的。每个区域的朝向、面积、人员密度都不一样我建议每套新场景至少用一周数据重新标定一次CO2基线值和人数估算系数。6.3 实测结果我在一栋普通办公楼的两个楼层做了对照测试A层用新系统B层保持原有定时控制。测试周期是7个工作日两层的面积和人员规模相近。实测下来的大概数据是这样的指标A层新系统B层原有控制变化空调日累计运行时长约9.2小时约12小时减少23%新风机组日累计运行时长约6小时约10小时减少40%照明日用电量约7.1度约9.6度减少26%区域日均室温达标率96%92%提升4个百分点CO2超标时间占比3.5%7.2%下降一半需要说明这不是实验室数据房间的朝向和使用情况不可能完全一致不同季节的结果也会变。但至少说明这套系统的节能潜力是真实存在的。特别是提前关停空调那30分钟占整个空调节能的很大一部分而且对体感温度的负面影响几乎可以忽略。6.4 部署踩坑清单第一坑是传感器位置。CO2传感器装在了新风出风口附近读数常年500ppm以下人数估算直接失效。解决办法是回装到人员活动区域但避开直吹位置。第二坑是空调电动阀的水锤效应每次开关阀门都砰的一声响。后来我在控制逻辑里加了步进式开关一个阀门分5次到达目标开度噪声和管网冲击都小了很多。第三坑是红外误触发空调出风口的热气流吹动了窗帘红外传感器就以为有人。这个只能调安装角度和灵敏度或者改用多传感器融合比如红外加声音检测把单传感器的高误报率降下来。还有一个很容易忽略的点断电重启后空调阀位和风机状态是不确定的。我的处理是每次重启先进入待命模式再通过当前房间温度重新建立目标状态绝不盲目沿用断电前的指令。否则半夜恢复供电系统直接按白天的模式把空调拉满一晚上就把省的电费又花回去了。7. 这套架构不只能管楼宇能延伸出去的方向做完这个项目我最大的体会是存算一体架构最值钱的地方不在于算得多快而在于它把智能放到了数据产生的现场让系统在最恶劣的网络条件下也能保持独立运转。楼宇只是一个比较典型的落地场景。同样的“采集-推理-执行”闭环稍微改改传感器配置和控制逻辑就能套到其他场景里。农业大棚是我想过的一个方向。大棚里的温度、湿度、土壤墒情数据比楼宇更密集光照和通风的控制要求也更苛刻而且很多大棚的网络信号差到没法依赖云端。边缘本地闭环加存算一体推理反而比中心化方案更合适。冷库和机房也是类似逻辑温度控制的安全等级更高本地决策的必要性更强。回到楼宇这套系统本身后续可以做的扩展还有很多把人数估算做得更准加入多房间联动避免多台空调同时全功率启动或者把电价峰谷时段纳入控制策略在峰电时段主动预冷、谷电时段蓄能。技术底座已经具备剩下的都是策略层面的迭代。我这几天又在重新翻采集数据准备把午休时段的控制规则再细化一轮等下一版跑出来再更新到后续的实战篇里。