DIY空调省电助手：基于规则引擎与热舒适模型的智能温控实践-平芜编程栈

七月的电费单到手的那一刻，我才发现空调才是夏天真正的“隐形大户”。一台1.5匹的变频空调，每天开8个小时，一个月下来电费轻松多出两三百。为了把这事儿彻底弄明白，我干脆写了个小项目——空调省电助手，专门根据室内温度、室外温度、房间里的人数，自动推荐空调最佳温度和模式（制冷、制热、除湿），同时实时监控空调耗电量，每周自动生成一份省电报告。这篇文章把整个项目的思路、选型、代码和踩坑过程完整拆开，给同样想折腾智能家居、想省电费的朋友一份可以直接抄作业的参考。

这个项目适合三类人：一是家里有智能空调、又懂一点Python或ESP32基础的DIY玩家，二是被电费单吓到、想量化“怎么开空调最省”的精打细算型用户，三是做物联网项目练手、需要一个完整“采集-决策-控制-反馈”闭环案例的开发者。你不需要很深的算法功底，核心逻辑用“规则引擎+轻量级热舒适模型”就能跑起来，成本控制在两百块以内，效果立竿见影。

1. 需求拆解与整体设计：从“省电”到“舒适”的平衡术

1.1 核心需求解析：四个关键词缺一不可

这个项目表面上是“推荐温度和模式”，但真正拆开看，其实是四个相互咬合的功能模块：

感知层：室内温度、室外温度、房间人数。这三者决定了“当前环境到底需要多少冷量/热量”。
决策层：在制冷、制热、除湿三种模式之间做选择，同时给出一个“最佳设定温度”。这是整个项目的灵魂。
执行层：把决策结果转化成空调能听懂的控制指令，同时实时读取耗电量数据。
反馈层：把一段时间内的运行数据汇总成省电报告，用真实数据告诉你“这么调到底省了多少”。

这里最关键的设计决策是：不要一上来就上AI模型。市面上的智能温控产品喜欢宣传“AI学习你的习惯”，但实际落地时，AI模型需要大量历史数据训练，而且行为不可解释——你不知道它为什么把温度调到25.5℃。我的方案是“规则引擎 + 简化热舒适模型”，所有决策都能追溯到明确的公式和逻辑，用户一看就懂，出了问题也能立刻定位。这对个人项目来说，远比“黑盒智能”实用得多。

1.2 整体架构选型：本地优先，云端为辅

架构上我选择了“本地计算为主，云端查询为辅”的路线。核心控制逻辑跑在树莓派（或者ESP32）上，传感器和红外发射器直接连接，决策引擎在本地实时运行。室外温度这种非本地数据，通过免费的天气API定时拉取，缓存半小时一次，避免频繁请求。

为什么不把决策放到云端？两个原因：一是家庭网络抖动会导致控制延迟，空调响应慢半拍，体感就很差；二是隐私——房间人数、温度分布、作息规律这些数据留在本地更安心。云端只承担两件事：拉取室外温度，以及后续把脱敏后的耗电数据同步到手机App展示。这种“本地闭环 + 云端辅助”的结构，是这类智能家居小项目比较稳的姿势。

2. 数据采集层：传感器选型与接入实战

2.1 室内外温度采集：精度比品牌更重要

室内温度传感器，我用的是DHT22（又叫AM2302）。坦白说，它精度只有±0.5℃，响应速度也不算快，但胜在便宜稳定，淘宝八九块钱一个，接一个上拉电阻就能用。如果你手头宽裕，可以换SHT30，精度±0.3℃，I2C接口，代码更简洁。DS18B20也可以，防水封装能直接扔到室外。

安装位置比选型更影响数据质量。我一开始把传感器贴在空调出风口旁边，结果室内温度永远显示18℃，决策逻辑以为房间很冷，一直不启动制冷。后来把传感器放在远离空调、离地1.2米左右的墙面上，读数才正常。这里有个容易被忽略的点：传感器要避开阳光直射和电视机顶盒这类热源，否则测出来的是“局部温度”而不是“体感温度”。

室外温度我用的是和风天气的免费API，每小时自动拉一次。这样做省去了室外布线的麻烦，但要注意API的免费额度限制，建议在程序里加一个本地缓存，请求失败时用上一次的数据兜底。

2.2 人数检测方案：精度和成本的一个折中

人数检测是整个项目里最容易翻车的环节。我试过三种方案：

红外热释电传感器（PIR）：便宜，十块钱以内，但只能检测“有没有人”，不能区分人数。家里养宠物的话，猫从传感器前面路过都会误报。
毫米波雷达（LD2410）：能检测运动和无运动存在，可以统计一段时间内的人体目标数量，价格六七十块，实测精度不错。缺点是需要配置灵敏度参数，调起来有点玄学。
摄像头 + 图像识别：用OpenCV做人体检测，精度最高，但涉及隐私问题，在客厅装摄像头很多人心理上过不去。我最终没有采用。

最终我的方案是：进门处放一个LD2410雷达，输出检测到的人数，配合一个简单的去抖逻辑——连续10秒检测到的人数变化才生效，避免人短暂经过导致误判。实测下来，在2~4人的家庭场景里，准确率七八成是有的。这个精度对温控决策完全够用，因为人数影响温度推荐本身就有容错空间。

2.3 电量实时监控：PZEM-004T是最省心的选择

监控空调耗电量，我用的是PZEM-004T电能计量模块。它是一款支持串口通信的交流电测量模块，能直接读出电压、电流、功率、电量、功率因数，精度1%左右，淘宝价三十多块钱，简直是DIY项目的福音。

接线方法不复杂，但必须强调安全：模块的“火线输入”串接到空调插座的火线上，零线并接到零线端子，注意断电操作，别拿生命开玩笑。模块的串口输出接到树莓派或ESP32的UART接口，用一根USB转TTL线也能临时测试。

读数据用现成的库就行。以Python为例：

import serial import time ser = serial.Serial('/dev/ttyUSB0', baudrate=9600, timeout=1) def read_pzem(): # PZEM-004T V3.0 支持Modbus RTU # 发送读取指令：01 04 00 00 00 0A 71 04 cmd = bytes.fromhex('01 04 00 00 00 0A 71 04') ser.write(cmd) time.sleep(0.2) data = ser.read(50) if len(data) >= 25: voltage = int.from_bytes(data[3:5], 'big') / 10.0 current = int.from_bytes(data[5:7], 'big') / 1000.0 power = int.from_bytes(data[7:9], 'big') / 10.0 energy = int.from_bytes(data[9:13], 'big') * 0.001 # kWh return { 'voltage': voltage, 'current': current, 'power': power, 'energy': energy } return None

注意，PZEM-004T V3.0的Modbus协议和旧版不一样，买的时候问清楚版本。旧版用脉冲输出，读数据方式完全不同，别买错了。实测中这个模块会偶尔丢包，我在主循环里加了“读到None就重试3次”的机制，基本能稳定运行。

3. 推荐算法：别玩玄学，用热舒适模型说话

3.1 为什么要参考PMV/PPD模型

温度推荐不能拍脑袋“26℃万能”。人体的热舒适感实际上是环境温度、湿度、风速、穿着量、活动量（代谢率）共同作用的结果。学术界有一套经典模型叫PMV（预测平均评价）和PPD（预测不满意百分比），是丹麦教授Fanger在上世纪80年代提出的。PMV从-3（冷）到+3（热），0代表中性舒适；PPD则是预测会有百分之多少的人对热环境不满意。

公式比较复杂，但我们可以把它简化成工程可用的几个结论：

夏季凉感 = 温度降低 + 风速增加 + 湿度降低，三者可以互相补偿。
当湿度在40%~60%时，体感温度比实际温度更接近真实温度；湿度超过70%，体感温度会明显上升。
冬季热感 = 温度升高 + 辐射热（暖气/阳光）+ 风速降低。

在代码里我不直接算PMV，而是用它的核心思想构建一个“体感温度”修正值，再决定目标温度和模式。这套做法参考了ASHRAE 55标准的简化实现。

3.2 制冷、制热、除湿：模式决策的判断逻辑

模式选择的坑比我想象的多。刚开始我只判断“室内温度高于26℃就制冷，低于20℃就制热”，结果梅雨季翻车了：室内温度27℃，湿度80%，开制冷模式温度是降下来了，但体感还是黏糊糊的，电费也居高不下。

后来我把湿度纳入了模式决策：

场景	温度范围	湿度范围	推荐模式
盛夏闷热	> 28℃	> 70%	先除湿20分钟，再转制冷
典型夏季	26~28℃	40%~70%	制冷
梅雨低温	24~27℃	> 75%	除湿
阴冷冬季	< 20℃	40%~60%	制热
干冷冬季	< 20℃	< 40%	制热 + 加湿（若设备支持）

这个表格看起来简单，但背后有几个工程上的考量：

除湿模式并不是“温度没到就开”。它的工作原理是让压缩机间歇运行、风机低速运转，让蒸发器温度低于空气露点，水蒸气凝结排出。这个过程制冷量小，但耗电量也比制冷模式低。如果房间温度超过28℃，除湿模式的降温能力不足，人会很难受，这时候应该先制冷把温度压下来。
“先除湿20分钟再制冷”是我实测的优化策略。在南方梅雨季，这个组合比纯制冷模式每小时能省0.1度电左右，体感却更清爽。
制热模式下，如果房间湿度太低，空气会特别干，嗓子难受。决策引擎在湿度低于40%时会在报告里提示“建议配合加湿器”，这算是对舒适度的一个辅助提醒。

3.3 推荐温度计算：一个既省电又不难受的公式

设定温度怎么算？市面上很多智能温控直接给一个固定值26℃，这太粗糙了。我用的方法是“动态目标温度”，公式如下：

推荐设定温度 = 基准温度 + 温差修正 + 人数修正 + 电价修正

其中：

基准温度：夏季设定为26℃，冬季设定为20℃。
温差修正：当室外温度和室内温度差超过8℃时，每超过1℃，推荐设定温度往室外温度方向调高/调低0.3℃。这样做的原因是，室内外温差越大，热量传递越快，空调需要维持的功率就越高。比如室外38℃，室内30℃，温差8℃以上，推荐设定温度就是26 + (38 - 30 - 8) * 0.3 = 26.6℃。设定温度提高0.6℃，耗电量能下降6%左右，而体感差异并不大。
人数修正：每增加一个人，相当于增加了约80W的人体散热。房间里如果超过2人，每多一个人，推荐设定温度下调0.5℃。上面的例子，如果有4个人，就是26.6 - 0.5 * 2 = 25.6℃。
电价修正：这是被很多人忽略的一点。结合峰谷电价，在电价贵的时段（通常14:00~17:00），尽量让设定温度偏高一点，减少压缩机负荷；在电价便宜的凌晨时段，如果房间没人但需要维持基础温度，可以让空调提前把温度降到位然后进入低功率维持。

下面是推荐温度计算的核心代码，我用Python写了个简版：

def recommend_temperature(indoor_temp, outdoor_temp, people_count, is_cooling=True): # 基准温度 base_temp = 26 if is_cooling else 20 # 温差修正 temp_diff = abs(outdoor_temp - indoor_temp) diff_adjust = 0 if temp_diff > 8: diff_adjust = (temp_diff - 8) * 0.3 if outdoor_temp > indoor_temp and is_cooling: # 室外太热，适当调高设定温度 pass elif outdoor_temp < indoor_temp and not is_cooling: diff_adjust = -diff_adjust # 人数修正 people_adjust = 0 if people_count > 2: people_adjust = -0.5 * (people_count - 2) # 电价修正（峰电时段调高1℃，谷电时段调低1℃） hour = datetime.now().hour price_adjust = 0 if 14 <= hour <= 17: price_adjust = 1.0 elif 23 <= hour or hour <= 6: price_adjust = -1.0 # 最终推荐 recommended = base_temp + diff_adjust + people_adjust + price_adjust # 边界限制：制冷模式不低于22℃，不高于29℃ if is_cooling: recommended = max(22, min(29, recommended)) else: recommended = max(18, min(26, recommended)) return round(recommended, 1)

这个公式最大的好处是“每个参数都解释得清”。我可以在手机上看到“为什么推荐26.5℃”的完整拆解——室外温差修正+0.6，人数修正-0.5，电价修正+0.4，逻辑透明。用户信任度比黑盒AI高得多。

需要说明的是，这里的人数修正和温差修正是我根据室内热负荷的简化估算，实际效果受房间面积、墙体隔热系数影响，如果你想更精确，可以在报告里加入“用户期望温度”的反馈，不断修正修正系数。

4. 系统实现：采集、决策、控制、显示的完整闭环

4.1 红外控制：让普通空调也变得“智能”

如果你的空调是老款，没有WiFi联网功能，红外发射器是最通用的方案。我用的是HX1838红外接收模块（用来学习遥控器码）+ 一个红外发射管，接在树莓派的GPIO上。底层库用gpiotx或者pigpio，发射NEC编码的原始波形。

学习空调遥控器的流程比较繁琐，但一次搞定后面就爽了：

用红外接收模块录制遥控器发出的原始波形数据（时长、载波、脉冲序列）。
把录到的数据以JSON格式保存到本地，比如“制冷26度.json”。
发送时，读JSON，用红外发射管重放。

录制代码的核心是记录每个脉冲的持续时间：

import pigpio import time pi = pigpio.pi() rx_pin = 17 # 红外接收模块信号引脚 def record_ir(duration=1.0): pi.set_mode(rx_pin, pigpio.INPUT) pi.set_glitch_filter(rx_pin, 100) pulses = [] last_tick = pi.get_current_tick() start = time.time() while time.time() - start < duration: level = pi.read(rx_pin) tick = pi.get_current_tick() diff = pigpio.tickDiff(last_tick, tick) if diff > 0: pulses.append((level, diff)) last_tick = tick time.sleep(0.0001) return pulses

录制过程中有个细节：每个遥控器按键按一次，要记录持续1秒左右的波形，里面包含引导码、地址码、命令码和重复码。如果录制时间太短，可能只录到一次完整发射，发送时空调不响应。我踩过这个坑，后来把录制时间加长到1.5秒，并且连续按键两次，取波形完整的那次。

发送的时候，要根据原始波形的载波频率（一般是38kHz）重新调制。pigpio库的wave_send_with_carrier函数可以直接指定频率，比较省事。

如果你的空调是智能空调（小米、格力、美的带有联网模块），也可以走云API连接，调用厂商的调温接口。但实话说，云API的鉴权流程和token维护比本地红外麻烦得多，而且可能因为固件升级导致接口变化。我现在的方案是：优先走红外，因为所有数据都本地可控；如果空调自带WiFi且API稳定，再考虑双通道冗余。

4.2 主控逻辑：一分钟一轮的决策循环

整个系统的核心是一个无限循环，每60秒执行一次。流程如下：

读取室内温度、湿度、人数、实时功率。
拉取最新的室外温度（缓存超过30分钟才更新）。
运行推荐算法，得到推荐温度和推荐模式。
将推荐值与当前空调状态比较，如果温度差超过1℃或模式不同，发送红外控制指令。
记录本次数据到SQLite数据库。

主循环的Python伪代码：

import sqlite3 import time from datetime import datetime DB = sqlite3.connect('ac_helper.db') DB.execute('''CREATE TABLE IF NOT EXISTS metrics ( ts TEXT PRIMARY KEY, indoor_temp REAL, outdoor_temp REAL, people_count INTEGER, power REAL, recommend_temp REAL, recommend_mode TEXT, actual_temp REAL, actual_mode TEXT )''') while True: indoor = read_indoor_sensor() outdoor = get_outdoor_temp() # 带缓存 people = radar.read_people_count() power = read_pzem()['power'] rec_temp, rec_mode = recommend(indoor, outdoor, people) # 判断是否需要调整空调 current_temp, current_mode = get_ac_state() if abs(current_temp - rec_temp) >= 1 or current_mode != rec_mode: send_ir('设定温度', rec_temp) send_ir('模式', rec_mode) # 入库 DB.execute('''INSERT INTO metrics VALUES (?,?,?,?,?,?,?,?)''', (datetime.now().isoformat(), indoor, outdoor, people, power, rec_temp, rec_mode, current_temp, current_mode)) DB.commit() time.sleep(60)

这里要特别注意：控制空调的频次不能太高。我曾经把轮询间隔压到10秒，结果空调压缩机频繁启停，不仅更费电，还容易损坏设备。现在用的策略是“死区控制”——推荐温度和当前设定温度相差超过1℃才调整，这样既保证了响应速度，又避免了频繁变动。

4.3 数据展示：一个轻量的Web仪表盘

为了让省电报告有数据支撑，我顺手用Flask搭了一个很简单的Web仪表盘。页面展示四块内容：当前环境数据卡片、24小时温度曲线、24小时功率曲线、本周省电汇总表。

图表用ECharts，从SQLite里读数据生成JSON传给前端。核心代码就是查询最近24小时数据然后取均值：

from flask import Flask, jsonify app = Flask(__name__) @app.route('/api/stats') def stats(): rows = DB.execute(''' SELECT datetime(ts) as hour, AVG(indoor_temp), AVG(power), AVG(recommend_temp) FROM metrics WHERE ts >= datetime('now', '-24 hours') GROUP BY strftime('%Y-%m-%d %H', ts) ORDER BY hour ''').fetchall() return jsonify([{ 'hour': r[0], 'indoor_temp': r[1], 'power': r[2], 'rec_temp': r[3] } for r in rows])

仪表盘跑在内网，手机浏览器直接访问树莓派的IP就能看。这个展示层不是必需品，但有了它，调试决策逻辑时方便太多——你可以一眼看出推荐温度和实际运行温度差在哪里。

5. 省电报告：用数据说话，而不只是“感觉省了”

5.1 报告里放哪些指标

每周日晚上，系统会自动生成一份《空调节能周报》。报告包含以下核心指标：

本周总耗电量、日均耗电量、功率峰值。
平均室内温度、平均室外温度、平均人数。
推荐设定温度与实际设定温度的偏差时间占比。
模式占比：制冷多少小时、除湿多少小时、制热多少小时。
节能估算：与“固定26℃全天开机”的基线相比，本周省了多少度电、多少钱。

其中“节能估算”是用户最关心的，也是需要小心计算的。基线的定义要合理：我假定不装这个系统时，用户会按固定26℃全天运行，压缩机不停机。实际上很多用户习惯23℃甚至更低，所以这个基线是保守估计，实际节省可能更多。报告里我会明确标注“估算值”，避免误导。

生成报告用Python的Jinja2模板渲染HTML，再用weasyprint转成PDF。模板里用matplotlib画了两张图：温度-功率关系散点图和分时耗电柱状图。

5.2 节能账本的实际测算

以我家实测数据为例：1.5匹变频空调，夏季每天运行8小时，设定26℃。有推荐助手之前，我习惯24℃，每天耗电约7.2度。使用推荐助手后，设定温度平均升到26.5℃，偶尔触发“先除湿后制冷”策略，每天耗电降到5.4度左右。每天节省约1.8度，一个月省54度，按0.6元/度算，一个月省32.4元。

这还是在没有利用峰谷电价的情况下。如果加上凌晨预冷策略，把空调在谷电时段把房间温度降到23℃，然后白天只在峰电时段维持温度，一个月还能再多省10元左右。省电效果最明显的是梅雨季，除湿模式相比制冷模式每小时能省0.1度电，一天下来就是0.8度左右。

当然，有个重要的前提：变频空调设定温度每调高1℃，制冷能耗降低约6%~10%；定频空调因为压缩机频繁启停，节省幅度更大。如果是老旧定频空调，效果会更明显，但舒适度会差一些，因为压缩机启停带来的温度波动比较大。

5.3 报告生成自动化

用cron在每周日晚上10点触发报告脚本，生成PDF后推送到手机。推送我用的是钉钉机器人Webhook，简单配置一下就行。核心代码：

def generate_weekly_report(): data = query_week_data() baseline_energy = 1.2 * data['running_hours'] # 1.2kW * 小时 actual_energy = data['actual_energy'] saved = baseline_energy - actual_energy html = render_template('report.html', data=data, saved=saved) pdf = HTML(string=html).write_pdf('weekly_report.pdf') send_to_dingtalk(pdf)

生成报告前要注意数据质量。如果某个传感器离线了一整天，报告里的“平均室内温度”就会失真。我在脚本里加了数据完整性检查：如果一周内数据缺失超过10%，报告会标注“数据完整度偏低，结论仅供参考”。这个小细节避免了“报告数据不准导致用户误判”的尴尬。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

现象	可能原因	解决办法
室内温度读数明显偏低	传感器靠近空调出风口	把传感器移到远离空调的位置，离地1.2米，加屏蔽罩
空调不响应红外指令	录制波形不完整或载波频率不匹配	重新录制，录制时按下按键保持1秒以上；检查发射管角度
功率读数与电表不一致	PZEM-004T互感器精度偏差	用已知功率的电器（如电水壶）校准，调整系数
人数始终检测为0	LD2410雷达灵敏度配置过低	调高运动检测门限，设置“无人判定延迟”为20秒
除湿模式启动后温度降不下来	房间温度超过28℃，除湿能力不足	改为先制冷20分钟再切入除湿
省电报告数据缺失	采集程序崩溃或传感器离线	查看日志，确认采集程序是否常驻，增加看门狗重启

6.2 几个让我印象深刻的“坑”

第一个坑：红外录制时遥控器电量不足。我家空调遥控器用了两年没换电池，录出来的波形脉冲宽度明显偏短，发射后空调完全没反应。排查了一下午，最后换了新电池、重新录制，问题立刻解决。提醒大家，录制红外码之前先确认遥控器是满电状态。

第二个坑：PZEM-004T串口数据偶尔乱码。刚开始我以为模块坏了，后来发现是树莓派USB转TTL的供电不稳，导致电平信号抖动。解决方法是把PZEM的VCC接到树莓派的5V引脚（而不是USB的5V），并共地。现在运行两个月，乱码基本消失。

第三个坑：SQLite数据库写入阻塞。采集程序每60秒写一条记录，理论上毫无压力。但我刚开始用Flask的调试模式跑Web服务，调试模式的reloader会重启进程，导致数据库被多处连接，偶尔出现“database is locked”。解决方法是关闭reloader，同时给SQLite连接加一个超时参数。

第四个坑：人数检测在全家安静看电视时失效。LD2410雷达默认的微动检测灵敏度太低，人坐在沙发上刷手机，只有手指动，雷达判断为“静止”，人数被误判为0。这个问题的关键是区分“人体存在”和“运动检测”，雷达要开启“存在检测”模式，判定时间窗口拉长到15秒以上。

第五个坑：空调压缩机频繁启停。我一开始用的控制策略是“每5分钟对比一次推荐温度，只要差0.1℃就发指令”，结果压缩机一小时内启停好几次，电费反而涨了。后来加入死区控制（温差超1℃才动作）和最短运行时间保护（压缩机启动后10分钟内不再发停机指令），终于消停了。

7. 项目扩展：从“省电助手”到“家庭能源管家”

做完了空调省电助手，你会发现这套“数据采集 + 规则决策 + 可视化报告”的架构思路完全可以平移到其他家电上。我接下来的计划是把它接到热水器和冰箱上，统一做一个家庭能源管理平台。热水器的峰谷电价策略和空调预冷逻辑很像，冰箱则主要是温度区间优化。

另一个很有价值的扩展方向是光伏。如果家里装了太阳能板，空调的决策逻辑可以进一步和发电量联动：光伏发电充足时，提前把房间预冷到目标温度；发电不足时，适当提高设定温度。这样“省电费”就从“少用电”升级成了“多用自己发的电”，经济价值更大。

最后说一个我在整个项目里最深的体会：省电不是靠“硬扛热”，而是靠“聪明地调”。以前的观念是“空调开26℃就是省电”，但实际上“26℃ + 低风速 + 定时关机”可能比“23℃ + 大风量”更费电。因为没有数据支撑，你根本不知道哪个策略最优。这个项目花了两周时间做出来，但真正值钱的不是那几十行代码，而是——你终于能用数据回答“怎么开空调既舒服又省钱”这个问题了。

如果你也打算复刻这个项目，我的建议是：先别急着写代码，先把传感器买齐，手动记录三天“温度、湿度、人数、耗电量”的真实数据。有了基线数据，你才知道你的推荐算法到底有没有用，也才能说服你的家人“按这个方案调真能省电”。毕竟，智能家居最大的敌人不是技术，而是“我觉得不冷”和“电费单还没出来”之间的认知落差。