简介面向电力行业的小程序完整工程源码整合电力数据监控、用电负荷分析、故障预警、远程抄表、能源消耗统计、智能电表集成、设备管理、实时可视化、用户行为分析、需求预测与节能优化等业务模块适合电力信息化开发、物联网应用开发及能源管理相关学习者参考研究。资源共2000个文件以js逻辑、json配置、wxml页面结构、wxss样式为主辅以md说明文档与ts脚本覆盖从界面到数据交互的完整小程序项目压缩包仅1.27MB目录清晰便于查阅。已有107人浏览学习附赠docx说明文档及日期选择、滑块、选项卡等通用组件代码可帮助读者理解小程序分层架构与接口封装方式并在此基础上快速扩展静态数据展示、设备状态监控等自定义功能。整体设计体现了从数据采集、分析、预警到优化的完整闭环对建设电力智能管理平台具有较好的工程参考价值。1. 电力行业智能管理小程序把电企数字化的发力点放到一线手里电力行业智能管理小程序这个方向这几年在园区配电、售电公司和县级供电所里被反复提起不是因为它名字好听而是电企数字化推进到“最后一公里”时大家发现真正难的不是把大屏看板做得炫而是让一线电工老师傅愿意在值班室掏出手机完成抄表、查负荷、收预警这件事。把电力数据监控、用电负荷分析、故障预警、远程抄表、能源消耗统计以及智能电表集成全部收进一个小程序等于把传统SCADA系统的核心能力搬进了微信生态。适合谁一是管着十几个配电房的园区物业二是需要低成本触达多站点人员的售电和运维团队。下文直接从采集、可视化、预警、避坑、预测这条主线把可复现的路径讲透。2. 智能电表集成与数据采集先把计量数据这条命脉打通2.1 三条主流的电表接入方式与选型边界在做电力数据监控小程序之前先要解决一个现实问题数据从哪来。市面上存量电表大致分成三类——走DL/T645规约的国网系计量表走Modbus-RTU协议的配电综测表以及新装的带边缘计算能力的智能网关。这三种设备的接入方式完全不同选型错了后面全是补丁。第一类是DL/T645直连。这种表在电网侧计量点数量巨大通信物理层多为RS485组网方式是“采集器或集中器加主站”。如果小程序后端要直接做主站常见做法是加一个RS485转以太网模块用串口服务器把所有电表的485总线统一接到内网主机上由后端服务定时轮询。优点是规约统一、计量数据有法律效力缺点是轮询周期受485总线带宽限制站点一多就得分层采样。第二类是Modbus-RTU。多功能电能表和配电综测表基本都支持这个协议寄存器里能直接读到U、I、P、Q、PF等实时电气量。相比DL/T645Modbus更适合做负荷分析因为拿到的特征量更全采集频率也更高。很多项目把这类表挂在DTU或边缘网关下网关定时采集后上抛到MQTT。第三类是智能网关加MQTT这是我最推荐的新建站点方案。网关本身具备协议解析能力支持DL/T645和Modbus采集频率可以到秒级还能断点续传。后端只需要订阅MQTT主题或者通过网关的REST接口拉数据省掉大量底层报文解析工作。选型经验我总结成一句话老计量点向DL/T645方向兼容新建配电房优先Modbus加网关分布范围广、网络不稳的站点必须上MQTT边缘缓存。三类设备并存时尽量不要在下层做重复协议转换统一在网关侧转成JSON再上行。提示真正影响项目进度的不是“用哪种协议”而是“表计是否支持校时”。拿到现场设备清单后第一件事先确认每台表的时间精度否则后面对齐统计数据会非常痛苦。2.2 用DL/T645报文解析把十六进制指令变成可用数值如果站点里还留着不少DL/T645老表后端得有解析能力。DL/T645-2007的帧结构不复杂0x68开头6字节表地址加控制字和长度字节数据域带数据标识和数值结尾是校验和加0x16。写一个最小解析器不难难在BCD码反转和标识对照。import binascii def dl645_byte_to_bcd(raw: int) - int: DL/T645中每个字节高低四位各表示一个十进制位且低位在前 low raw 0x0F # 低四位是实际值的低位 high (raw 4) 0x0F # 高四位是实际值的高位 return low * 10 high def parse_dlt645_value(data_bytes: bytes) - float: 将数据域中的电能值字节还原为真实电量分辨率通常为0.01kWh value_str for b in data_bytes: value_str f{dl645_byte_to_bcd(b):02d} return int(value_str) / 100.0 # 示意某次读取返回的正向有功电能数据域为 4 个字节 raw_data bytes([0x12, 0x34, 0x56, 0x78]) kwh parse_dlt645_value(raw_data) print(f正向有功电能: {kwh:.2f} kWh)这段代码刻意省去了帧头切割和校验重点说明BCD码处理。DL/T645里一个字节拆成高低两个BCD位存储顺序和显示顺序相反如果直接按大端转十六进制读出来的数字完全对不上。工程里还要根据数据标识分段解析区分正向有功、反向有功、A/B/C三相电压每种标识对应的字节长度不一样解析器要和电表厂家协议表同步维护。解析完的数据要落库。常见做法是建一张energy_snapshot表记录表计地址、采集时间、正向有功电能、反向有功电能、瞬时功率以表计地址加采集时间为唯一键。这里有个建议不管从电表取回来的是累计值还是增量值落库时统一存累计电能值后续统计用窗口函数算增量回溯和补数都方便。2.3 能源消耗统计的数据对齐为什么不能直接对电量求和很多团队在能源消耗统计上翻车不是SQL写错而是没搞懂电量的两种存在形式。第一种是累计值表计从装表起不断累加第二种是增量值即本次读数减上次读数。如果现场两种表同时存在统计页直接把电量加起来结果会偏到离谱。我的做法是在能源统计服务里先做一次归一化每条记录只存累计电能外加一个增量字段通过窗口函数计算出来。查询时用SQL窗口函数:-- 按电表和时间排序用LAG取上一采集点的累计电能算出本次增量 SELECT meter_id, read_time, cumulative_energy, cumulative_energy - LAG(cumulative_energy) OVER ( PARTITION BY meter_id ORDER BY read_time ) AS incremental_energy FROM energy_snapshot WHERE read_time 2025-01-01 00:00:00 AND read_time 2025-01-02 00:00:00;这样能源消耗统计只需在SQL层统一算“当日增量”或“15分钟增量”不依赖底层表计类型。但还有一个口径问题现场多功能表常常把一天分成尖、峰、平、谷四个费率表计会自动把电量分摊到费率时段。做分时统计时不要用页面时间范围去硬切表计读数而要看表计本身配置的费率时段表。我的血泪教训是曾有一套系统没同步时段配置导致峰段电量永远算不准最后是逐台表抄费率表才修正过来。3. 实时数据可视化与用电负荷分析从原始示数到运营看板3.1 负荷曲线聚合的窗口与统计口径电力数据的利用率取决于有没有把原始采集值转成业务看得懂的统计口径。电表上传的瞬时功率和电压电流是元数据而运营侧要看的负荷曲线通常是15分钟冻结值。这个15分钟窗口不是拍脑袋定的电网统计和需量计费基本都按15分钟冻结保持这个窗口能和前端表计冻结数据天然对齐。在数据库聚合时我的做法是把时间戳对齐到分钟网格。以PostgreSQL为例用date_bin函数操作直接-- 把秒级采集数据聚合成15分钟负荷序列 SELECT meter_id, date_bin(15 minutes, read_time) AS window_start, AVG(active_power) AS avg_power_kw, MAX(active_power) AS max_power_kw, SUM(active_power * 15 / 60) / 1000.0 AS energy_kwh FROM energy_snapshot GROUP BY meter_id, date_bin(15 minutes, read_time) ORDER BY window_start;注意这里的电量估算是平均功率乘窗口时长。严格意义上的电量应该来自表计电能寄存器差值不是功率积分所以如果涉及电费结算精度不要用这个SQL算电量它只适合看趋势和负载率形态。聚合窗口定了之后还要定义“天”的边界。配电房的日统计通常以零点为界但有些园区为了对账方便会把日起始设为早上6点这样负荷低谷段在凌晨统计曲线更平滑。这类业务偏好必须做成参数配置不要在代码里硬编码。3.2 小程序端实时看板用WebSocket推送替代定时轮询聚合后的数据要显示在微信小程序里。最容易被新手忽视的坑是前端每5秒去轮询一次HTTP接口看起来简单多个用户同时开着页面后端连接池很快被打爆。正确的做法是WebSocket推送或者小程序端做长连接订阅。如果你用uni-app开发同时要兼顾微信小程序和H5可以把WebSocket封装成一个可复用的连接管理器// 实时数据通道断线重连、心跳保活、订阅分发一次封装 class RealtimeDataChannel { constructor({ url, onMessage, onStatusChange }) { this.url url this.onMessage onMessage this.onStatusChange onStatusChange this.reconnectTimes 0 this.timer null this._connect() } _connect() { uni.connectSocket({ url: this.url, complete: () {} }) uni.onSocketOpen(() { this.reconnectTimes 0 this.onStatusChange this.onStatusChange(online) // 连接建立后先订阅仪表盘频道后端只推订阅了的数据 uni.sendSocketMessage({ data: JSON.stringify({ action: subscribe, channel: meter_dashboard }) }) this._startHeartbeat() }) uni.onSocketMessage((res) { this.onMessage this.onMessage(JSON.parse(res.data)) }) uni.onSocketClose(() { this.onStatusChange this.onStatusChange(offline) this._reconnect() }) } _startHeartbeat() { this.timer setInterval(() { uni.sendSocketMessage({ data: JSON.stringify({ action: ping }) }) }, 30000) } _reconnect() { if (this.reconnectTimes 5) return this.reconnectTimes 1 setTimeout(() this._connect(), 3000 * this.reconnectTimes) } }这段代码解决三个问题断线自动重连、定时心跳保活、订阅频道后才开始推送。实际生产里页面销毁时要调uni.closeSocket并把定时器清掉否则页面切走以后心跳还在跑小程序会弹“频繁调用”的告警。图表渲染方面微信小程序里用ec-canvas画折线图比较顺手。负荷曲线更新时不要整图setOption只更新series里的数据项性能差异在低端安卓机上非常明显。这个优化务必提前做否则巡检人员普遍用千元机页面刷新会卡到没法用。3.3 负荷异常识别的三阈值判断法用电负荷分析除了看曲线还要能在数据异常时给值班员提醒。对于那些还没有沉淀出AI模型的团队一套三阈值判断法就够撑起第一版异常识别。第一个阈值是绝对越限比如电流超过变压器额定电流的80%说明可能过载第二个阈值是变化率比如15分钟负荷同比上一时刻上涨超过30%说明有大设备启动或突跳第三个是负值阈值当功率持续为负说明可能存在倒送电或接线错误。三者是“或”关系但触发后的持续判定要叠加时间窗口防止瞬时波动误报。这个判断逻辑放在采集服务里做一层规则计算def check_power_anomaly(snapshot, previous, threshold_cfg): # 规则1绝对越限超过阈值立即预警 if snapshot[active_power] threshold_cfg[overload_kw]: return overload # 规则215分钟内功率环比突增且连续5个点都满足才触发 delta_pct (snapshot[active_power] - previous[active_power]) / max(previous[active_power], 1) if delta_pct threshold_cfg[ramp_pct] and snapshot[window_count] 5: return ramp_up # 规则3功率负值连续3个采集点判定为反向送电或接线异常 if snapshot[active_power] 0 and snapshot[window_count] 3: return reverse_flow return None这段代码里最容易忽略的参数是window_count表示连续满足条件的数据点数量。加上持续判定后误报率会明显下降。如果不做这个限制空调启动、电机软启带来的瞬时电流波动每天能触发上百次预警值班员几天后就把报警当背景噪音了。4. 故障预警系统与远程抄表自动化链路要这样设计4.1 故障预警规则引擎分级策略与触发条件配置从负荷异常识别到正式预警中间还隔着规则引擎。第一版如果所有预警逻辑都写在业务代码里后续调节阈值就变成了发版工程。一个轻量做法是把规则参数做成数据库可配置运维人员在后台就能改不用动代码。我用一张预警规则表字段是规则编码、设备类型、指标名称、比较符号、阈值、持续周期、告警级别、通知模板。告警级别分三级红、黄、蓝。红色表示设备跳闸或严重过载必须立即处置黄色表示过温、过流等异常趋势值班员需要在30分钟内确认蓝色是提醒类比如负荷率长时间低于15%提示设备利用率低。告警计算采用边采集边评估的模式每次数据入库就触发一次规则匹配。为了控制数据库压力规则匹配计算放在内存里规则表只在启动和手动刷新时加载一次。配置示例规则编码指标条件阈值持续点数级别R001A相电流大于额定电流80%3黄色告警R002变压器温度大于85℃2红色告警R003有功功率环比突增30%5黄色预警R004功率因数小于0.810蓝色提醒数据库可配置的好处是小程序后台可以直接暴露一个“阈值设置”页运维人员改完即时生效不需要重新发版。这也是故障预警系统能真正落地的关键——预警阈值一定要业务侧自己能够调整。4.2 远程抄表定时任务与断网补偿远程抄表的本质是定时采集多块电表的示数再汇总生成报表。技术上不复杂复杂的是分布式环境下不能重复抄、不能漏抄。后端只有一台服务器时直接用Spring定时任务就能跑Component public class MeterReadingTask { private static final Logger log LoggerFactory.getLogger(MeterReadingTask.class); // 每天23:55触发日冻结抄表避开零点前后采集高峰 Scheduled(cron 0 55 23 * * ?) public void dailyReading() { ListString meterIds meterService.listAllOnlineMeters(); for (String meterId : meterIds) { try { meterReadService.readAndStore(meterId); } catch (Exception e) { log.error(抄表失败 meterId{}, err{}, meterId, e.getMessage()); retryQueue.push(meterId); } } } }这里的readAndStore是同步方法内部调用采集器接口读取电表冻结数据。两个坑要注意一是某台表在抄表时刻正好通信失败不能直接跳过要丢进重试队列二是任务部署在多台机器时必须加分布式锁否则同一台表会被抄两次。我见过有项目没加锁月底电网对账发现电量翻倍排查两天才发现是两台应用同时执行了日冻结任务。抄表数据落库后还需要一天做一次数据补抄。现场串口通信偶尔丢帧抄表服务每天对前一天的采集成功率做统计低于95%就自动触发补抄。这部分逻辑用异步队列实现避免占用正常采集周期的时间片否则产线设备高峰期会出现采集超时。4.3 预警触达链路订阅消息、短信兜底与去重故障预警如果不触达就没有意义。小程序端最自然的方式是微信订阅消息。这里有个需要提前知道的事订阅消息通常是一次性授权用户每次点击“允许”只能接收一次推送长期订阅消息只对部分类目开放不是所有电力场景都能申请到。用户通过微信小程序登录后后端在授权记录里存openid。触发预警时后端调subscribeMessage.send接口把内容推过去# 发送小程序订阅消息的极简示例access_token需走缓存复用 import requests def send_wx_subscribe(openid, template_id, data, page/pages/alarm/index): token get_cached_access_token() # 从redis获取过期自动刷新 resp requests.post( https://api.weixin.qq.com/cgi-bin/message/subscribe/send, params{access_token: token}, json{ touser: openid, template_id: template_id, page: page, data: data, miniprogram_state: formal }, timeout5 ) return resp.json()data参数里放模板定义的字段比如设备名称、预警级别、发生时间。如果推送量特别大微信接口会限流我会在推送服务里做per-user队列每用户每秒最多推2条超出部分合并成一条汇总通知。短信兜底也有必要。值班电话收不到小程序通知是常事尤其是凌晨。常见做法是红色告警必须发短信黄色可选蓝色在用户开启夜间免打扰后不发送。短信通道费用高要配频控一小时内同一台设备最多发3条否则故障恢复反复触发短信费会失控。5. 电力设备管理常见问题排查五个高频翻车现场5.1 电表读数跳变是谐波干扰还是寄存器位宽现象某块表的正向有功电能从1234.56突然变成99999.99或者出现负值运维第一反应是表坏了。原因多数不是表坏了而是寄存器位宽和读取时序问题。很多多功能表用32位整数寄存器存累计电能满量程后回绕到0还有的情况是Modbus读取时跨寄存器边界的两个16位字没同步高16位和低16位来自不同刷新周期。RS485链路受谐波干扰读到错误字节序列的情况也时有发生。解决先把采集频率降下来在网关侧开启滤波和重试。针对小数点位做前置校验将本次读数与上次差值比对如果差值超过表计物理上可能的最大范围就丢弃并标记可疑数据等下一周期补采。这个校验要放在源头不要放到数据库清洗环节在下游擦数据永远补不齐。5.2 token过期引发登录态雪崩并发请求与refresh策略现象早上打开小程序一片空白所有接口同时返回401刷新也没用。后台日志显示token刷新接口被大量调用。原因小程序初始化会并发发出几十个请求第一个请求发现token过期后每个请求都各自调一次refresh接口微信服务端因为频繁刷新而短暂封禁。更隐蔽的是多个请求同时刷新时有的用了旧token去换新token微信返回invalid credential。解决把token刷新逻辑改造成全局单例的Promise所有并发请求共享同一个刷新动作拿到新token后再一起重放。let refreshPromise null function refreshTokenOnce() { if (!refreshPromise) { refreshPromise new Promise((resolve, reject) { wx.request({ url: /auth/refresh, success: resolve, fail: reject, complete: () { setTimeout(() { refreshPromise null }, 1000) } }) }) } return refreshPromise }这个方案同时解决“多个页面同时拉起登录”的问题。电力小程序的用户是值班员群体使用高峰集中在整点前后不做全局token锁翻车概率很高。5.3 凌晨数据错位时区与时间戳对齐现象凌晨1点到2点的抄表数据在报表里显示到前一天或后一天值班员对账怎么都对不上。原因服务器时区配置错乱电表走的是本地时间两者拼接时直接把时间戳转库没有统一成同一时区。尤其是边缘网关传回来的是UTC时间戳国内服务器没做转换。解决约束全局时间标准。表计与边缘网关走本地时间网关与后端之间统一传Unix时间戳或ISO 8601带时区字符串。数据库里一律用UTC存储业务展示时再转北京时间。SQL查询不要用本地时间直接比较字符串要用带时区的字段。我还加了一道兜底每小时把所有电表的实时时间与服务器时间做一次差值检测偏差超过30秒就告警逼现场把表计校时纳入巡检项目。5.4 预警风暴连续触发与防抖机制现象变压器温度到了85℃触发红色告警温度迟迟没降系统每隔一个采集周期重复推送值班手机一晚上响三十多次。原因规则引擎只做了条件触发没有做告警事件生命周期管理。同一设备同一规则在未确认前应该只有“开始”和“恢复”两个状态而不是每次满足条件都当作新告警。解决引入告警防抖和去重。每台设备加规则加级别组成一个告警事件第一次触发时创建事件后续只更新最后发生时间只有事件状态从active变为recovered后才允许触发新一轮。在规则引擎里加抑制窗口比如30分钟内同一设备同一规则最多推送3次。这样真正严重的故障不会被淹没在重复推送里值班员也能把注意力放在处理上。5.5 电量统计对不上倍率与统计周期口径现象营销系统里的电量和现场表计读数差几十倍看起来不是简单的小数点误差。原因电压互感器和电流互感器有变比表计显示的是二次侧值要乘以PT变比和CT变比才是实际电量。系统里维护表计时倍率参数没配全或者更换互感器后台账没更新。解决在设备档案里增加“合计倍率”字段抄表服务在读数后统一做乘法。核对方法是拿“表计本月读数差乘倍率”与上一级关口表数值对比误差超过1%就查档案。这类问题往往不是代码bug而是台账管理缺失需要在系统里加一道倍率变更审批流程避免运维人员随意修改造成数据失真。6. 电力需求预测与节能优化建议监控数据怎么产生下一层价值实时采集、可视化、预警、抄表都打通之后项目只完成了一半。真正让管理层愿意持续投入资源的是数据能不能转化为电力需求预测和节能优化建议。降本增效最容易落地的路径是移峰填谷把空调、储能、充电桩这类可调负荷从峰段挪到谷段。而判断什么时候能移、能移多少需要第二天96点负荷曲线。第一版不必上复杂的深度学习模型用历史负荷数据跑一个线性回归基线就够了import pandas as pd from sklearn.linear_model import LinearRegression # 历史15分钟负荷数据特征取小时、星期、温度 df load_history() # columns: hour, weekday, temperature, load_kw features df[[hour, weekday, temperature]].values target df[load_kw].values model LinearRegression().fit(features[:5000], target[:5000]) pred model.predict(features[5000:])这个模型精度不会太高但足以识别出明天哪个时段负荷大概率超过需量阈值从而把小程序的节能建议推给用户。评估预测性能看MAPE和RMSE两个指标MAPE控制在15%以内就可以上线试用。这套体系跑顺后我习惯每月让系统自动生成一份节能月报列出峰谷电量结构、变压器负载率、可调负荷清单让节能从应急管理变成日常运营。我还会在节能建议页放一个反馈入口让用户对每条建议标记“已采纳”或“不适合”反馈数据回流后用来修正下一条建议——别把系统做成单向广播一线用户的反馈是模型最便宜的增量训练数据。希望帮到你。本文还有配套的精品资源点击获取