尧图网站建设 
简介这是一套面向电力行业的智能管理小程序源码涵盖电力数据监控、负荷分析、故障预警、远程抄表、能耗统计、智能电表集成、设备管理、数据可视化、用户行为分析与需求预测等功能模块适合电力企业技术人员、小程序开发者及高校学生参考学习。压缩包共2000个文件主要为js逻辑、json配置、wxml页面、wxss样式辅以md与ts说明文件包体仅1.27MB便于导入与修改。已有107人下载学习适合作为电力行业智能化改造或毕业设计的项目蓝本。资源提供完整项目代码涵盖功能页面、数据交互逻辑、实时图表展示及用户行为分析等实现并附赠DOCX说明文件便于理解模块间协同逻辑可直接用于二次开发或作为课程设计与毕业设计参考。1. 电力智能管理小程序从电表到面板一条链路解决四类现场问题你管着一个园区、一栋写字楼或者一条生产线的用电最头疼的往往不是电费贵而是“不知道电去哪了、设备什么时候出问题”。这个标题里的电力行业智能管理小程序就是把传统电力监控从“机房上位机”搬到手机微信里智能电表负责采数小程序负责展示、报警和抄表后端负责负荷分析、预测和节能建议。它适合物业电工、小型工厂能源管理员、充电桩和光伏运维人员也适合售电公司给客户做用电行为报告。反直觉的一点是这类项目最不该一上来就画界面而是先把电表协议、数据字段和告警规则定清楚否则后面每次换表型都是一次返工。2. 先把数据链路立住电表协议、数据表结构与小程序可视化选型做电力监控小程序常见做法是先定“数据从哪来”再谈界面。智能电表集成不是把电表接到插座上就行现场表计协议五花八门有的走 DL/T645有的走 Modbus-RTU还有不少厂家私有协议。如果一开始不抽象出一层统一采集接口后面换一个品牌电表抄数代码就得重写一遍。2.1 电表协议选型先分清DL/T645、Modbus和厂家私有协议国内公网电表最常见的是 DL/T645-2007 协议它和电能表国标绑定支持正向有功、反向有功、电压、电流、功率因数等数据项。工业现场则大量使用 Modbus-RTU通过寄存器地址读原始数值。两者差别很大维度DL/T645-2007Modbus-RTU数据标识4字节数据标识长度寄存器地址功能码典型读法请求-应答含校验和读保持寄存器 0x03小数位协议定义单位在数据项描述里由厂家寄存器表决定批量采集一次读一项循环较多一次可读连续多路寄存器兼容性国网/南网通用工业表、光伏逆变器、采集器通用我一般建议优先选支持 DL/T645 且兼容 Modbus 的表计两个口都留出来。采集器通过 RS485 总线把多块电表接到一台边缘网关网关再通过 MQTT 把数据推到云服务器。小项目也可以省略网关直接用带网口的电能表走 Modbus-TCP 或 DL/T645 over TCP但超过 30 块表时轮询会很慢。下面是读 Modbus 电能表电压、电流的 Python 示例依赖pymodbusfrom pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.1.50, port502, timeout3) if not client.connect(): raise RuntimeError(电表连接失败检查IP和端口) # 假设厂家寄存器表电压起始地址 0x0000电流 0x0002功率 0x0004 # 使用功能码 0x03 读连续 6 个寄存器每个量占 2 个寄存器32位float result client.read_holding_registers(0x0000, count6, unit1) if result.isError(): raise RuntimeError(寄存器读取失败请核对地址和从站号) values result.registers voltage_high values[0] voltage_low values[1] current_high values[2] current_low values[3] # 常见做法IEEE754 大端模式解析32位浮点 import struct voltage_bytes struct.pack(HH, voltage_high, voltage_low) voltage struct.unpack(f, voltage_bytes)[0] print(fA相电压: {voltage:.1f}V) client.close()这里有两个参数很容易踩坑unit1是 Modbus 从站号多块表并联时每块表要设不同站号count6表示连续读 6 个寄存器但实际每个电量参数可能占 2 个寄存器如果寄存器表里每个量只占 1 个寄存器你的解析长度就要改。还有字节序有的表厂用大端有的用小端甚至还有中端别急着写死先用厂家文档里的数值和自己读到的十六进制核对一遍。DL/T645 的解析逻辑和 Modbus 完全不同它的数据帧里带控制码、数据标识和校验和读法更像“发一条命令电表回一段长报文”。如果你现场既有 DL/T645 电表又有 Modbus 表最好在采集层做一个统一数据模型把电表地址、协议类型、寄存器起始位置、缩放系数都存到配置表里采集服务只负责输出标准化 JSON。这样到后面做实时数据可视化时小程序和后端根本不用关心底层协议差异。2.2 建设最小数据表用SQL定义负荷、电量和设备三张核心表采集服务把电表数据标准化成 JSON 后后端要落库。电力监控项目和普通管理系统的差别在于数据是高频时序数据不是单纯增删改查。最忌讳用一张大宽表把所有电表字段堆在一起那样查询“某块表昨天每小时的平均功率”会变得非常慢。我常用的库是 MySQL 存基础数据和告警事件用 TimescaleDB 或者 PostgreSQL 时序分区表存分钟级负荷数据。如果只是中小规模项目MySQL 也够用但要把分钟表按月分表。下面是三张核心表的建表 SQL-- 设备表每块电表、每个回路的基本信息 CREATE TABLE device ( id INT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) UNIQUE NOT NULL COMMENT 表计编号/资产编号, device_name VARCHAR(128) NOT NULL COMMENT 设备名称如1号厂房总柜, protocol_type VARCHAR(16) NOT NULL DEFAULT modbus COMMENT modbus/dlt645, slave_id INT NOT NULL DEFAULT 1 COMMENT Modbus从站号, register_base INT NOT NULL DEFAULT 0 COMMENT 起始寄存器地址, ct_ratio DECIMAL(10,3) NOT NULL DEFAULT 1 COMMENT 电流互感器变比, pt_ratio DECIMAL(10,3) NOT NULL DEFAULT 1 COMMENT 电压互感器变比, enabled TINYINT(1) NOT NULL DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 负荷数据表按月分表存储功率、电压、电流等实时指标 CREATE TABLE load_data_202501 ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) NOT NULL COMMENT 对应device.device_code, collect_time DATETIME NOT NULL COMMENT 采集时间统一用设备本地时间, active_power DECIMAL(12,3) NOT NULL COMMENT 有功功率(kW), reactive_power DECIMAL(12,3) DEFAULT 0 COMMENT 无功功率(kvar), voltage DECIMAL(8,2) DEFAULT 0 COMMENT 相电压(V), current DECIMAL(8,2) DEFAULT 0 COMMENT 相电流(A), power_factor DECIMAL(5,3) DEFAULT 0 COMMENT 功率因数, frequency DECIMAL(5,2) DEFAULT 50 COMMENT 频率(Hz), INDEX idx_device_time (device_code, collect_time) ); -- 电量表按天累积方便统计日电量、月电量 CREATE TABLE energy_daily ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) NOT NULL, stat_date DATE NOT NULL, active_energy_kwh DECIMAL(14,4) COMMENT 正向有功总电量(kWh), reverse_energy_kwh DECIMAL(14,4) COMMENT 反向有功电量(kWh), peak_power DECIMAL(12,3) COMMENT 当日最大需量(kW), valley_power DECIMAL(12,3) COMMENT 当日最小功率(kW), UNIQUE KEY uk_device_date (device_code, stat_date) );注意load_data_202501这种月表是为了控制单表行数一个中型园区一个月可能产生几百万条记录。如果用了 TimescaleDB 就不用按月建表按时间分区即可。另一个容易忽略的是ct_ratio和pt_ratio变比电表读到的电流是互感器二次侧电流需要乘变比才是真实值。比如 250A 电流互感器变比是 250/550实际电流 二次电流 × 50这个系数千万别在采集层和小程序端各做一次否则值会翻倍。电力数据监控里时间基准也必须统一。电表内部时钟往往会漂移我建议采集服务每次读到电表时间如果和服务器时间偏差超过 5 分钟就在采集侧用服务器时间覆盖记录时间而不是信任电表时间。省得后面做用电负荷分析时曲线高峰老是往左或往右偏移一段时间。2.3 实时数据可视化小程序端用ucharts还是原生canvas数据落库后下一步是让小程序把实时数据画出来。微信小程序本身不支持 DOM常见的图表组件是 echarts-for-weixin 和 uCharts。我在实际项目中更倾向 uCharts它体积小支持 H5、微信小程序、App而且渲染性能在低端安卓机上比 echarts 稳定。uCharts 的折线图、柱状图和仪表盘基本覆盖电力监控需求。下面是小程序端用 uCharts 绘制当日负荷曲线的核心代码以微信原生开发为例// pages/dashboard/dashboard.js const uCharts require(../../utils/u-charts.min.js); Page({ data: { chartData: null, deviceCode: DEV001 }, onLoad(options) { this.setData({ deviceCode: options.deviceCode || DEV001 }); this.loadTodayCurve(); }, loadTodayCurve() { wx.request({ url: https://your-api.com/api/v1/load/curve?deviceCode${this.data.deviceCode}date2025-03-18, method: GET, header: { X-Token: wx.getStorageSync(token) }, success: (res) { const series res.data.series; // [{time: 08:00, power: 125.6}, ...] const categories series.map(item item.time); const data series.map(item item.power); this.setData({ chartData: { categories: categories, series: [{ name: 有功功率(kW), data: data }] } }); this.renderChart(); } }); }, renderChart() { if (this.data.chartData) { this.chart new uCharts({ type: line, context: wx.createCanvasContext(loadCurveCanvas), categories: this.data.chartData.categories, series: this.data.chartData.series, animation: false, width: 750, height: 350, dataLabel: false, xAxis: { disableGrid: true, labelCount: 6 }, yAxis: { gridType: dash, min: 0 }, legend: { show: true, position: top } }); } } });这里的参数width: 750是按微信小程序的逻辑分辨率来的canvas 真实宽度是 750 除以wx.getSystemInfoSync().windowWidth做像素换算如果直接填 750 在视网膜屏上会模糊。进阶做法是用upx2px(750)换算或者从wx.createSelectorQuery()里拿到实际节点宽度再设置。animation: false是为了首屏渲染更快后续加载更多数据时也可以关闭动画。实时数据可视化不只是画一条曲线还要考虑页面下拉刷新、自动定时刷新和大屏/手机屏切换。如果需求是“实时”建议不要每秒请求一次接口用 15 秒定时轮询加 WebSocket 推送组合页面可见时轮询后台切入前台时立即刷新。否则几百块表同时轮询后端压力会很快打满。3. 用电负荷分析落到代码行为聚类、需求预测和节能建议怎么出数据链路通了接下来才是这个标题里最有价值的部分——用电负荷分析。很多团队把“负荷分析”做成了只是画个饼图实际上用户想看的是哪些设备在偷懒、哪些时间段能错峰、明天大概用电多少、节能建议从哪里下手。这部分不用一上来上深度学习先用可解释的统计和经典机器学习就够了。3.1 特征工程把原始电表读数变成可分析的负荷指标从分钟级负荷数据到用户行为特征中间需要做降采样和聚合。我一般先按小时求平均、按天算峰谷再派生下面几个指标日负荷率平均功率/最大功率、峰谷差率、峰功率-谷功率/峰功率、夜间最小功率判断是否有待机耗电、最大需量出现时间判断是上班尖峰还是晚上尖峰。这些特征才是用电行为分析的输入。下面是直接从 MySQL 小时表聚合日特征的计算脚本import pandas as pd import pymysql conn pymysql.connect(hostlocalhost, userenergy_user, passwordxxx, dbenergy_mgmt) # 读某块表一天的小时级平均功率 sql SELECT DATE_FORMAT(collect_time, %%Y-%%m-%%d %%H:00) AS hour_point, AVG(active_power) AS avg_power FROM load_data_202503 WHERE device_code DEV001 AND collect_time 2025-03-18 00:00:00 AND collect_time 2025-03-19 00:00:00 GROUP BY hour_point ORDER BY hour_point df pd.read_sql(sql, conn) df[hour] df[hour_point].str[-2:].astype(int) peak_power df[avg_power].max() valley_power df[avg_power].min() avg_power df[avg_power].mean() load_rate avg_power / peak_power if peak_power else 0 peak_valley_diff_rate (peak_power - valley_power) / peak_power if peak_power else 0 print(f当日最大需量: {peak_power:.2f} kW) print(f当日最小功率: {valley_power:.2f} kW) print(f负荷率: {load_rate:.2%}) print(f峰谷差率: {peak_valley_diff_rate:.2%}) conn.close()这里%%Y是因为用 pymysql 和 Python 字符串格式化SQL 里需要转义百分号直接写%Y会报错。另一个容易犯的问题是GROUP BY hour_point本身没问题但 MySQL 的DATE_FORMAT输出字符串排序依赖字符串字典序如果跨年就会出现 2025-01 排在 2024-12 前面的情况所以ORDER BY hour_point看起来对实际上按字符串排也符合时间顺序前提是格式统一用%Y-%m-%d %H:00。负荷率低说明设备容量有明显的冗余或者用电集中在很短时间。峰谷差率高的用户适合做削峰填谷和需求响应引导。这些指标不能只算一天要向前滚动 30 天取趋势才能在电力需求预测里发挥价值。3.2 用电行为聚类用KMeans识别高耗能、峰谷型和异常用户有了日特征表行为分析最常用的就是聚类。典型的三类结果一是“办公型”白天高、晚上低负荷率中等二是“连续生产型”全天平稳负荷率高三是“冲击型”短时高功率负荷率很低。用 KMeans 在二维特征负荷率、峰谷差率上就能分开。下面是完整聚类代码包括归一化和图标注释from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler import numpy as np # 假设 features 是 DataFrame每行是一个用户一天的特征 # 列user_id, load_rate, peak_valley_diff_rate features pd.read_sql(SELECT device_code AS user_id, load_rate, peak_valley_diff_rate FROM user_daily_features WHERE stat_date2025-03-18, conn) X features[[load_rate, peak_valley_diff_rate]].values # 归一化两个指标量纲不同load_rate 是0-1peak_valley_diff_rate 也是0-1 # 但分布差异大标准化后聚类更稳定 X_scaled StandardScaler().fit_transform(X) # 用轮廓系数试出 k3 通常比较稳定 model KMeans(n_clusters3, random_state42, initk-means, n_init10) labels model.fit_predict(X_scaled) features[cluster] labels # 输出每类中心反归一化后对应真实负荷率/峰谷差率中心 centers model.cluster_centers_ print(聚类中心(标准化后):, centers) # 业务含义解释load_rate 高 峰谷差低 - 连续生产型 for c in range(3): subset features[features[cluster] c] avg_lr subset[load_rate].mean() avg_pv subset[peak_valley_diff_rate].mean() print(f第{c1}类: 用户数{len(subset)}, 平均负荷率{avg_lr:.2f}, 平均峰谷差率{avg_pv:.2f})n_init10是 KMeans 的常用参数表示跑 10 次取最优避免初始化点差导致结果不稳定。random_state42是为了结果可复现。这里最大的坑是“聚类结果漂移”今天跑出来 3 类明天数据更新可能变成 2 类或 4 类。解决办法是固定 K 值并且把聚类中心存下来作为下一批用户的初始中心而不是每次都重新随机。异常用户识别不一定要聚类更实用的是基于阈值的事件触发。比如某个设备夜间最小功率超过 10kW基本可以判断有空载耗电功率因数低于 0.5 并且持续 15 分钟大概率有设备无功补偿失效。这类规则要放到预警系统里而不是等日报告出来才告诉用户。3.3 电力需求预测与节能建议用线性回归做一个可解释的基线电力需求预测在这个项目里主要用来做两件事一是给用户“明天最大需量”预警避免超需量罚款二是给节能优化建一个基线得出“如果没有优化你会用多少电”。我一般从简单的多因子线性回归开始用昨日同时段负荷、当天温度、星期几作为特征。温度数据可以接天气 API也可以直接用负荷自回归。下面是一个 24 小时逐小时负荷预测的最小 Python 示例import pandas as pd from sklearn.linear_model import LinearRegression from sklearn.model_selection import train_test_split # 读取过去 30 天的逐时负荷和温度 df pd.read_sql( SELECT collect_time, active_power, temperature FROM load_hourly_history WHERE device_codeDEV001 AND collect_time NOW() - INTERVAL 30 DAY , conn) df[hour] df[collect_time].dt.hour df[weekday] df[collect_time].dt.weekday # 构造自回归特征前一天同一时刻的功率 df[prev_day_power] df.groupby(hour)[active_power].shift(24) # 去掉缺失值再训练 df_model df.dropna(subset[prev_day_power, temperature]) features df_model[[hour, weekday, prev_day_power, temperature]] target df_model[active_power] X_train, X_test, y_train, y_test train_test_split(features, target, test_size0.2, shuffleFalse) model LinearRegression() model.fit(X_train, y_train) import joblib joblib.dump(model, ../../models/daily_load_model.pkl) print(f训练完成测试R2: {model.score(X_test, y_test):.3f})shift(24)是关键它取同小时前一天的历史负荷模型核心就是“今天某时的负荷和昨天同时段强相关”。shuffleFalse很重要时间序列切分不能打乱顺序否则会泄露未来信息导致 R2 虚高。温度特征可选如果不想接天气 API可以先不加用前天、昨天和一周前同一时刻的负荷做三变量自回归准确率也很可观。预测得到负荷曲线后节能优化建议就能落地。比如预测明天 14:00-16:00 将出现高峰提醒用户提前把储能放电夜间最小功率持续偏高建议排查待机设备功率因数低建议加无功补偿。这些都是从特征和预测结果直接推导出来的不需要黑匣子模型用户也更容易信服。4. 故障预警与远程抄表规则引擎、推送通道和小程序端表单前面讲了监控和分析这章解决两个业务动作设备坏了怎么办、电表怎么远程抄。故障预警系统不是越复杂越好真正在现场稳定运行的往往是几十条写死的规则而不是训练出来的异常检测模型。远程抄表则要处理好“抄表任务、冻结数据、缴费对账”三者关系再考虑小程序端录入和展示。4.1 预警规则引擎阈值、梯度、缺相和反向电量故障预警落地第一件事是把告警规则拆成四类越限、变化率、组合逻辑、电量异常。越限最简单比如电压超过 110% 或低于 85%变化率规则能捕捉“10 分钟内负荷从 30kW 跳到 120kW”这通常是启动电流冲击或设备故障组合逻辑比如“功率因数低于 0.5 且持续超过 15 分钟”才触发避免单点误报。下面是一个用 Python 写的最小规则引擎# rules/alert_engine.py class AlertEngine: def __init__(self, rules): self.rules rules # 规则列表每条是dict def evaluate(self, device_code, metric, value, ts): alerts [] for rule in self.rules: if metric ! rule[metric]: continue op rule[operator] threshold rule[threshold] # 越限类规则支持 , , , if op and value threshold: alerts.append(self._build_alert(rule, value, ts)) elif op and value threshold: alerts.append(self._build_alert(rule, value, ts)) # 梯度规则值相比上一个时间点的变化量 elif op delta_gt: prev_val rule.get(last_value, 0) if abs(value - prev_val) threshold: alerts.append(self._build_alert(rule, value, ts)) rule[last_value] value return alerts def _build_alert(self, rule, value, ts): return { device_code: rule.get(device_code, ANY), metric: rule[metric], level: rule.get(level, warning), # info/warning/critical message: f{rule[label]} 当前值 {value}阈值 {rule[threshold]}, ts: ts }这段代码的核心是operator抽象后面增加新类型只要扩展evaluate的分支。实际部署时我不建议自己写状态管理把预警阈值放到数据库表里避免改代码才能调参数。梯度规则里last_value如果存内存服务重启后就失灵所以要用 Redis 存上一时刻值或者改成连续 3 个采集周期都超阈值才触发这样更稳定。告警发送通道可以接微信订阅消息、短信和邮件。现场运维人员最喜欢的是微信订阅消息但订阅消息要求用户主动订阅且模板有次数限制所以重要告警还是得短信兜底。推送服务最好做成独立模块用 MQTT 或 Redis 队列解耦别把规则引擎放在采集线程里。4.2 远程抄表任务与推送从定时任务到微信订阅消息远程抄表听起来简单实际有一个坑不是每时每刻都在抄表而是按结算周期冻结数据。比如每天 0 点冻结正向有功总电量这个值是一天最后一条累计电量不能把当天每分钟电量加起来因为电表内部可能已经翻转清零。所以远程抄表要分两块实时采集用于监控定时冻结用于账务。我用 Python APScheduler 实现每天 0 点 5 分的抄表任务from apscheduler.schedulers.blocking import BlockingScheduler from collection.gateway import read_total_energy def daily_meter_reading_job(): device_list get_enabled_devices() for dev in device_list: # 读电表累计正向电量注意单位是kWh energy read_total_energy(dev) # 读电表当前时间防止电表时钟漂移影响冻结时间 meter_time read_meter_time(dev) save_daily_reading(dev[device_code], energy, meter_time) # 如果电量相比昨天的冻结值突然减少说明电表翻转或换表 yesterday get_yesterday_reading(dev[device_code]) if yesterday and energy 1 yesterday - 0.01: send_alert(dev[device_code], meter_rollback, f可能换表或清零:昨天{yesterday},今天{energy}) scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(daily_meter_reading_job, cron, hour0, minute5) scheduler.start()这里时间表达式hour0, minute5是每天零点零五分执行错开零点整点其他任务的高峰。energy 1 yesterday - 0.01这个判断允许 1kWh 的误差避免误差导致误报。如果电表支持冻结数据尽量读取电表自身的日冻结记录而不是每天去算差值因为很多电表断电时不会留存分钟数据。推送消息到微信小程序端典型流程是后端调微信订阅消息接口import requests def send_wechat_subscribe(openid, template_id, data_dict): url https://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token get_access_token() payload { touser: openid, template_id: template_id, page: pages/alert/alert, data: { thing1: {value: data_dict[device_name]}, number2: {value: data_dict[power]}, thing3: {value: data_dict[message]} } } resp requests.post(url, jsonpayload, timeout3) # 常见错误码43101 表示用户未订阅41030 表示模板ID错误 if resp.json().get(errcode) ! 0: print(推送失败, resp.json())get_access_token要加缓存微信接口每日有配额频繁刷新会限流。订阅消息的data字段里thing类型限制 20 个字符以内超过会被拒绝所以告警 message 不能太长我一般把设备名称截断到 10 个字再拼接报警内容。4.3 小程序端表单和抓包自检用Charles确认请求体/响应体远程抄表在小程序端一个重要功能是“人工补抄”现场表计离线时运维人员用小程序表单手动录入表底码。这个功能看似简单但很容易因为参数名不对导致后台拒收。我建议开发阶段用代理工具做抓包自检这里说的是本地调试常用的Charles把微信开发者工具代理到 8888 端口能清楚看到wx.request发出的请求头、请求体、响应体。// pages/meter-reading/meter-reading.js submitMeterReading() { const { deviceCode, meterValue, readerName } this.data; if (!deviceCode || isNaN(Number(meterValue))) { wx.showToast({ title: 请输入有效表底数, icon: none }); return; } wx.request({ url: ${app.globalData.baseUrl}/api/v1/meter/reading, method: POST, data: { deviceCode, meterValue: Number(meterValue), // 后端要求数字不能是字符串 readerName, readingTime: this.formTime() // ISO格式时间 }, header: { X-Token: wx.getStorageSync(token) }, success: (res) { // 后端返回 { code: 0, data: { readingId } } if (res.data.code 0) { wx.showToast({ title: 抄表成功, icon: success }); } else { wx.showToast({ title: res.data.msg || 提交失败, icon: none }); } }, fail: () { // 网络异常时把表单暂存到本地缓存下轮重试 this.saveToLocalCache(); } }); }这里有个细节meterValue: Number(meterValue)把表单字符串转成数字因为后端如果用了 Long 类型字符串会被 Jackson 反序列化成字符串导致类型不匹配。readingTime也要注意时区建议统一用YYYY-MM-DD HH:mm:ss后端按 Asia/Shanghai 解析。抓包时的常见现象是小程序里请求能通但通过 Charles 看不到。原因通常是微信开发者工具没有勾选“不校验合法域名”以及代理设置未同步。在调试阶段可以临时关闭合法域名校验但上线前必须在小程序管理后台把 HTTPS 域名配置好否则真机直接报fail url not in domain list。5. 避坑记负荷对不上、推送丢失、解析错位5个高频现场问题电力智能管理项目和其他小程序项目有很大差别它依赖硬件采集链路而链路越长问题越隐蔽。下面几条都是我在类似项目里反复遇到过的按“现象 → 原因 → 解决”的方式写算是血泪经验能帮你少走弯路。5.1 现象负荷曲线出现规律性“断崖”每天整点掉零有一段时间服务器画出来的负荷曲线每到整点就掉到 0持续五分钟又恢复。开始以为是电表故障跑到现场看电表显示正常再查数据库发现整点附近的记录active_power为 0而且只发生在全部表计上。最后定位到采集网关固件里有个“整点冻结”任务网关在整点时执行冻结操作串口被占用采集线程读上来的寄存器数据不完整程序又把不完整报文强转成 0 并写入库。解决方法是采集服务增加校验当连续 3 个采集周期读到完全相同的 0 值且与前一天同时间值差异巨大时标记为“脏数据”而不是直接入库。数据质量规则要提前设计否则后面分析全被脏数据带偏。5.2 现象预警推送在测试环境正常正式环境收不到小程序真机上收不到订阅消息但后端日志显示消息发送成功。查微信返回码显示 0说明消息已经投递到微信服务器问题在用户侧用户在某个页面点了订阅授权但订阅消息要求“一次性订阅”只能推送一条如果用户已经订阅过一次第二次推送就被自动忽略。解决方式是引导用户重新订阅或者在每次推送前检查wx.getSetting里的订阅关系。另一个容易忽略的是page字段指向的页面必须在后台配置为正式版本路径否则通知点击时跳转失败。我在这个坑上栽过两次现在把订阅关系存数据库每次推送前先判断该用户剩余订阅次数不够就转为短信通知。5.3 现象电表读出来的电压是 229.9V数据显示 2299V多出十倍这是 Modbus 寄存器解析最典型的翻车现场。厂家寄存器表里写的是“电压0x0000-0x0001单位0.1V”但你的解析函数把两个寄存器按 IEEE754 浮点解析结果不是 229.9 而是 229.9 的十倍百倍或者是个无法理解的数字。解决方法是先看协议文档确认数据类型和缩放系数。常见的定点数模式是高 16 位存整数部分低 16 位存小数部分需要(reg_high * 65536 reg_low) / 100。我建议建立一个“寄存器映射”表每个量都有data_typeint16/uint16/float/bcd和scale0.1/0.01/1解析时统一查表不要在每个表型里硬编码。还有一个极易忽略的点电表把三个相位的电压作为连续寄存器排序可能是 A/B/C也可能是 A/C/B最好打印原始寄存器数组和电表液晶屏对一遍。5.4 现象微信开发者工具模拟器正常真机加载小程序白屏或接口超时这类问题常见于开发环境用http://localhost或局域网点表接口真机上无法访问。微信小程序真机要求所有请求域名必须是 HTTPS 且在后台配置了合法域名开发工具里可以勾选“不校验合法域名”但真机不行。解决方法是统一走线上 HTTPS 网关内网电表数据由云端采集器中转。另外小程序的包体积限制是 2MB如果工程里塞了图表库加整套页面很容易超限。这时用微信官方分包加载把仪表盘、设备管理、抄表页拆到不同分包主包只留首页和公共组件。我在项目里就是用这种“先上线主包再按需加载分包”的方式把首包控在 1.6MB。5.5 现象用电行为聚类结果每周都变报告没法跟用户解释KMeans 每次运行时初始点不同聚类结果会有细微差别。有的周把“高耗能用户”分出来 8 个下周又变成 9 个你以为用户用量变了其实只是随机种子变了。解决方式是把模型训练和预测分开每天定时训练后保存模型用户行为分析统一走载入模型做预测不再每天重新聚类。还要固定random_state并保存聚类中心这样只要数据分布不发生明显变化结论就是可复现的。如果你发现加了温度特征后结果反而更不稳定说明特征里的缺失值太多不如先把缺失率超过 30% 的特征丢弃宁缺毋滥。6. 最后的验证技巧用mock电表数据在本地把整条流程跑通项目到了交付阶段最大的风险不是轮子不会写而是现场没有任何真实电表可以联调。我一般会在本地先搭一套 mock 电表按固定周期推数据把采集 → 入库 → 分析 → 预警 → 小程序展示全链路验证一遍这样到现场只是换数据源不会手忙脚乱。6.1 用一个mock脚本生成一天的负荷数据验证全链路import time import random import json from paho.mqtt import publish device_code MOCK_DEVICE_001 base_power 30.0 # 夜间基础负荷 for i in range(60 * 30): # 30分钟每2秒一条模拟1天?这里改成循环1440次更干净 hour (i // 120) % 24 if 8 hour 18: power base_power random.uniform(40, 80) # 白天高峰 else: power base_power random.uniform(0, 5) payload { deviceCode: device_code, ts: time.strftime(%Y-%m-%d %H:%M:%S), activePower: round(power, 3), voltage: round(random.uniform(220, 235), 1), current: round(power / 220, 2) } publish.single(meter/data, json.dumps(payload), hostnamelocalhost, port1883) time.sleep(1)验证步骤很直观打开采集服务日志确认 MQTT 消息被接收查数据库load_data_202503表确认每 2 秒新增一条打开小程序仪表盘看曲线是否随时间增长故意把功率设置成超高值确认预警规则触发。如果哪一步断了顺着链路逐段排查比现场搬电表快得多。mock 脚本里的random.uniform是模拟真实波动的通用做法但要注意方差不要太大否则负荷分析算法会认为系统不稳定。6.2 四步验收清单从数据到预警的完整性检查我会在项目交付前拿一份真实的历史用电负荷记录替换 mock 数据源跑通四个验收点第一分钟级实时数据连续采集 24 小时缺失率低于 0.5%第二日负荷曲线与现场电表液晶屏读数误差不超过 3%第三人为设置故障阈值预警消息在 5 分钟内推送到测试微信第四按周生成用户用电行为报告类别分布与上一周保持稳定。这四个点都通过再让用户拿真实设备试运行一周。这套方案做到后面你会发现自己最值钱的东西不是小程序页面而是那套能适应多种电表协议的数据链路和预警规则。以后接新表型只要在协议配置里加一条映射就能复用到下一批项目。希望这些方法能帮你在电力监控这条路上少踩几个坑也少加几天班。本文还有配套的精品资源点击获取 电力监控小程序开发实践：从电表采集、负荷分析到预警与抄表
简介这是一套面向电力行业的智能管理小程序源码涵盖电力数据监控、负荷分析、故障预警、远程抄表、能耗统计、智能电表集成、设备管理、数据可视化、用户行为分析与需求预测等功能模块适合电力企业技术人员、小程序开发者及高校学生参考学习。压缩包共2000个文件主要为js逻辑、json配置、wxml页面、wxss样式辅以md与ts说明文件包体仅1.27MB便于导入与修改。已有107人下载学习适合作为电力行业智能化改造或毕业设计的项目蓝本。资源提供完整项目代码涵盖功能页面、数据交互逻辑、实时图表展示及用户行为分析等实现并附赠DOCX说明文件便于理解模块间协同逻辑可直接用于二次开发或作为课程设计与毕业设计参考。1. 电力智能管理小程序从电表到面板一条链路解决四类现场问题你管着一个园区、一栋写字楼或者一条生产线的用电最头疼的往往不是电费贵而是“不知道电去哪了、设备什么时候出问题”。这个标题里的电力行业智能管理小程序就是把传统电力监控从“机房上位机”搬到手机微信里智能电表负责采数小程序负责展示、报警和抄表后端负责负荷分析、预测和节能建议。它适合物业电工、小型工厂能源管理员、充电桩和光伏运维人员也适合售电公司给客户做用电行为报告。反直觉的一点是这类项目最不该一上来就画界面而是先把电表协议、数据字段和告警规则定清楚否则后面每次换表型都是一次返工。2. 先把数据链路立住电表协议、数据表结构与小程序可视化选型做电力监控小程序常见做法是先定“数据从哪来”再谈界面。智能电表集成不是把电表接到插座上就行现场表计协议五花八门有的走 DL/T645有的走 Modbus-RTU还有不少厂家私有协议。如果一开始不抽象出一层统一采集接口后面换一个品牌电表抄数代码就得重写一遍。2.1 电表协议选型先分清DL/T645、Modbus和厂家私有协议国内公网电表最常见的是 DL/T645-2007 协议它和电能表国标绑定支持正向有功、反向有功、电压、电流、功率因数等数据项。工业现场则大量使用 Modbus-RTU通过寄存器地址读原始数值。两者差别很大维度DL/T645-2007Modbus-RTU数据标识4字节数据标识长度寄存器地址功能码典型读法请求-应答含校验和读保持寄存器 0x03小数位协议定义单位在数据项描述里由厂家寄存器表决定批量采集一次读一项循环较多一次可读连续多路寄存器兼容性国网/南网通用工业表、光伏逆变器、采集器通用我一般建议优先选支持 DL/T645 且兼容 Modbus 的表计两个口都留出来。采集器通过 RS485 总线把多块电表接到一台边缘网关网关再通过 MQTT 把数据推到云服务器。小项目也可以省略网关直接用带网口的电能表走 Modbus-TCP 或 DL/T645 over TCP但超过 30 块表时轮询会很慢。下面是读 Modbus 电能表电压、电流的 Python 示例依赖pymodbusfrom pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.1.50, port502, timeout3) if not client.connect(): raise RuntimeError(电表连接失败检查IP和端口) # 假设厂家寄存器表电压起始地址 0x0000电流 0x0002功率 0x0004 # 使用功能码 0x03 读连续 6 个寄存器每个量占 2 个寄存器32位float result client.read_holding_registers(0x0000, count6, unit1) if result.isError(): raise RuntimeError(寄存器读取失败请核对地址和从站号) values result.registers voltage_high values[0] voltage_low values[1] current_high values[2] current_low values[3] # 常见做法IEEE754 大端模式解析32位浮点 import struct voltage_bytes struct.pack(HH, voltage_high, voltage_low) voltage struct.unpack(f, voltage_bytes)[0] print(fA相电压: {voltage:.1f}V) client.close()这里有两个参数很容易踩坑unit1是 Modbus 从站号多块表并联时每块表要设不同站号count6表示连续读 6 个寄存器但实际每个电量参数可能占 2 个寄存器如果寄存器表里每个量只占 1 个寄存器你的解析长度就要改。还有字节序有的表厂用大端有的用小端甚至还有中端别急着写死先用厂家文档里的数值和自己读到的十六进制核对一遍。DL/T645 的解析逻辑和 Modbus 完全不同它的数据帧里带控制码、数据标识和校验和读法更像“发一条命令电表回一段长报文”。如果你现场既有 DL/T645 电表又有 Modbus 表最好在采集层做一个统一数据模型把电表地址、协议类型、寄存器起始位置、缩放系数都存到配置表里采集服务只负责输出标准化 JSON。这样到后面做实时数据可视化时小程序和后端根本不用关心底层协议差异。2.2 建设最小数据表用SQL定义负荷、电量和设备三张核心表采集服务把电表数据标准化成 JSON 后后端要落库。电力监控项目和普通管理系统的差别在于数据是高频时序数据不是单纯增删改查。最忌讳用一张大宽表把所有电表字段堆在一起那样查询“某块表昨天每小时的平均功率”会变得非常慢。我常用的库是 MySQL 存基础数据和告警事件用 TimescaleDB 或者 PostgreSQL 时序分区表存分钟级负荷数据。如果只是中小规模项目MySQL 也够用但要把分钟表按月分表。下面是三张核心表的建表 SQL-- 设备表每块电表、每个回路的基本信息 CREATE TABLE device ( id INT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) UNIQUE NOT NULL COMMENT 表计编号/资产编号, device_name VARCHAR(128) NOT NULL COMMENT 设备名称如1号厂房总柜, protocol_type VARCHAR(16) NOT NULL DEFAULT modbus COMMENT modbus/dlt645, slave_id INT NOT NULL DEFAULT 1 COMMENT Modbus从站号, register_base INT NOT NULL DEFAULT 0 COMMENT 起始寄存器地址, ct_ratio DECIMAL(10,3) NOT NULL DEFAULT 1 COMMENT 电流互感器变比, pt_ratio DECIMAL(10,3) NOT NULL DEFAULT 1 COMMENT 电压互感器变比, enabled TINYINT(1) NOT NULL DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 负荷数据表按月分表存储功率、电压、电流等实时指标 CREATE TABLE load_data_202501 ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) NOT NULL COMMENT 对应device.device_code, collect_time DATETIME NOT NULL COMMENT 采集时间统一用设备本地时间, active_power DECIMAL(12,3) NOT NULL COMMENT 有功功率(kW), reactive_power DECIMAL(12,3) DEFAULT 0 COMMENT 无功功率(kvar), voltage DECIMAL(8,2) DEFAULT 0 COMMENT 相电压(V), current DECIMAL(8,2) DEFAULT 0 COMMENT 相电流(A), power_factor DECIMAL(5,3) DEFAULT 0 COMMENT 功率因数, frequency DECIMAL(5,2) DEFAULT 50 COMMENT 频率(Hz), INDEX idx_device_time (device_code, collect_time) ); -- 电量表按天累积方便统计日电量、月电量 CREATE TABLE energy_daily ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_code VARCHAR(64) NOT NULL, stat_date DATE NOT NULL, active_energy_kwh DECIMAL(14,4) COMMENT 正向有功总电量(kWh), reverse_energy_kwh DECIMAL(14,4) COMMENT 反向有功电量(kWh), peak_power DECIMAL(12,3) COMMENT 当日最大需量(kW), valley_power DECIMAL(12,3) COMMENT 当日最小功率(kW), UNIQUE KEY uk_device_date (device_code, stat_date) );注意load_data_202501这种月表是为了控制单表行数一个中型园区一个月可能产生几百万条记录。如果用了 TimescaleDB 就不用按月建表按时间分区即可。另一个容易忽略的是ct_ratio和pt_ratio变比电表读到的电流是互感器二次侧电流需要乘变比才是真实值。比如 250A 电流互感器变比是 250/550实际电流 二次电流 × 50这个系数千万别在采集层和小程序端各做一次否则值会翻倍。电力数据监控里时间基准也必须统一。电表内部时钟往往会漂移我建议采集服务每次读到电表时间如果和服务器时间偏差超过 5 分钟就在采集侧用服务器时间覆盖记录时间而不是信任电表时间。省得后面做用电负荷分析时曲线高峰老是往左或往右偏移一段时间。2.3 实时数据可视化小程序端用ucharts还是原生canvas数据落库后下一步是让小程序把实时数据画出来。微信小程序本身不支持 DOM常见的图表组件是 echarts-for-weixin 和 uCharts。我在实际项目中更倾向 uCharts它体积小支持 H5、微信小程序、App而且渲染性能在低端安卓机上比 echarts 稳定。uCharts 的折线图、柱状图和仪表盘基本覆盖电力监控需求。下面是小程序端用 uCharts 绘制当日负荷曲线的核心代码以微信原生开发为例// pages/dashboard/dashboard.js const uCharts require(../../utils/u-charts.min.js); Page({ data: { chartData: null, deviceCode: DEV001 }, onLoad(options) { this.setData({ deviceCode: options.deviceCode || DEV001 }); this.loadTodayCurve(); }, loadTodayCurve() { wx.request({ url: https://your-api.com/api/v1/load/curve?deviceCode${this.data.deviceCode}date2025-03-18, method: GET, header: { X-Token: wx.getStorageSync(token) }, success: (res) { const series res.data.series; // [{time: 08:00, power: 125.6}, ...] const categories series.map(item item.time); const data series.map(item item.power); this.setData({ chartData: { categories: categories, series: [{ name: 有功功率(kW), data: data }] } }); this.renderChart(); } }); }, renderChart() { if (this.data.chartData) { this.chart new uCharts({ type: line, context: wx.createCanvasContext(loadCurveCanvas), categories: this.data.chartData.categories, series: this.data.chartData.series, animation: false, width: 750, height: 350, dataLabel: false, xAxis: { disableGrid: true, labelCount: 6 }, yAxis: { gridType: dash, min: 0 }, legend: { show: true, position: top } }); } } });这里的参数width: 750是按微信小程序的逻辑分辨率来的canvas 真实宽度是 750 除以wx.getSystemInfoSync().windowWidth做像素换算如果直接填 750 在视网膜屏上会模糊。进阶做法是用upx2px(750)换算或者从wx.createSelectorQuery()里拿到实际节点宽度再设置。animation: false是为了首屏渲染更快后续加载更多数据时也可以关闭动画。实时数据可视化不只是画一条曲线还要考虑页面下拉刷新、自动定时刷新和大屏/手机屏切换。如果需求是“实时”建议不要每秒请求一次接口用 15 秒定时轮询加 WebSocket 推送组合页面可见时轮询后台切入前台时立即刷新。否则几百块表同时轮询后端压力会很快打满。3. 用电负荷分析落到代码行为聚类、需求预测和节能建议怎么出数据链路通了接下来才是这个标题里最有价值的部分——用电负荷分析。很多团队把“负荷分析”做成了只是画个饼图实际上用户想看的是哪些设备在偷懒、哪些时间段能错峰、明天大概用电多少、节能建议从哪里下手。这部分不用一上来上深度学习先用可解释的统计和经典机器学习就够了。3.1 特征工程把原始电表读数变成可分析的负荷指标从分钟级负荷数据到用户行为特征中间需要做降采样和聚合。我一般先按小时求平均、按天算峰谷再派生下面几个指标日负荷率平均功率/最大功率、峰谷差率、峰功率-谷功率/峰功率、夜间最小功率判断是否有待机耗电、最大需量出现时间判断是上班尖峰还是晚上尖峰。这些特征才是用电行为分析的输入。下面是直接从 MySQL 小时表聚合日特征的计算脚本import pandas as pd import pymysql conn pymysql.connect(hostlocalhost, userenergy_user, passwordxxx, dbenergy_mgmt) # 读某块表一天的小时级平均功率 sql SELECT DATE_FORMAT(collect_time, %%Y-%%m-%%d %%H:00) AS hour_point, AVG(active_power) AS avg_power FROM load_data_202503 WHERE device_code DEV001 AND collect_time 2025-03-18 00:00:00 AND collect_time 2025-03-19 00:00:00 GROUP BY hour_point ORDER BY hour_point df pd.read_sql(sql, conn) df[hour] df[hour_point].str[-2:].astype(int) peak_power df[avg_power].max() valley_power df[avg_power].min() avg_power df[avg_power].mean() load_rate avg_power / peak_power if peak_power else 0 peak_valley_diff_rate (peak_power - valley_power) / peak_power if peak_power else 0 print(f当日最大需量: {peak_power:.2f} kW) print(f当日最小功率: {valley_power:.2f} kW) print(f负荷率: {load_rate:.2%}) print(f峰谷差率: {peak_valley_diff_rate:.2%}) conn.close()这里%%Y是因为用 pymysql 和 Python 字符串格式化SQL 里需要转义百分号直接写%Y会报错。另一个容易犯的问题是GROUP BY hour_point本身没问题但 MySQL 的DATE_FORMAT输出字符串排序依赖字符串字典序如果跨年就会出现 2025-01 排在 2024-12 前面的情况所以ORDER BY hour_point看起来对实际上按字符串排也符合时间顺序前提是格式统一用%Y-%m-%d %H:00。负荷率低说明设备容量有明显的冗余或者用电集中在很短时间。峰谷差率高的用户适合做削峰填谷和需求响应引导。这些指标不能只算一天要向前滚动 30 天取趋势才能在电力需求预测里发挥价值。3.2 用电行为聚类用KMeans识别高耗能、峰谷型和异常用户有了日特征表行为分析最常用的就是聚类。典型的三类结果一是“办公型”白天高、晚上低负荷率中等二是“连续生产型”全天平稳负荷率高三是“冲击型”短时高功率负荷率很低。用 KMeans 在二维特征负荷率、峰谷差率上就能分开。下面是完整聚类代码包括归一化和图标注释from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler import numpy as np # 假设 features 是 DataFrame每行是一个用户一天的特征 # 列user_id, load_rate, peak_valley_diff_rate features pd.read_sql(SELECT device_code AS user_id, load_rate, peak_valley_diff_rate FROM user_daily_features WHERE stat_date2025-03-18, conn) X features[[load_rate, peak_valley_diff_rate]].values # 归一化两个指标量纲不同load_rate 是0-1peak_valley_diff_rate 也是0-1 # 但分布差异大标准化后聚类更稳定 X_scaled StandardScaler().fit_transform(X) # 用轮廓系数试出 k3 通常比较稳定 model KMeans(n_clusters3, random_state42, initk-means, n_init10) labels model.fit_predict(X_scaled) features[cluster] labels # 输出每类中心反归一化后对应真实负荷率/峰谷差率中心 centers model.cluster_centers_ print(聚类中心(标准化后):, centers) # 业务含义解释load_rate 高 峰谷差低 - 连续生产型 for c in range(3): subset features[features[cluster] c] avg_lr subset[load_rate].mean() avg_pv subset[peak_valley_diff_rate].mean() print(f第{c1}类: 用户数{len(subset)}, 平均负荷率{avg_lr:.2f}, 平均峰谷差率{avg_pv:.2f})n_init10是 KMeans 的常用参数表示跑 10 次取最优避免初始化点差导致结果不稳定。random_state42是为了结果可复现。这里最大的坑是“聚类结果漂移”今天跑出来 3 类明天数据更新可能变成 2 类或 4 类。解决办法是固定 K 值并且把聚类中心存下来作为下一批用户的初始中心而不是每次都重新随机。异常用户识别不一定要聚类更实用的是基于阈值的事件触发。比如某个设备夜间最小功率超过 10kW基本可以判断有空载耗电功率因数低于 0.5 并且持续 15 分钟大概率有设备无功补偿失效。这类规则要放到预警系统里而不是等日报告出来才告诉用户。3.3 电力需求预测与节能建议用线性回归做一个可解释的基线电力需求预测在这个项目里主要用来做两件事一是给用户“明天最大需量”预警避免超需量罚款二是给节能优化建一个基线得出“如果没有优化你会用多少电”。我一般从简单的多因子线性回归开始用昨日同时段负荷、当天温度、星期几作为特征。温度数据可以接天气 API也可以直接用负荷自回归。下面是一个 24 小时逐小时负荷预测的最小 Python 示例import pandas as pd from sklearn.linear_model import LinearRegression from sklearn.model_selection import train_test_split # 读取过去 30 天的逐时负荷和温度 df pd.read_sql( SELECT collect_time, active_power, temperature FROM load_hourly_history WHERE device_codeDEV001 AND collect_time NOW() - INTERVAL 30 DAY , conn) df[hour] df[collect_time].dt.hour df[weekday] df[collect_time].dt.weekday # 构造自回归特征前一天同一时刻的功率 df[prev_day_power] df.groupby(hour)[active_power].shift(24) # 去掉缺失值再训练 df_model df.dropna(subset[prev_day_power, temperature]) features df_model[[hour, weekday, prev_day_power, temperature]] target df_model[active_power] X_train, X_test, y_train, y_test train_test_split(features, target, test_size0.2, shuffleFalse) model LinearRegression() model.fit(X_train, y_train) import joblib joblib.dump(model, ../../models/daily_load_model.pkl) print(f训练完成测试R2: {model.score(X_test, y_test):.3f})shift(24)是关键它取同小时前一天的历史负荷模型核心就是“今天某时的负荷和昨天同时段强相关”。shuffleFalse很重要时间序列切分不能打乱顺序否则会泄露未来信息导致 R2 虚高。温度特征可选如果不想接天气 API可以先不加用前天、昨天和一周前同一时刻的负荷做三变量自回归准确率也很可观。预测得到负荷曲线后节能优化建议就能落地。比如预测明天 14:00-16:00 将出现高峰提醒用户提前把储能放电夜间最小功率持续偏高建议排查待机设备功率因数低建议加无功补偿。这些都是从特征和预测结果直接推导出来的不需要黑匣子模型用户也更容易信服。4. 故障预警与远程抄表规则引擎、推送通道和小程序端表单前面讲了监控和分析这章解决两个业务动作设备坏了怎么办、电表怎么远程抄。故障预警系统不是越复杂越好真正在现场稳定运行的往往是几十条写死的规则而不是训练出来的异常检测模型。远程抄表则要处理好“抄表任务、冻结数据、缴费对账”三者关系再考虑小程序端录入和展示。4.1 预警规则引擎阈值、梯度、缺相和反向电量故障预警落地第一件事是把告警规则拆成四类越限、变化率、组合逻辑、电量异常。越限最简单比如电压超过 110% 或低于 85%变化率规则能捕捉“10 分钟内负荷从 30kW 跳到 120kW”这通常是启动电流冲击或设备故障组合逻辑比如“功率因数低于 0.5 且持续超过 15 分钟”才触发避免单点误报。下面是一个用 Python 写的最小规则引擎# rules/alert_engine.py class AlertEngine: def __init__(self, rules): self.rules rules # 规则列表每条是dict def evaluate(self, device_code, metric, value, ts): alerts [] for rule in self.rules: if metric ! rule[metric]: continue op rule[operator] threshold rule[threshold] # 越限类规则支持 , , , if op and value threshold: alerts.append(self._build_alert(rule, value, ts)) elif op and value threshold: alerts.append(self._build_alert(rule, value, ts)) # 梯度规则值相比上一个时间点的变化量 elif op delta_gt: prev_val rule.get(last_value, 0) if abs(value - prev_val) threshold: alerts.append(self._build_alert(rule, value, ts)) rule[last_value] value return alerts def _build_alert(self, rule, value, ts): return { device_code: rule.get(device_code, ANY), metric: rule[metric], level: rule.get(level, warning), # info/warning/critical message: f{rule[label]} 当前值 {value}阈值 {rule[threshold]}, ts: ts }这段代码的核心是operator抽象后面增加新类型只要扩展evaluate的分支。实际部署时我不建议自己写状态管理把预警阈值放到数据库表里避免改代码才能调参数。梯度规则里last_value如果存内存服务重启后就失灵所以要用 Redis 存上一时刻值或者改成连续 3 个采集周期都超阈值才触发这样更稳定。告警发送通道可以接微信订阅消息、短信和邮件。现场运维人员最喜欢的是微信订阅消息但订阅消息要求用户主动订阅且模板有次数限制所以重要告警还是得短信兜底。推送服务最好做成独立模块用 MQTT 或 Redis 队列解耦别把规则引擎放在采集线程里。4.2 远程抄表任务与推送从定时任务到微信订阅消息远程抄表听起来简单实际有一个坑不是每时每刻都在抄表而是按结算周期冻结数据。比如每天 0 点冻结正向有功总电量这个值是一天最后一条累计电量不能把当天每分钟电量加起来因为电表内部可能已经翻转清零。所以远程抄表要分两块实时采集用于监控定时冻结用于账务。我用 Python APScheduler 实现每天 0 点 5 分的抄表任务from apscheduler.schedulers.blocking import BlockingScheduler from collection.gateway import read_total_energy def daily_meter_reading_job(): device_list get_enabled_devices() for dev in device_list: # 读电表累计正向电量注意单位是kWh energy read_total_energy(dev) # 读电表当前时间防止电表时钟漂移影响冻结时间 meter_time read_meter_time(dev) save_daily_reading(dev[device_code], energy, meter_time) # 如果电量相比昨天的冻结值突然减少说明电表翻转或换表 yesterday get_yesterday_reading(dev[device_code]) if yesterday and energy 1 yesterday - 0.01: send_alert(dev[device_code], meter_rollback, f可能换表或清零:昨天{yesterday},今天{energy}) scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(daily_meter_reading_job, cron, hour0, minute5) scheduler.start()这里时间表达式hour0, minute5是每天零点零五分执行错开零点整点其他任务的高峰。energy 1 yesterday - 0.01这个判断允许 1kWh 的误差避免误差导致误报。如果电表支持冻结数据尽量读取电表自身的日冻结记录而不是每天去算差值因为很多电表断电时不会留存分钟数据。推送消息到微信小程序端典型流程是后端调微信订阅消息接口import requests def send_wechat_subscribe(openid, template_id, data_dict): url https://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token get_access_token() payload { touser: openid, template_id: template_id, page: pages/alert/alert, data: { thing1: {value: data_dict[device_name]}, number2: {value: data_dict[power]}, thing3: {value: data_dict[message]} } } resp requests.post(url, jsonpayload, timeout3) # 常见错误码43101 表示用户未订阅41030 表示模板ID错误 if resp.json().get(errcode) ! 0: print(推送失败, resp.json())get_access_token要加缓存微信接口每日有配额频繁刷新会限流。订阅消息的data字段里thing类型限制 20 个字符以内超过会被拒绝所以告警 message 不能太长我一般把设备名称截断到 10 个字再拼接报警内容。4.3 小程序端表单和抓包自检用Charles确认请求体/响应体远程抄表在小程序端一个重要功能是“人工补抄”现场表计离线时运维人员用小程序表单手动录入表底码。这个功能看似简单但很容易因为参数名不对导致后台拒收。我建议开发阶段用代理工具做抓包自检这里说的是本地调试常用的Charles把微信开发者工具代理到 8888 端口能清楚看到wx.request发出的请求头、请求体、响应体。// pages/meter-reading/meter-reading.js submitMeterReading() { const { deviceCode, meterValue, readerName } this.data; if (!deviceCode || isNaN(Number(meterValue))) { wx.showToast({ title: 请输入有效表底数, icon: none }); return; } wx.request({ url: ${app.globalData.baseUrl}/api/v1/meter/reading, method: POST, data: { deviceCode, meterValue: Number(meterValue), // 后端要求数字不能是字符串 readerName, readingTime: this.formTime() // ISO格式时间 }, header: { X-Token: wx.getStorageSync(token) }, success: (res) { // 后端返回 { code: 0, data: { readingId } } if (res.data.code 0) { wx.showToast({ title: 抄表成功, icon: success }); } else { wx.showToast({ title: res.data.msg || 提交失败, icon: none }); } }, fail: () { // 网络异常时把表单暂存到本地缓存下轮重试 this.saveToLocalCache(); } }); }这里有个细节meterValue: Number(meterValue)把表单字符串转成数字因为后端如果用了 Long 类型字符串会被 Jackson 反序列化成字符串导致类型不匹配。readingTime也要注意时区建议统一用YYYY-MM-DD HH:mm:ss后端按 Asia/Shanghai 解析。抓包时的常见现象是小程序里请求能通但通过 Charles 看不到。原因通常是微信开发者工具没有勾选“不校验合法域名”以及代理设置未同步。在调试阶段可以临时关闭合法域名校验但上线前必须在小程序管理后台把 HTTPS 域名配置好否则真机直接报fail url not in domain list。5. 避坑记负荷对不上、推送丢失、解析错位5个高频现场问题电力智能管理项目和其他小程序项目有很大差别它依赖硬件采集链路而链路越长问题越隐蔽。下面几条都是我在类似项目里反复遇到过的按“现象 → 原因 → 解决”的方式写算是血泪经验能帮你少走弯路。5.1 现象负荷曲线出现规律性“断崖”每天整点掉零有一段时间服务器画出来的负荷曲线每到整点就掉到 0持续五分钟又恢复。开始以为是电表故障跑到现场看电表显示正常再查数据库发现整点附近的记录active_power为 0而且只发生在全部表计上。最后定位到采集网关固件里有个“整点冻结”任务网关在整点时执行冻结操作串口被占用采集线程读上来的寄存器数据不完整程序又把不完整报文强转成 0 并写入库。解决方法是采集服务增加校验当连续 3 个采集周期读到完全相同的 0 值且与前一天同时间值差异巨大时标记为“脏数据”而不是直接入库。数据质量规则要提前设计否则后面分析全被脏数据带偏。5.2 现象预警推送在测试环境正常正式环境收不到小程序真机上收不到订阅消息但后端日志显示消息发送成功。查微信返回码显示 0说明消息已经投递到微信服务器问题在用户侧用户在某个页面点了订阅授权但订阅消息要求“一次性订阅”只能推送一条如果用户已经订阅过一次第二次推送就被自动忽略。解决方式是引导用户重新订阅或者在每次推送前检查wx.getSetting里的订阅关系。另一个容易忽略的是page字段指向的页面必须在后台配置为正式版本路径否则通知点击时跳转失败。我在这个坑上栽过两次现在把订阅关系存数据库每次推送前先判断该用户剩余订阅次数不够就转为短信通知。5.3 现象电表读出来的电压是 229.9V数据显示 2299V多出十倍这是 Modbus 寄存器解析最典型的翻车现场。厂家寄存器表里写的是“电压0x0000-0x0001单位0.1V”但你的解析函数把两个寄存器按 IEEE754 浮点解析结果不是 229.9 而是 229.9 的十倍百倍或者是个无法理解的数字。解决方法是先看协议文档确认数据类型和缩放系数。常见的定点数模式是高 16 位存整数部分低 16 位存小数部分需要(reg_high * 65536 reg_low) / 100。我建议建立一个“寄存器映射”表每个量都有data_typeint16/uint16/float/bcd和scale0.1/0.01/1解析时统一查表不要在每个表型里硬编码。还有一个极易忽略的点电表把三个相位的电压作为连续寄存器排序可能是 A/B/C也可能是 A/C/B最好打印原始寄存器数组和电表液晶屏对一遍。5.4 现象微信开发者工具模拟器正常真机加载小程序白屏或接口超时这类问题常见于开发环境用http://localhost或局域网点表接口真机上无法访问。微信小程序真机要求所有请求域名必须是 HTTPS 且在后台配置了合法域名开发工具里可以勾选“不校验合法域名”但真机不行。解决方法是统一走线上 HTTPS 网关内网电表数据由云端采集器中转。另外小程序的包体积限制是 2MB如果工程里塞了图表库加整套页面很容易超限。这时用微信官方分包加载把仪表盘、设备管理、抄表页拆到不同分包主包只留首页和公共组件。我在项目里就是用这种“先上线主包再按需加载分包”的方式把首包控在 1.6MB。5.5 现象用电行为聚类结果每周都变报告没法跟用户解释KMeans 每次运行时初始点不同聚类结果会有细微差别。有的周把“高耗能用户”分出来 8 个下周又变成 9 个你以为用户用量变了其实只是随机种子变了。解决方式是把模型训练和预测分开每天定时训练后保存模型用户行为分析统一走载入模型做预测不再每天重新聚类。还要固定random_state并保存聚类中心这样只要数据分布不发生明显变化结论就是可复现的。如果你发现加了温度特征后结果反而更不稳定说明特征里的缺失值太多不如先把缺失率超过 30% 的特征丢弃宁缺毋滥。6. 最后的验证技巧用mock电表数据在本地把整条流程跑通项目到了交付阶段最大的风险不是轮子不会写而是现场没有任何真实电表可以联调。我一般会在本地先搭一套 mock 电表按固定周期推数据把采集 → 入库 → 分析 → 预警 → 小程序展示全链路验证一遍这样到现场只是换数据源不会手忙脚乱。6.1 用一个mock脚本生成一天的负荷数据验证全链路import time import random import json from paho.mqtt import publish device_code MOCK_DEVICE_001 base_power 30.0 # 夜间基础负荷 for i in range(60 * 30): # 30分钟每2秒一条模拟1天?这里改成循环1440次更干净 hour (i // 120) % 24 if 8 hour 18: power base_power random.uniform(40, 80) # 白天高峰 else: power base_power random.uniform(0, 5) payload { deviceCode: device_code, ts: time.strftime(%Y-%m-%d %H:%M:%S), activePower: round(power, 3), voltage: round(random.uniform(220, 235), 1), current: round(power / 220, 2) } publish.single(meter/data, json.dumps(payload), hostnamelocalhost, port1883) time.sleep(1)验证步骤很直观打开采集服务日志确认 MQTT 消息被接收查数据库load_data_202503表确认每 2 秒新增一条打开小程序仪表盘看曲线是否随时间增长故意把功率设置成超高值确认预警规则触发。如果哪一步断了顺着链路逐段排查比现场搬电表快得多。mock 脚本里的random.uniform是模拟真实波动的通用做法但要注意方差不要太大否则负荷分析算法会认为系统不稳定。6.2 四步验收清单从数据到预警的完整性检查我会在项目交付前拿一份真实的历史用电负荷记录替换 mock 数据源跑通四个验收点第一分钟级实时数据连续采集 24 小时缺失率低于 0.5%第二日负荷曲线与现场电表液晶屏读数误差不超过 3%第三人为设置故障阈值预警消息在 5 分钟内推送到测试微信第四按周生成用户用电行为报告类别分布与上一周保持稳定。这四个点都通过再让用户拿真实设备试运行一周。这套方案做到后面你会发现自己最值钱的东西不是小程序页面而是那套能适应多种电表协议的数据链路和预警规则。以后接新表型只要在协议配置里加一条映射就能复用到下一批项目。希望这些方法能帮你在电力监控这条路上少踩几个坑也少加几天班。本文还有配套的精品资源点击获取