七月的电费单到手的那一刻我才发现空调才是夏天真正的“隐形大户”。一台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, baudrate9600, timeout1) 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_coolingTrue): # 基准温度 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(duration1.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, datadata, savedsaved) pdf HTML(stringhtml).write_pdf(weekly_report.pdf) send_to_dingtalk(pdf)生成报告前要注意数据质量。如果某个传感器离线了一整天报告里的“平均室内温度”就会失真。我在脚本里加了数据完整性检查如果一周内数据缺失超过10%报告会标注“数据完整度偏低结论仅供参考”。这个小细节避免了“报告数据不准导致用户误判”的尴尬。6. 常见问题与排查技巧实录6.1 高频问题速查表现象可能原因解决办法室内温度读数明显偏低传感器靠近空调出风口把传感器移到远离空调的位置离地1.2米加屏蔽罩空调不响应红外指令录制波形不完整或载波频率不匹配重新录制录制时按下按键保持1秒以上检查发射管角度功率读数与电表不一致PZEM-004T互感器精度偏差用已知功率的电器如电水壶校准调整系数人数始终检测为0LD2410雷达灵敏度配置过低调高运动检测门限设置“无人判定延迟”为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℃ 大风量”更费电。因为没有数据支撑你根本不知道哪个策略最优。这个项目花了两周时间做出来但真正值钱的不是那几十行代码而是——你终于能用数据回答“怎么开空调既舒服又省钱”这个问题了。如果你也打算复刻这个项目我的建议是先别急着写代码先把传感器买齐手动记录三天“温度、湿度、人数、耗电量”的真实数据。有了基线数据你才知道你的推荐算法到底有没有用也才能说服你的家人“按这个方案调真能省电”。毕竟智能家居最大的敌人不是技术而是“我觉得不冷”和“电费单还没出来”之间的认知落差。