Y951 智能配电箱省电产品化计划

状态：讨论版
目标：将 Y951 从“智能远程配电箱”升级为“可验证节能的智能配电箱”，在合适场景下帮助用户降低约 10%~20% 用电量。
相关产品文档：Y951 规格书

1. 方向判断

Y951 当前已经具备省电产品化的基础：

多回路独立控制：每一路可单独启停，适合泵、风机、增氧机、照明、阀门等负载。
定时与联动：可按时间计划或外部传感器数据控制回路。
云端平台：可上传状态、用电数据和运行记录，具备图表化和运维追踪基础。
可选监测模块：规格书中已有电流监测、断电/缺相监测、声光告警、显示屏等扩展能力。
后端基础：DataLogger 已有点位、历史数据、当前数据、定时任务、联动规则和点位操作日志。
前端基础：ums 已有设备、点位、历史曲线、定时和自动化工作台规划。

省电 10%~20% 不能作为所有场景的无条件承诺。它更适合表达为：

在存在空转、过度运行、人工忘关、固定定时不匹配现场需求、负载错峰需求的场景中，通过监测、调度、联动和运行优化，目标降低 10%~20% 的无效用电。

如果现场负载本身必须满时运行，或者没有功率/电流监测，只能做控制便利性和估算节能，不能形成强证明。

2. 产品定位

建议将 Y951 的新卖点定义为：

“可监测、可调度、可证明的智能节能配电箱。”

核心不是简单说“省电”，而是提供四件事：

看得见：每个回路的运行状态、运行时长、电流、功率、电量趋势可视化。
管得住：远程、定时、联动、批量策略控制多回路负载。
少浪费：识别空转、超时运行、低效运行和不必要运行。
讲得清：给出基线期、优化期、节电量、节电率和策略贡献。

第一版客户价值主打 节电量优先 + 减少人工优先。不考虑电价和节省电费，设备保护和异常告警作为辅助价值，不作为第一版主叙事。

节电量主线要求产品页面、建议排序和节能报告优先回答：

比基线少用了多少电：saving_kwh。
节电率是多少：saving_rate。
哪些建议或策略贡献了节电：strategy_contribution。
数据可信度如何：基线期、优化期、归一化口径和异常排除说明。

减少人工主线要求系统不要只给数据，而要把“发现问题 -> 生成建议 -> 用户确认 -> 生成定时器或规则 -> 复盘效果”做成闭环：

自动发现忘关、超时运行、固定定时不合理和可缩短运行窗口。
自动生成可落地的 Schedule / Rule 草稿，减少人工分析和配置规则的工作量。
用户只做确认、拒绝或修改，不需要手工从曲线里推断策略。
操作后自动复盘节电量、节电率和策略贡献，减少人工整理报告。

3. 多场景 Profile 架构

第一版 MVP 不限定温室大棚。Worker Energy Plugin 应采用多场景 profile 架构：通用节能分析内核负责计算、聚合、基线、异常和节电量；不同应用场景通过 scene_profile、基础提示词、设备信息、回路配置、传感器和 point 数据提供上下文。

核心原则：

Worker 的确定性代码负责 kWh、运行时长、基线、节电量、节电率、异常和策略贡献计算。
AI/提示词负责场景化理解、建议生成、原因解释和报告摘要，不直接替代核心计算。
场景差异放在 scene profile 中，不在 Worker 主流程里为温室、工厂、泵站分别写死算法。
MVP 选择一个实际项目跑通闭环即可，不限定项目必须是温室大棚。
已确认第一版只内置 generic_distribution_box:latest，用于通用智能配电箱节能分析；温室、工厂用电、泵站、水产等 profile 后续再添加。

后续可支持的典型场景：

场景	典型负载	节能机会
温室大棚	风机、水泵、补光灯、卷膜设备	根据温湿度、光照、时间段和天气联动，减少固定定时带来的浪费
工厂用电	空压机、排风、照明、循环水泵、辅助设备	识别非生产时间运行、固定定时不合理、异常高耗和长时间空转
水产养殖	增氧机、水泵、循环泵	按溶氧、时间段、天气或人工经验优化运行，减少全天候过度运行
畜禽养殖	风机、照明、喷淋、水泵	按环境数据和分区需求运行，减少低负载时段无效运行
工地/临时用电	照明、水泵、施工辅助设备	避免下班后忘关，识别异常长时间运行
分散站点	泵阀、排水、照明	远程策略和异常告警，降低无人值守浪费

不建议第一阶段主打对连续工艺、强制满负荷运行设备的节能承诺。

4. 节能能力分层

4.1 基础版：运行时长节能

适用于未选配功率监测或早期项目。

记录每个回路的开关状态和操作日志。
统计每日、每周、每月运行时长。
根据额定功率估算耗电量。
提供超时运行提醒、夜间忘关提醒、固定定时优化建议。

优点：硬件门槛低，能快速上线。
限制：节电量是估算值，客户说服力有限。

4.2 标准版：电流/功率实测节能

适用于希望明确展示节能效果的项目。

每个回路配置电流或功率监测点位。
采集电流、电压、功率、电量或至少可推导电量的关键数据。
结合回路开关状态，统计真实耗电趋势。
对比基线期和优化期，输出节电量和节电率。

优点：可形成可信节能报告。
限制：需要硬件选配和更高频数据采集。

4.3 高级版：智能策略节能

适用于多传感器、多回路、多目标优化的项目。

根据环境点位、生产目标和运行时间窗口生成策略建议。
自动识别空转、频繁启停、异常负载、低效运行。
第一版只支持建议模式；授权自动采纳作为后续能力，不进入 MVP。
给出每条策略的预计收益、风险和执行记录。

优点：形成差异化产品能力。
限制：需要足够历史数据和现场验证。

5. 数据闭环设计

5.1 必要数据

每个节能回路建议至少具备以下数据：

数据	说明	是否必须
回路控制点位	开、关、正转、反转、停止等控制点	必须
回路状态点位	每回路开/合状态，可与控制结果闭环校验	必须，当前已具备
电流点位	每回路电流，用于判断负载是否真实工作、是否空转或异常	必须，当前已具备
电压点位	每回路电压，用于电力质量和异常诊断	必须，当前已具备
有效功率点位	每回路有功功率，用于真实能耗计算和节能归因	必须，当前已具备
无效功率点位	每回路无功功率，用于功率因数和负载异常分析	推荐，当前已具备
火线端子温度	每回路火线端子温度，用于发热、接触不良和安全风险识别	推荐，当前已具备
电量点位	当前没有累计 kWh；第一版通过每分钟有效功率积分计算，后续如电表模块支持累计 kWh 再优先使用	后续增强
电压/相位点位	用于缺相、欠压、过压和安全分析	推荐
环境传感点位	温度、湿度、溶氧、光照、水位等	视场景需要
操作日志	记录谁在什么时候因为什么策略控制了哪一路	必须

5.2 数据频率

Y951 规格书当前写的是默认 1 小时上传一次，可调整。若要做节能，建议分级：

普通状态/低价值点位：5~60 分钟。
电流/功率/运行状态：1~5 分钟。
保护、故障、缺相、过流：事件实时上报。
策略执行前后：必须即时记录操作日志和关键点位快照。

如果仍保持 1 小时上传一次，只适合日报/月报级统计，不适合精细策略优化。

5.3 云端计算架构可行性

当前架构为“现场数据透传至云端，云端统一计算”，并且每分钟采集一次。该架构对 Y951 节能产品化是可行的，但需要明确适用边界。

适合放在云端计算的内容：

分钟级能耗统计、日报、月报和节能报告。
基线期与优化期对比。
忘关治理、超时运行提醒、空转识别、异常高耗识别。
按环境数据做分钟级启停建议，例如温湿度、溶氧、水位、光照触发。
策略建议生成、策略效果复盘和策略贡献分析。

不应只依赖云端计算的内容：

短路、过流、漏电、缺相、欠压、过压等电气保护。
急停、本地手动、手动/停止/自动模式优先级。
毫秒级或秒级强实时联锁。
网络断开时仍必须执行的安全停机逻辑。

每分钟采集一次的结论：

能力	是否足够	说明
月度/日度节能报告	足够	1 分钟粒度已经明显优于普通电表日/月统计
运行时长统计	足够	可准确统计回路开停时间，误差通常在分钟级
功率曲线积分	基本足够	适合稳定负载；大幅波动负载会有一定积分误差
空转识别	基本足够	适合持续空转；瞬时空转或短周期异常可能漏检
忘关/超时治理	足够	这类策略本身不需要秒级判断
错峰启动	取决于策略	分钟级错峰可行；防止同时启动冲击仍建议本地或网关侧处理
电气保护	不足	必须由断路器、保护模块或本地控制完成

数据量估算：

text

每日数据量 = 设备数量 x 点位数量 x 1440

示例：一台 16 回路 Y951，如果上传 40 个点位，每分钟一次：

text

40 x 1440 = 57,600 条/天/台
约 172.8 万条/月/台

这个量级可以接受，但需要工程上避免“每个点位一次请求”。推荐每分钟按设备批量上报一次，单次 payload 包含所有点位数据。云端需要做三层存储：

最新值表：用于实时页面和规则判断。
原始历史表：保留分钟级原始数据，用于追溯和重算。
聚合表：按 5 分钟、小时、日、月聚合，用于报表和大屏。

架构建议：

现场设备每分钟批量上报所有关键点位。
云端先写最新值，再写历史数据，再异步做能耗聚合。
云端策略只下发普通启停和建议，不承担电气保护。
工控屏显示云端策略状态，同时保留本地手动/停止优先级。
网络离线时，节能策略暂停或使用最近一次本地计划；安全保护不依赖云端。

因此，第一版可以继续采用云端计算，不必增加边缘计算主机。只有当后续需要秒级联锁、离线自动策略或高频波动分析时，再考虑把部分规则下沉到工控屏、PLC 或网关。

5.4 能耗计算方式

当前 Y951 每回路没有累计电量 kWh 点位，第一版应以“每分钟有效功率积分”作为分路能耗计算口径。后续如果电表模块或协议支持累计 kWh，再切换为累计电量差值优先。

优先级建议：

功率曲线积分：按每分钟有效功率和时间间隔求和，作为当前第一版主口径。
累计电量点位：后续如硬件提供累计 kWh，直接使用 kWh 差值，并作为更高可信度口径。
电流、电压、功率因数估算：适合没有功率点位但有电流点位的设备。
额定功率 x 运行时长估算：仅作为基础版兜底。

第一版报告需要明确标注：

分路 kWh 来源为每分钟有效功率积分。
误差主要来自采样间隔、缺失数据补点、负载短周期波动和功率点位校准误差。
若有总线累计电量，可用整箱总量校验分路积分总和的偏差。

公式示例：

text

节电量 = 基线期归一化能耗 - 优化期归一化能耗
节电率 = 节电量 / 基线期归一化能耗

归一化能耗需要按业务量或环境条件修正，例如养殖面积、设备数量、天气、生产批次、运行天数等。

6. 策略方向

6.0 真实省电机制

Y951 作为配电与控制设备，本身不能凭空提高水泵、风机、照明、增氧机的电机效率。真正能省电，必须来自以下几类可验证动作：

减少不该运行的时间。
减少超过实际需求的运行时间。
发现并处理异常耗电设备。
避免不必要的同时运行和峰值冲击。
将固定粗放运行改成按现场需求运行。

因此，节能产品不能只做数据展示，必须能改变设备运行行为。建议把节能策略分成以下几类：

机制	如何真实省电	典型例子	需要的数据
忘关治理	直接减少无效运行时长	夜间照明、施工水泵、备用风机超时后提醒或关闭	回路状态、运行时长、业务时间
按需运行	用传感器条件替代固定长时间运行	水位到达后停泵，温度达标后停风机，溶氧达标后停增氧机	环境点位、回路控制点、回路状态
空转治理	发现设备开着但没有有效产出	水泵无水空转、风机皮带异常、增氧机负载异常	电流、功率、状态、必要时加水位/压力/流量
过量运行压缩	找出每天可缩短的运行窗口	固定运行 12 小时，但有效需求只有 9~10 小时	历史功率、环境数据、运行结果
错峰控制	降低同时运行峰值，减少过量启动和高负荷时段集中运行	多台大功率泵错开启动，降低整箱峰值功率	功率、时间、回路优先级
异常耗电维护	修复高耗设备，恢复正常能效	水泵堵塞、电机轴承异常、接触器异常导致电流偏高	分路电流、功率、历史正常区间
外部条件预测	根据天气或外部条件提前调整运行计划	降雨前暂停灌溉，降温前减少风机，强光时减少补光	天气预报、传感器、业务规则

第一阶段最容易做出真实效果的是：

忘关治理。
超时运行治理。
固定定时改为按需联动。
空转识别与停机/告警。
异常高耗提醒。
结合传感器和天气数据动态调整运行窗口。

不建议第一阶段把重点放在“AI 预测省电”。如果没有明确控制动作，预测只能解释数据，不能产生真实节电。

判断一个策略是否是真节能，可以用一个简单标准：

text

这个策略是否让某个负载少运行了一段原本不必要的时间？
这个策略是否发现并消除了某个异常耗电状态？
这个策略是否在不影响生产结果的情况下改变了运行窗口？

如果答案是否定的，它就不是节能策略，只是数据展示。

6.0.1 结合传感器和第三方数据

云平台已经支持传感器数据上报，现场可通过数据采集器连接传感器和云端。这个能力应作为真实节能的关键输入，而不是只用于展示曲线。

传感器数据适合解决“当前是否需要运行”：

传感器数据	可控制负载	真实节能方式
水位	水泵、排水泵、补水阀	达到目标水位后停止，避免固定时间过量运行
温度	风机、湿帘、加热、通风	达到目标温度后停止或降低运行频率
湿度	风机、除湿、喷淋	避免湿度已达标仍继续运行
溶氧	增氧机、水循环	溶氧达标后停机，低于阈值再启动
光照	补光灯、遮阳、卷膜	自然光足够时减少补光
土壤湿度	灌溉泵、电磁阀	土壤湿度达标后停止灌溉
压力/流量	水泵、管道设备	判断空转、堵塞、漏水和无效运行

第三方数据适合解决“接下来是否需要运行”：

第三方数据	可控制负载	真实节能方式
天气预报降雨	灌溉泵、喷淋	预计降雨时延后或取消灌溉
天气预报温度	风机、加热、通风	预计降温时减少提前通风，预计升温时提前低功率运行
天气预报湿度	除湿、通风、喷淋	避免在高湿天气做低效除湿或喷淋
光照/日出日落	补光灯、照明	根据自然光减少补光和照明
气象灾害预警	水泵、排水、通风	提前排水或进入保护模式，减少事后高耗补救

设计原则：

传感器数据用于实时闭环，第三方天气数据用于计划调整。
传感器优先级应高于天气预报，现场真实数据高于预测数据。
天气数据只能调整可延迟、可提前、可暂停的负载，不能覆盖安全策略。
第三方数据必须记录来源、更新时间和有效期，过期数据不能参与策略建议生成。
生成建议前必须检查人工锁定、关键负载等级、最小运行时间和最小停机时间；第一版只生成建议，不自动采纳。

典型策略示例：

text

工厂用电：
如果照明或排风在非生产时间持续运行，则生成关闭或调整定时器建议。
如果空压机回路在非生产时间仍有稳定功率，则生成空转检查建议。
如果循环水泵连续运行超过业务窗口，则建议缩短运行窗口或增加规则。

温室风机：
如果棚内温度高于阈值且室外温度更低，则开启风机。
如果天气预报未来 1 小时降温，且当前温度未超过安全上限，则延后启动。
如果棚内湿度已达标且温度未超限，则缩短固定通风时长。

温室补光：
如果光照低于阈值且处于作物需要补光时段，则开启补光。
如果天气预报强光或日出临近，则缩短补光时长。

温室灌溉/喷淋：
如果土壤湿度低于阈值，但未来 3 小时预计降雨，则延后灌溉。
如果未来 3 小时无降雨且土壤湿度持续偏低，则启动灌溉。

水产增氧：
如果溶氧低于阈值，则立即启动增氧机。
如果溶氧达标且未来天气稳定，则停止或轮换运行。
如果夜间、高温、阴雨等高风险条件出现，则提高溶氧安全阈值。

这里的关键是：外部数据必须改变设备运行计划。只展示天气、温度、湿度，不会省电。

6.1 第一版只做一个简单通用策略模板

第一阶段不要直接做“AI 自动省电”，也不要一次性内置过多策略模板。generic_distribution_box 第一版只放一个最简单、跨场景成立的策略模板，目标是先跑通“发现机会 -> 生成建议 -> 用户确认 -> DataLogger 落地 -> 复盘节电量”的闭环。

建议第一版模板：

长时间运行提醒：回路连续运行超过配置阈值，生成减少运行、增加定时器或人工检查建议。
阈值来源：优先使用 EnergyCircuitMapping.max_continuous_run_minutes；未配置时使用 SceneProfile.default_thresholds.max_continuous_run_minutes。
generic_distribution_box 第一版默认值：max_continuous_run_minutes = 120。

后续再逐步扩展：

忘关治理：超过设定时长自动提醒或关闭。
空转识别：控制点已开启但电流低于阈值，判定负载未正常工作。
异常高耗：电流或功率高于历史正常区间，提醒维护。
分时运行：按业务时间窗口运行，夜间或低需求时段降低运行。
环境联动：温湿度、溶氧、水位、光照等达到阈值后启停设备。
互锁与错峰：避免多路高功率负载同时启动，降低峰值负荷。
最小运行/最小停机时间：避免频繁启停损坏设备。

6.2 再做建议型智能优化

当积累足够数据后，增加策略建议：

推荐缩短某一路每日运行时长。
推荐调整定时器起止时间。
推荐将固定定时改成环境联动。
推荐合并或错开高功率负载。
推荐检修异常耗电回路。

建议先由用户确认执行，不直接自动控制。

6.3 后续做授权自动采纳

成熟后再提供授权自动采纳，不提供 Worker 或 AI 直接控制设备：

用户设定安全边界、运行窗口和目标阈值。
DataLogger 在用户预授权范围内自动接受低风险建议，并创建 Schedule / Rule / Control。
每次控制都记录策略来源、原因、预计影响和实际结果。
用户可一键暂停授权自动采纳，恢复手动确认。

6.4 AI 的定位

节能产品需要 AI，但 AI 不应该成为第一版省电闭环的核心控制逻辑。原因是：

真实省电首先依赖明确控制动作，例如关停、延后、缩短、轮换和错峰。
电气控制必须可解释、可复核、可回滚，不能只依赖模型判断。
第一阶段数据量不足时，AI 容易给出看似合理但不可验证的建议。
现场安全、生产风险和客户信任要求策略必须有确定边界。

推荐定位：

层级	是否用 AI	职责
控制执行层	不依赖 AI	执行开关、停止、定时、联动、安全边界
规则策略层	少量使用 AI 辅助	将用户目标转成可解释规则，仍由确定性条件执行
策略建议层	适合使用 AI	发现可缩短运行时段、异常耗电、定时不合理、传感器阈值建议
报告解释层	适合使用 AI	解释节能来源、异常原因、策略效果和下一步建议
参数优化层	后续使用 AI	根据历史数据推荐阈值、运行窗口和轮换策略

第一阶段不建议做：

AI 直接决定关键负载开关。
AI 直接绕过定时/联动/安全边界下发控制。
AI 在没有足够历史数据时承诺节电率。
AI 生成无法追溯原因的自动策略。

第一阶段建议做：

AI 读取历史运行、能耗、传感器和天气数据，输出节能机会。
AI 将机会转成草稿策略，例如“建议把 1 号风机从固定运行改为温度联动”。
用户确认后，由系统生成确定性规则执行。
AI 解释每条策略为什么建议、预计影响、风险和验证方式。

推荐流程：

text

项目配置 + 回路能力 + 历史数据 + 传感器 + 天气 + 操作日志 + 场景提示词
  -> AI 发现节能机会
  -> 生成策略建议
  -> 用户确认
  -> 转成确定性规则
  -> DataLogger 执行控制
  -> Worker 插件验证结果

最终目标不是“AI 自动省电”，而是“AI 帮助发现省电机会，确定性系统负责可靠执行”。

第一版 AI 决策应是“配置驱动建议”，不是固定负载策略：

项目没有配置补光灯，AI 不应生成补光建议。
项目有风机但没有温湿度传感器，AI 只能基于运行时长、功率和天气给低置信度建议，不能生成授权自动采纳规则。
项目有风机、棚内温度、棚内湿度和室外天气，AI 可以建议把固定通风改为温湿度联动。
项目有补光灯、光照传感器、日出日落和作物补光时段，AI 可以建议缩短不必要补光。
项目有水泵但没有水位、土壤湿度或流量数据，AI 不能判断是否过量灌溉，只能做超时、忘关和异常功率提醒。

6.4.1 AI 建议类型

结合 DataLogger 已有定时功能和规则引擎，AI 第一阶段不需要新增执行系统。AI 只生成建议，用户确认后落到现有能力：

AI 建议类型	示例	用户确认后落地方式
即时操作建议	建议现在开启 1 号风机 10 分钟	调用现有点位控制接口，写入 `PointOperationLog(source=ai)`
定时器建议	建议增加定时器：每 5 分钟开启风机 1 分钟	创建或更新现有 `Schedule`
规则建议	建议增加规则：当温度大于 25℃ 时开启风机	创建或更新现有 `Rule`
参数调整建议	建议将风机关闭阈值从 23℃ 调整到 24℃	修改现有规则条件或策略参数
维护建议	2 号水泵电流高于历史正常区间，建议检查堵塞或轴承	只生成建议和告警，不自动控制

建议数据结构可以统一为 EnergyRecommendation：

字段	说明
recommendation_type	`manual_action` / `schedule` / `rule` / `parameter_change` / `maintenance`
target_circuit_id	目标回路
title	建议标题
reason	建议原因
evidence	触发建议的数据证据
expected_effect	预计影响，例如预计减少运行时长或耗电
risk_level	风险等级
proposed_payload	可转换为 Schedule、Rule 或控制请求的结构化参数
status	`pending` / `approved` / `rejected` / `applied`

示例：定时器建议

json

{
  "recommendation_type": "schedule",
  "target_circuit_id": "device_1:fan_1",
  "title": "建议增加间歇通风定时器",
  "reason": "过去 3 天温度接近阈值但未持续超限，连续运行风机存在过量运行。",
  "expected_effect": "预计每天减少风机运行 2~3 小时。",
  "proposed_payload": {
    "trigger_mode": "interval",
    "interval_minutes": 5,
    "action": "on",
    "duration_minutes": 1
  }
}

示例：规则建议

json

{
  "recommendation_type": "rule",
  "target_circuit_id": "device_1:fan_1",
  "title": "建议增加温度联动规则",
  "reason": "温度超过 25℃ 后风机开启可降低过量固定运行。",
  "proposed_payload": {
    "condition": {
      "metric": "temperature",
      "operator": "greater_than",
      "value": 25
    },
    "action": {
      "command": "on"
    }
  }
}

执行原则：

AI 只生成 pending 建议，不直接生效。
用户确认后才创建定时器、规则或即时控制动作。
所有真实控制仍走 DataLogger 现有控制链路。
建议必须携带证据和原因，不能只给结论。
建议必须可拒绝、可撤销、可查看执行结果。

7. 后端计划：DataLogger

现有基础：

AgriDevicePoint 可表达每个回路的控制、状态、电流、功率等点位。
DataReportService 当前可将数据写入 SQS 和 D1 最新值表。
PointDataViewSet 已支持按 agri_id 查询历史数据。
Schedule 已支持 once、daily、interval 和持续时长。
Rule 已支持点位条件、点位控制动作、冷却时间、运行审计。
PointOperationLog 已统一记录手动、定时、规则、AI 等控制来源。

DataLogger 建议新增或增强：

模块	计划
点位类型	增加或规范电流、电压、有效功率、无效功率、回路状态、火线端子温度、功率积分电量等共享点位类型
Recommendation API	保存建议、建议详情、证据、接受、拒绝、应用状态和审计
Schedule/Rule 草稿 API	用户接受建议后，由 DataLogger 创建定时器或规则
控制承接	即时操作建议被接受后，仍通过现有控制接口执行并写操作日志
安全边界	接受建议时检查权限、关键负载、人工锁定、最小运行/停机时间等约束

聚合、基线、异常分析、节能报告和 AI 建议生成由 Worker Energy Plugin 承担，不放进 DataLogger 第一阶段主流程。

7.1 解耦架构设计

为了尽量不绑定当前 DataLogger 和 ums 的内部实现，建议把节能分析能力放在 Worker Energy Plugin 中，DataLogger 只作为数据、建议生命周期和执行底座。

核心原则：

DataLogger 继续做数据采集、点位管理、设备控制和操作日志。
Worker Energy Plugin 只依赖 DataLogger API、MongoDB 原始历史数据和标准数据模型，不直接依赖 DataLogger 内部表结构。
DataLogger 管理建议的保存、展示、接受、拒绝、应用和审计。
UMS 只作为展示和配置入口，不把节能算法写在前端；UMS 不直接调用 Worker，只调用 DataLogger 节能相关 API。
Energy-worker 只和 DataLogger 层交互；外部业务系统不直接访问 Worker。
节能策略的输出先是“建议”和“控制请求”，由现有控制通道执行。
电气安全、手动优先和本地保护仍由硬件、本地控制或现有控制链路负责。

建议边界：

text

现场设备
  -> DataLogger 数据接入层
  -> 标准化遥测事件 EnergyTelemetry
  -> Worker Energy Plugin
      -> 能耗聚合
      -> 基线对比
      -> 策略评估
      -> 节能报告
      -> 建议草稿
  -> DataLogger Recommendation API
  -> DataLogger Schedule / Rule / Control
  -> 现场回路

7.1.1 Worker 插件不直接理解原始点位

当前系统里点位是 agri_id，这是 DataLogger 的基础模型。Worker 插件不应在算法里硬编码某个 agri_id 是电流、功率或控制点，而应增加一层“回路映射”。

建议建立 EnergyCircuitMapping 概念：

字段	说明
project_id	所属项目
device_id	所属 Y951 设备
circuit_no	回路编号
circuit_name	回路名称
load_type	负载类型，例如 `fan` / `lighting` / `pump` / `curtain` / `spray` / `other`
load_purpose	负载用途，例如通风、补光、灌溉、喷淋、卷膜
control_point_id	控制点位
status_point_id	运行状态点位
current_point_id	电流点位，可选
power_point_id	功率点位，可选
energy_point_id	累计电量点位，当前没有，作为后续增强可选
related_sensor_ids	相关传感器点位，例如温度、湿度、光照、土壤湿度
rated_power_kw	额定功率，用于估算
critical_level	关键负载等级
max_continuous_run_minutes	最大连续运行时长；未配置时使用 SceneProfile 默认值
min_on_minutes	最小运行时间，避免频繁启停
min_off_minutes	最小停机时间，避免频繁启停
allowed_actions	允许建议的动作，例如 `schedule` / `rule` / `manual_action`
auto_accept_enabled	后续字段，第一版固定为 `false`，不启用授权自动采纳

这样 Worker 插件面向“回路”工作，而不是面向零散点位工作。后续如果底层点位格式、设备型号或数据源变化，只需要调整映射层。

建议同时建立 EnergyProjectConfig，作为 AI 和策略引擎的输入边界：

字段	说明
project_id	项目 ID
scene_type	场景类型，例如 `greenhouse` / `factory_power` / `pump_station` / `aquaculture` / `generic_distribution_box`
scene_profile_id	场景 profile ID；第一版固定使用 `generic_distribution_box:latest`
user_goal	用户目标，例如省电优先、稳产优先、设备保护优先
prompt_profile	场景提示词模板，例如温室节能、工厂非生产时段节能、谨慎控制、只生成建议
business_hours	业务运行时间窗口
weather_location	天气位置，可选
safety_policy	安全策略，例如关键负载、人工锁定、最小运行/停机时间、允许建议动作
circuit_mappings	回路能力配置列表

EnergyProjectConfig 和 EnergyCircuitMapping 属于 project 配置，由 UMS 提供配置界面，通过 DataLogger 节能配置 API 提交并保存。DataLogger 可以新增独立的项目节能配置表或 JSON 配置字段，但不改造 AgriDevicePoint、Schedule、Rule 等主模型。Worker 不接收 UMS 或 DataLogger 推送配置，Worker 在分析任务中通过 DataLogger API 拉取配置，并写入项目 D1 作为分析侧缓存、快照和追溯依据。

AI 的输入必须来自 EnergyProjectConfig、EnergyCircuitMapping、历史数据和外部上下文，不能直接根据回路名称或点位名称猜测控制策略。

已确认第一版 SceneProfile 存 R2，由研发直接维护；普通 UMS 项目用户只选择 profile，不直接编辑底层提示词、策略模板和安全规则。第一版只内置 generic_distribution_box:latest，R2 更新后下一轮 Worker 分析自动使用最新版本。

字段	说明
scene_profile_id	profile ID
scene_type	场景类型
base_prompt	基础提示词
supported_load_types	支持的负载类型
required_context	建议需要的传感器、业务时间、天气或生产上下文
strategy_templates	可用策略模板；第一版只内置长时间运行提醒，后续再扩展忘关、超时、按需运行、异常高耗、错峰等
default_thresholds	默认阈值；第一版包含 `max_continuous_run_minutes = 120`
safety_rules	场景安全边界
output_schema	建议输出结构约束

版本要求：

R2 保存具体版本文件，例如 scene-profiles/generic_distribution_box/v1.json、scene-profiles/generic_distribution_box/v2.json。
第一版由研发直接覆盖或更新 scene-profiles/generic_distribution_box/latest.json，不设置管理员审核流程。
即使 latest 可直接覆盖，也必须保留具体版本文件，避免只剩一个不可追溯的 latest。
Worker 分析时按 scene_profile_id = generic_distribution_box:latest 加载最新 profile。
Worker 必须在 recommendation_trace、report_snapshot 和分析日志中记录实际解析到的 resolved_scene_profile_version。
如果 profile 更新导致建议行为变化，应能通过 trace 追溯当时使用的具体版本。

配置边界：

UMS：负责配置入口、校验提示、人工确认和展示；只调用 DataLogger API，不直接调用 Worker。
DataLogger Energy API：负责接收 UMS 的节能配置读写请求，做项目权限、用户权限、基础点位存在性校验，并保存项目节能配置主副本。
Worker：通过 DataLogger API 拉取节能项目配置和回路能力配置；第一版配置保存后立即生效，参与下一轮分析。
D1：保存 Worker 拉取到的 EnergyProjectConfig、EnergyCircuitMapping、提示词 profile 选择和配置版本快照，用于分析追溯，不作为配置主副本。
R2：保存可版本化的 SceneProfile；第一版只内置 scene-profiles/generic_distribution_box/latest.json，由研发直接维护。
DataLogger：保存节能项目配置主副本，但不修改 AgriDevicePoint、Schedule、Rule 等主模型；同时作为权限、入口、建议生命周期和执行审计层。

第一版不做配置发布和审核流程。UMS 保存配置后写入 DataLogger 项目节能配置主副本；Worker 后续 Cron、分析任务和 AI 建议生成通过 DataLogger API 拉取最新配置，并同步配置快照到 D1。为降低误配置风险，保存前必须做基础校验，保存后必须写入 config_version：

校验回路引用的 DataLogger 点位是否存在。
校验控制点、状态点、电流点、功率点的类型是否匹配。
校验关联传感器是否属于同一项目或被授权引用。
校验关键负载是否设置了 critical_level、min_on_minutes、min_off_minutes 和 allowed_actions。
记录修改人、修改时间、修改前后摘要和配置快照，支持人工回滚。

7.1.2 标准化遥测事件

Worker 插件消费标准化后的数据，不消费设备原始协议。

建议事件格式：

json

{
  "project_id": "project_x",
  "device_id": "device_1",
  "circuit_id": "device_1:1",
  "metric": "power_kw",
  "value": 1.25,
  "unit": "kW",
  "timestamp": 1710000000,
  "quality": "ok"
}

metric 建议使用稳定枚举：

text

voltage_v
current_a
power_kw
energy_kwh
power_factor
run_state
control_state
temperature
humidity
dissolved_oxygen
water_level
light_lux

DataLogger 可以继续保存原始数据，但在进入 Worker 插件分析前转换成统一指标。

7.1.2.1 标准化外部上下文

第三方天气、日出日落等数据不应直接写进策略算法。建议先转换成 EnergyExternalContext，再由 Worker 插件消费。

建议事件格式：

json

{
  "project_id": "project_x",
  "location": {
    "lat": 28.12,
    "lng": 112.98
  },
  "provider": "weather_provider",
  "context_type": "weather_forecast",
  "metric": "rain_probability",
  "value": 0.75,
  "unit": "ratio",
  "valid_from": 1710000000,
  "valid_to": 1710010800,
  "fetched_at": 1709999900,
  "quality": "ok"
}

建议上下文类型：

text

weather_current
weather_forecast
sunrise_sunset
weather_alert

设计要求：

节能策略只读取标准化上下文，不直接调用第三方接口。
第三方数据必须带有效期，超过有效期后只允许用于展示，不允许参与策略建议生成。
不同供应商的数据结构由 External Context Adapter 适配。
现场传感器数据优先级高于第三方预测数据。

7.1.3 Worker 插件内部模块

建议 Worker Energy Plugin 拆成几个独立模块：

模块	职责
Telemetry Adapter	从 DataLogger/SQS/API 读取标准遥测
External Context Adapter	接入天气、日出日落等第三方数据并标准化
Circuit Registry	管理 Y951 设备、回路和点位映射
Energy Aggregator	生成分钟、小时、日、月能耗聚合
Baseline Engine	管理基线期、优化期和归一化规则
Strategy Engine	评估忘关、空转、超时、错峰、环境联动等策略
Recommendation Engine	输出节能建议，不直接控制
Result Output	输出节电量、节电率、策略贡献、异常分析和报告结论

第一阶段这些模块运行在 Worker Energy Plugin 中。DataLogger 不新增独立 energy app，只补 recommendation API、建议状态流和 Schedule/Rule/Control 承接能力。

Worker 的边界和具体工作：

Worker 是后台计算分析服务，不是 UMS 的在线业务 API。
Worker 不拥有 project 配置主权；project 节能配置保存在 DataLogger，Worker 只读取并保存分析快照。
Worker 读取 MongoDB 原始分钟数据、DataLogger 项目/设备/点位/状态/规则/日志/配置，以及 R2 SceneProfile 和第三方上下文。
已确认第一版 DataLogger 给 Worker 提供标准输入能力：项目、设备、点位、当前状态、历史数据窗口、project 节能配置、已有定时器、已有规则和操作日志。
Worker 负责能耗聚合、基线对比、异常识别、策略机会评估、AI 辅助解释、报告结论生成。
已确认 Worker 输出业务可展示结果到 DataLogger；完整分析过程、聚合细节、基线细节、AI 过程和 trace 保留在 D1。输出到 DataLogger 的具体字段和数据粒度后续单独设计。
已确认 Worker 输出结构化建议草稿；DataLogger 负责保存、展示、接受、拒绝，并在用户接受后承接 Schedule/Rule/Control。建议通过 DataLogger recommendation API 提交；该 API 当前还没有，需要后续补充设计。
Worker 不直接控制设备，不创建生效的 Schedule/Rule，不绕过 DataLogger 的权限、日志和安全边界。
已确认第一版触发方式为 Cron + 内部手动触发。Cron 负责正常周期分析；内部手动触发只用于试点调试、单项目重算和报告验证，不作为 UMS 在线页面入口。
已确认第一版分析频率采用分层频率：轻量分析按短周期运行，完整分析按日运行。建议第一版先用“每 15 分钟轻量分析 + 每天 1 次完整分析”作为默认节奏，后续按项目规模和 MongoDB 压力调整。

7.1.3.1 智能配电箱电力插件

这里的“插件”不是开放插件平台，也不是按温室、水产、灌溉拆成多个独立插件。插件应定义为面向电力行业和智能配电箱的业务增强模块。

插件底层依赖 DataLogger 提供的数据和 API：

读取项目、设备和点位。
读取当前值、历史数据、操作日志、定时器和规则。
读取传感器数据和第三方外部上下文。
从 DataLogger 读取 project 节能配置、回路映射、提示词 profile 选择和安全策略，并在 D1 保存分析快照。
保存插件自己的计算结果、聚合数据和分析结果。
通过 DataLogger API 提交建议草稿。
建议的接受、拒绝、应用和审计全部由 DataLogger API 管理。

推荐边界：

text

DataLogger
  -> 设备、项目、点位、历史数据、当前数据
  -> 定时器 Schedule
  -> 规则引擎 Rule
  -> 点位控制 Control API
  -> 操作日志 PointOperationLog

Smart Distribution Energy Plugin
  -> 读取 DataLogger 数据
  -> 保存经 DataLogger 提交的项目配置和回路映射
  -> 建立回路视图
  -> 分析能耗和运行行为
  -> 保存插件计算数据
  -> 生成建议草稿
  -> 通过 DataLogger API 提交建议

插件拥有自己的派生数据，不污染 DataLogger 的主数据模型：

插件数据	说明
energy_project_config_snapshot	Worker 从 DataLogger 拉取的项目级节能配置快照，用于分析追溯
energy_circuit_mapping_snapshot	Worker 从 DataLogger 拉取的回路能力配置快照，用于分析追溯
circuit_snapshot	回路级快照，聚合控制点、状态点、电力点位
energy_aggregate	分钟、小时、日、月能耗聚合
baseline_profile	基线期模型和对比口径
anomaly_event	空转、异常高耗、长时间运行等分析事件
recommendation_trace	插件侧建议生成过程、证据摘要和 DataLogger 建议 ID 的映射
recommendation_effect	建议被应用后的插件侧效果评估，正式状态仍以 DataLogger 为准

插件不直接做的事情：

不直接连接现场设备。
不直接调用网关。
不绕过 DataLogger 的权限、审计、定时器和规则引擎。
不修改 DataLogger 原始历史数据。
不把安全保护逻辑放到插件里。

插件内部可以有不同分析模板，但这些模板不是系统级插件：

模板	作用
fan_ventilation	分析风机、通风、温湿度联动
irrigation_pump	分析水泵、灌溉、水位、土壤湿度
aquaculture_oxygen	分析增氧机、溶氧、水温、天气风险
lighting	分析照明、补光、日出日落和光照

这些模板只影响插件如何生成建议，不影响 DataLogger 的数据模型和执行链路。

建议插件对 DataLogger 暴露或调用的 API 形态：

API	方向	用途
DataLogger telemetry/history API	插件读取	获取当前值和历史点位数据
DataLogger schedule/rule API	插件读取	理解已有定时器和规则，避免重复建议
DataLogger operation log API	插件读取	分析人工操作和策略执行效果
DataLogger recommendation API	插件写入	提交建议草稿，由 DataLogger 管理接受、拒绝、应用和审计
DataLogger recommendation status API	插件读取	同步建议状态和应用结果
DataLogger schedule/rule/control API	DataLogger 内部执行	用户接受建议后由 DataLogger 创建定时器、规则或控制动作

推荐流程：

text

插件定时运行或被事件触发
  -> 调 DataLogger API 拉取数据
  -> 生成/更新插件计算数据
  -> 分析节能机会
  -> 生成建议草稿
  -> 通过 DataLogger recommendation API 提交建议
  -> DataLogger 保存建议并提供给 UMS
  -> 用户在 DataLogger/UMS 接受或拒绝
  -> DataLogger 创建 Schedule / Rule / Control
  -> 插件继续跟踪建议效果

这个设计的重点是：DataLogger 是数据、建议生命周期和执行底座，智能配电箱电力插件是分析和建议生成层。后续如果要为不同行业扩展特殊逻辑，优先在插件内部增加分析模板，而不是改 DataLogger 主流程。

7.1.3.2 Cloudflare Worker 部署形态

智能配电箱电力插件可以使用 Cloudflare Worker 实现，适合作为独立于 DataLogger 的轻量分析与建议服务。

推荐职责：

组件	职责
Worker Background Job	执行节能分析、聚合计算、报告生成和建议生成
Worker Cron	第一版主触发方式；默认每 15 分钟运行轻量分析，每天运行 1 次完整分析
Internal Manual Trigger	第一版辅助触发方式，用于试点调试、单项目重算和报告验证，不面向 UMS 页面
D1	保存插件计算数据、聚合数据、基线、异常事件和建议生成 trace
R2	保存可版本化 SceneProfile、模型提示词、场景模板、报告文件、导出文件
Workers AI	生成节能建议、解释异常原因、生成报告摘要和策略草稿
DataLogger API	作为底层数据源和执行接口，负责采集、控制、定时、规则、日志
MongoDB	保存 DataLogger 每分钟原始历史数据，第一版由 Worker 直接读取，用于批量分析和回溯

推荐部署边界：

text

UMS
  -> 调用 DataLogger Energy API

DataLogger
  -> 继续负责点位、数据、定时、规则、控制、操作日志、建议生命周期和权限边界
  -> 保存项目节能配置、建议，以及 Worker 输出后需要进入业务闭环的结果

Worker Energy Plugin
  -> 读取 D1 插件计算数据
  -> 读取 R2 静态模板
  -> 调用 Workers AI 生成建议
  -> 读取 MongoDB 原始分钟数据
  -> 调用 DataLogger API 读取项目、设备、点位、当前值、日志、定时器和规则
  -> 调用 DataLogger API 提交建议草稿
  -> 调用 DataLogger API 输出分析结果

已确认第一版采用“一项目一个 D1”。这个模式可以作为长期架构方向，但不能无治理地自然扩张；需要明确项目规模、绑定路由、迁移、监控和跨项目分析方案。

优点：项目级数据隔离清晰，单项目数据迁移和删除简单，查询范围天然收敛。
优点：符合按项目/租户隔离派生数据的思路，适合节能插件这种项目级配置、聚合和建议数据。
风险：如果所有项目 D1 都静态绑定到同一个 Worker，项目数量很大时会遇到绑定数量、配置体积和部署维护问题。
风险：单个 D1 适合一个项目的聚合和建议数据，不适合承载所有项目的高频原始数据。
已确认第一版基础方案选择 A：D1 只保存节能插件派生数据，不保存全量 point 明细或长期分钟级标准化副本。
可选增强：后续可能在项目 D1 中保存最近 1 个月的标准化 point 数据副本，用于近期页面查询、节能分析和减少 MongoDB 查询压力；该能力需要单独设计表结构、保留策略和同步补偿机制，不作为 MVP 前置条件。
约束：D1 当前优先保存配置、回路映射、聚合、基线、异常事件、建议 trace、效果评估和报告快照；原始数据仍以 DataLogger/MongoDB 为准。
已确认第一版 D1 路由选择 A：少量试点项目的 D1 通过 Worker 静态绑定访问。
第一版需要维护简单的 project_id -> D1 binding name 映射配置；Worker 分析任务按 project_id 选择对应 D1。
长期运行要求：必须有统一的 D1 schema migration、项目到 D1 的路由表、批量初始化脚本、监控告警、备份/导出和跨项目汇总方案。
扩展触发条件：当项目数量、D1 binding 数量、迁移成本、跨项目查询成本或运维监控成本明显上升时，进入 D1 路由/分组 Worker/registry 方案设计。

MongoDB / D1 近期数据读取方案：

已确认第一版采用 Worker 直连 MongoDB，读取原始分钟数据，用于批量分析、基线计算、异常回溯和建议生成。
已确认 MongoDB 分钟级原始历史数据保留 90 天。
Worker/D1 应保存小时、日、月聚合数据，聚合数据保留至少 12 个月，用于月报、趋势和跨周期对比。
90 天以外的节能报告不应依赖 MongoDB 原始分钟数据重算，只使用 D1 已生成的聚合数据和报告快照。
已确认 Worker 读取 MongoDB 的 POC 不作为 MVP 前置阻塞项；业务设计可以继续推进。
Worker 直连 MongoDB 的具体实现方式第一版不提前锁死，作为并行技术 POC 决策项。
POC 需要比较 TCP socket、Worker 兼容 driver / community driver 等直连方案，验证 TLS、认证、查询性能、错误恢复、部署复杂度和维护成本。
不假设传统 Node.js MongoDB driver 在 Worker 中无改造可用；如果使用 TCP socket，需要验证 BSON 协议、TLS 和连接生命周期。
如果项目 D1 后续保存最近 1 个月标准化 point 副本，Worker 优先读取 D1 近期数据；MongoDB 用于补数、校验、90 天内重算和 D1 未覆盖时间窗口的回溯。
MongoDB 必须提供 Worker 可访问的公网 TLS 入口；Cloudflare Worker 不能直接连接 localhost、私网地址或仅内网可达的 MongoDB。
不能依赖固定 Cloudflare 公布 IP 段做 allowlist，因为 Workers TCP 出站来源不属于 Cloudflare 公布 IP 范围；更适合使用强密码、TLS、最小权限账号、必要时 mTLS 或数据库侧访问代理。
不建议 UMS 在线页面通过 DataLogger 每次请求都触发 Worker 查询或计算。
第一版使用 Worker Cron 按项目增量读取 MongoDB。默认节奏为每 15 分钟轻量分析一次，每天完整分析一次；内部手动触发用于研发/管理员重算。Queue 作为多项目规模扩大后的扩展方案，不进入第一版 MVP。
Worker 负责计算分析并输出结果；哪些结果进入 DataLogger、哪些只保留在 Worker/D1，属于后续结果模型设计，本节不展开。
MongoDB 查询必须有明确时间窗口、项目范围、点位范围和分页限制，禁止无边界扫描。
MongoDB 账号应只读，并限制到插件需要的 collection 和字段。
已确认降级边界：如果 POC 发现 Worker 直连 MongoDB 不稳定，降级为 DataLogger 提供只读历史数据出口；不能把算法塞回 DataLogger，Worker 仍保持唯一节能分析层。

推荐数据流：

text

DataLogger -> MongoDB 保存原始分钟数据
Worker Cron 每 15 分钟轻量分析 / 每天完整分析，或内部手动触发 -> 读取 MongoDB 增量窗口
Worker -> 计算回路快照、能耗聚合、异常事件、建议草稿
Worker -> 写入项目 D1
Worker -> 调 DataLogger recommendation API 提交建议
Worker -> 调 DataLogger API 输出分析结果
UMS -> 从 DataLogger API 查询分析结果、建议和状态
用户接受/拒绝建议 -> DataLogger API 处理
建议被接受 -> DataLogger 创建 Schedule / Rule / Control

不推荐数据流：

text

UMS 页面请求
  -> Worker 直接大范围查询 MongoDB 原始数据
  -> 实时计算所有曲线和报告

原因是原始分钟数据量增长快，大范围查询会增加 MongoDB 压力、Worker 执行时间和接口不稳定性。

建议 D1 数据范围：

第一版基础方案 D1 不保存 circuit_minute_telemetry、point_data 或其他分钟级 point 明细表。分钟级明细查询、重算和异常回溯仍读取 MongoDB；D1 只保存插件派生数据和报告所需的聚合/快照。后续如果启用“最近 1 个月标准化 point 副本”，应新增独立表并明确为分析副本，不改变 DataLogger/MongoDB 的事实源地位。

表	用途
energy_project_config_snapshot	从 DataLogger 拉取的项目级节能配置快照，用于分析追溯，不作为配置主副本
energy_circuit_mapping_snapshot	从 DataLogger 拉取的回路能力配置快照，用于分析追溯，不作为配置主副本
config_version_snapshot	从 DataLogger 同步的配置版本快照、修改摘要和分析使用版本；第一版无发布/审核状态
circuit_snapshot	回路当前分析快照
energy_aggregate_hour	小时级能耗聚合
energy_aggregate_day	日级能耗聚合
baseline_profile	基线期模型
anomaly_event	异常事件
recommendation_trace	插件生成建议的证据、模型输出和 DataLogger 建议 ID 映射
report_snapshot	节能报告快照，保存报告结论、输入窗口和实际使用的 scene profile 版本
recommendation_effect	插件侧效果评估缓存
external_context_cache	天气、日出日落等外部上下文缓存

R2 建议保存：

SceneProfile，第一版只内置 scene-profiles/generic_distribution_box/latest.json；温室、工厂用电、泵站等 profile 后续再加。
Workers AI prompt 模板和输出 schema。
静态参数配置。
报告 PDF/HTML/CSV 导出结果。
大体积历史归档或中间分析文件。

Workers AI 建议用途：

根据历史数据和传感器数据生成建议。
把建议转换成 Schedule / Rule 草稿。
解释异常耗电原因。
生成节能报告摘要。

Workers AI 不建议用途：

不直接控制设备。
不直接创建已生效规则。
不替代 DataLogger 的规则引擎。
不承担电气安全判断。

推荐回写方式：

text

Worker 生成 EnergyRecommendation
  -> 写入插件 D1 的 recommendation_trace
  -> 调 DataLogger recommendation API 提交建议
  -> DataLogger 保存建议并提供接受/拒绝 API
  -> UMS 从 DataLogger 展示建议
  -> 用户在 DataLogger 接受/拒绝
  -> DataLogger 创建 Schedule / Rule / Control

第一版使用“一项目一个 D1 + Worker 后台分析任务 + 静态 D1 binding”的方式验证。Worker 不作为 UMS 或 DataLogger 在线页面查询依赖；项目数量增长后，需要规划 D1 路由方式，例如按项目分组部署 Worker、增加 central registry，或改为项目分片而不是每个项目绑定到同一个 Worker。

7.1.3.3 代码组织

已确认 Worker Energy Plugin 作为独立项目维护，放在 agri_rd 根目录下，不放进 agri_rd/data-logger/DataLogger，也不放进 ums。

已确认目录名为 agri_rd/energy-worker。

已确认第一版使用 TypeScript。TypeScript 的目的不是把系统做复杂，而是约束 D1 row、SceneProfile、节能配置、回路映射、DataLogger client 返回值等边界数据结构，降低后续多场景、多项目扩展时的字段漂移风险。

前面已确认 Hono 作为 Worker 路由框架；在当前“Worker 只主动调用 DataLogger”的边界下，Hono 不再承担业务 API 主入口。第一版如果保留 Hono，只用于健康检查、内部手动触发、调试或后续运维入口；核心分析由 Cron/service 执行，Queue 作为后续扩展。

text

agri_rd/
  energy-worker/
    wrangler.toml
    package.json
    tsconfig.json
    src/
      index.ts
      routes/
      services/
      repositories/
      clients/
      types/
    migrations/
    scene-profiles/
    test/

代码边界：

agri_rd/energy-worker 是独立 Cloudflare Worker 部署单元。
routes/ 第一版只保留健康检查、内部手动触发或调试入口；不提供 UMS/DataLogger 在线业务查询 API。
services/ 负责节能分析、配置快照同步、报告生成、建议生成和结果回写等业务编排。
repositories/ 负责 D1 读写。
clients/ 负责访问 DataLogger API、MongoDB 数据源、天气服务、Workers AI 等外部依赖。
types/ 保存 Worker 内部使用的 TypeScript 类型、DTO、D1 row、SceneProfile schema。
DataLogger 只通过 API 被 Worker 调用，不直接 import Worker 代码。
ums 只通过 DataLogger API 做节能配置和分析展示，不直接调用 Worker，也不直接 import Worker 代码。
已确认 Worker 调用 DataLogger 的基础内部接口使用内部 token 鉴权。第一版不做复杂签名，DataLogger 校验固定内部 token，并限制接口用途。
SceneProfile 源文件可放在 Worker 项目内维护，发布时同步到 R2；运行时以 R2 中的 latest 为准。
D1 migration 放在 Worker 项目内，随 Worker 项目维护。
TypeScript 类型优先在 Worker 项目内部维护；后续如确实需要共享类型，可以单独抽公共 schema 文件，但不能让 Worker、DataLogger、UMS 形成运行时耦合。

Worker 调用 DataLogger 的基础接口第一版应控制在低耦合范围：

获取项目、设备、点位和回路基础信息。
获取点位当前状态、开合状态、电流、电压、有效功率、无效功率、火线端子温度。
获取定时器、规则、操作日志等节能分析需要的上下文。
提交建议草稿，查询建议接受、拒绝、应用状态。
必要时提交动作请求，但真实控制、定时器创建、规则创建仍由 DataLogger 执行。

内部 token 要求：

Worker 请求 DataLogger 时携带固定内部 token。
token 存在 Worker secret 和 DataLogger 服务端环境变量中，不进入 UMS 前端。
DataLogger 对内部 token 接口做最小权限限制，不允许通过该 token 绕过正常用户权限直接控制设备。
token 需要支持人工轮换；后续如果进入规模化部署，可升级为 HMAC 签名或 Cloudflare Access Service Token。

7.1.4 控制链路解耦

智能配电箱电力插件不要直接调用网关，不要绕过现有控制日志。

推荐流程：

text

EnergyRecommendation 被用户确认
  -> 插件通过 DataLogger API 提交动作请求
  -> DataLogger 检查权限和安全边界
  -> DataLogger 创建 Schedule / Rule 或执行点位控制
  -> DataLogger 写 PointOperationLog
  -> 插件记录建议执行结果和节能效果

EnergyActionRequest 建议包含：

字段	说明
recommendation_id	来源建议 ID
circuit_id	目标回路
action	on/off/stop 等
reason	控制原因
expected_saving_kwh	预计节电量，可选
safety_context	安全边界检查结果
dry_run	是否只建议不执行

这样可以保证所有真实控制仍然走现有审计链路。

7.1.5 前端解耦

UMS 不直接实现节能算法，也不直接写 D1，也不直接调用 Worker。UMS 统一调用 DataLogger Energy API；DataLogger 返回项目配置、Worker 输出后的分析结果、建议和执行状态。DataLogger 在线页面请求不调用 Worker，Worker 通过后台任务生产结果并通过 DataLogger API 输出。具体结果表、字段和页面数据粒度后续单独设计，本节不展开。

API	用途
DataLogger `GET /energy/projects/{project_id}/config`	UMS 读取 DataLogger 保存的项目节能配置
DataLogger `PUT /energy/projects/{project_id}/config`	UMS 保存场景、目标、提示词 profile 和安全策略到 DataLogger 项目配置
DataLogger `GET /energy/projects/{project_id}/circuit-mappings`	UMS 读取 DataLogger 保存的回路能力配置
DataLogger `PUT /energy/projects/{project_id}/circuit-mappings`	UMS 保存回路负载类型、传感器映射、允许动作和安全边界到 DataLogger 项目配置
DataLogger `GET /energy/projects/{project_id}/overview`	UMS 查询项目节能分析结果，具体返回字段后续设计
DataLogger `GET /energy/devices/{device_id}/circuits`	UMS 查询设备/回路级节能分析结果，具体返回字段后续设计
DataLogger `GET /energy/circuits/{circuit_id}/summary`	UMS 查询单回路节能分析结果，具体返回字段后续设计
DataLogger `GET /energy/reports`	UMS 查询节能报告，具体快照结构后续设计
DataLogger `GET /recommendations`	建议列表和状态
DataLogger `POST /recommendations/{id}/accept`	接受建议，由 DataLogger 创建 Schedule / Rule / Control
DataLogger `POST /recommendations/{id}/reject`	拒绝建议
DataLogger `GET /recommendations/{id}`	建议详情、证据、应用结果

UMS 页面只关心这些业务对象：

回路
能耗
节能报告
策略
建议
执行记录

不直接关心底层点位如何存储，也不直接拼规则 JSON。

7.1.6 第一阶段落地方式

为了降低改造成本，第一阶段建议：

在 agri_rd 根目录下建立独立 Worker Energy Plugin 项目，作为唯一节能分析层。
UMS 增加节能项目配置页面，配置提交到 DataLogger Energy API；DataLogger 保存为 project 级节能配置，不改现有 AgriDevicePoint、Schedule、Rule 主模型。
Worker 直连 MongoDB 读取原始分钟历史数据，通过 DataLogger API 读取项目、设备、点位、节能配置、当前值、操作日志、定时器和规则。
Worker/D1 保存配置快照、回路映射快照、能耗聚合、基线、异常事件和建议生成 trace。
Worker 通过 DataLogger API 输出分析结果；具体结果表和字段后续单独设计。
DataLogger 后续新增 recommendation API，管理建议保存、接受、拒绝、应用和审计；当前该 API 还没有实现。
用户接受建议后，由 DataLogger 创建 Schedule / Rule / Control。
UMS 新增节能页面：配置保存、分析概览、报告展示、建议列表和接受/拒绝全部调用 DataLogger API。

这样当前架构可以继续运行，节能分析层和 DataLogger 主流程保持解耦。

8. 前端计划：UMS

现有基础：

设备详情、点位列表、点位历史曲线已经存在。
自动化入口已有定时功能。
联动规则已有前端规划，可作为节能策略的基础能力。

建议新增页面和能力：

页面/入口	能力
节能配置	配置场景、用户目标、提示词 profile、回路负载类型、关联传感器、安全边界，提交并保存到 DataLogger 项目配置
设备详情 - 节能概览	优先展示今日/本月用电、节电量、节电率、策略贡献；运行时长和异常回路作为辅助信息
回路详情	聚合显示控制状态、电流、功率、电量、操作日志和策略记录
自动化 - 节能策略	使用向导创建忘关治理、环境联动、错峰运行、超耗提醒
节能报告	支持选择时间范围，对比基线期和优化期，输出 kWh、节电率、策略贡献和可信度说明
策略建议	优先展示预计节电量最高、减少人工最明显的建议，并提供一键确认生成定时或联动规则，减少人工配置
安全设置	配置关键回路、最小运行时间、最小停机时间、人工锁定状态和允许建议动作

UMS 文案上建议避免过度技术化，把策略包装成客户能理解的动作：

“夜间无人时建议关闭照明，用户确认后执行”
“棚内温度低于阈值时减少风机运行”
“自然光充足时缩短补光时长”
“灌溉水泵最长连续运行 2 小时后提醒检查”
“高功率设备错峰启动”

9. 硬件与规格书计划

为了让“省电”成为可靠卖点，Y951 规格书后续应新增“节能版配置”：

9.1 建议型号

text

Y951-xx-C-E
  E: Energy Saving / 节能监测版

也可以不改型号，作为选配包：

基础控制版：远程、定时、联动、运行日志。
节能监测版：增加电流、功率监测，并通过功率积分形成电量统计。
节能优化版：增加策略报告、自动优化、显示屏或本地策略。

9.2 推荐硬件能力

总线电力监测：用于统计整箱总电压、电流、功率、功率因数、累计电量和峰值负荷。
每回路电力监测：当前可监测每个回路的开/合、电流、电压、有效功率、无效功率和火线端子温度，用于分路能耗归因、空转识别、异常负载诊断和安全风险识别。
每回路控制输出：用于远程、定时、联动和节能策略控制。
缺相、欠压、过压、过流保护。
本地控制优先级：手动/停止/自动必须清晰，避免云端误控。
回路状态反馈，避免平台以为已关闭但现场仍在运行。
关键负载支持人工锁定，锁定后策略只提醒不控制。
工控屏：用于本地查看总能耗、回路状态、策略状态、告警和手动/自动模式。

9.3 结合当前硬件的增配判断

如果当前智能配电箱已经具备总线电力监测、每个回路控制和可选工控屏，则第一版节能产品不需要大规模增加硬件。可以按以下优先级处理：

优先级	是否需要新增	硬件项	作用
P0	不新增，复用现有	总线电力监测	统计整箱总耗电、峰值功率、节能前后总量对比
P0	不新增，复用现有	每回路控制	执行远程、定时、联动、错峰和已授权的关闭策略
P0	不新增，复用现有	工控屏	本地展示能耗、运行状态、策略启停和告警
P0	不新增，复用现有	每回路开/合状态	判断回路是否真实运行，避免只知道“命令已下发”
P0	不新增，复用现有	每回路电流、电压、有效功率、无效功率	识别空转、异常负载、分路运行贡献和能耗归因
P0	不新增，复用现有	每回路火线端子温度	识别端子发热、接触不良和安全风险
P2	后续增强	分回路累计电量计量	当前没有累计 kWh；第一版先由有效功率积分计算，后续用于提高报告可信度
P2	视场景新增	环境传感器	支撑温湿度、溶氧、水位、光照等按需启停

产品化建议：

基础节能版：复用总线电力监测和每回路控制，输出整箱总节电量、运行时长和策略记录。
标准节能版：复用每回路开/合、电流、电压、有效功率、无效功率和端子温度，支持空转识别、异常负载、发热风险和分路运行分析。
高级节能版：在标准节能版基础上新增分回路累计电量计量，支持更准确的分路节能报告和策略贡献分析。

关键边界：

只有总线电力监测时，可以证明整箱总耗电变化，但不能严谨证明某一路具体省了多少电。
当前已有每回路开/合、电流、电压、有效功率、无效功率和火线端子温度，已经具备做分路运行诊断和功率积分能耗估算的基础。
当前没有每回路累计电量点位，分路 kWh 需要通过有效功率曲线积分计算，精度取决于采样频率、负载波动、缺失数据和点位校准。
有分回路累计电量时，才能做最强的“回路级节能证明”和策略贡献拆分。

9.4 规格书新增章节

后续可在 Y951 规格书加入：

节能监测功能
节能策略能力
节能数据与报告
节能版选配说明
节能效果说明和适用边界

建议措辞：

在配置电流/功率监测模块并启用智能调度策略的场景下，系统可通过减少无效运行、优化启停时间和识别异常负载，帮助用户降低用电浪费。实际节能效果与现场设备、使用习惯、工况和策略配置有关。

10. MVP 阶段计划

阶段 0：产品验证

目标：确认省电场景是否真实存在。

选择 1~3 个典型客户或内部测试场景。
每个场景至少接入 2~4 路负载。
明确每路负载的额定功率、用途、运行规律和可关闭边界。
开启操作日志和历史数据采集。
记录至少 7~14 天基线数据。

输出：

场景调研表。
回路清单。
节能机会列表。
是否适合承诺 10%~20% 的初步判断。

阶段 1：可视化和估算节能

目标：先把客户看得懂的节电量和省人工闭环做出来。

UMS 增加回路运行时长统计。
支持按每分钟有效功率积分统计 kWh。
展示每日/每月用电、节电量、节电率和策略贡献。
额定功率估算只作为缺少有效功率数据时的兜底口径。
加入忘关提醒和超时运行提醒。
对可优化项生成建议和 Schedule / Rule 草稿，用户确认后由 DataLogger 落地。
将策略控制写入统一操作日志。

输出：

基础节能概览页面。
回路运行日报/月报。
基于功率积分的节能报告。
策略建议列表和一键确认落地流程。

阶段 2：实测能耗闭环

目标：让节能数据可信。

为 Y951 节能版配置并规范电流、电压、有效功率、无效功率和回路状态点位；当前无累计电量点位。
后端增加能耗聚合任务。
支持按回路用有效功率积分统计 kWh。
支持基线期和优化期对比。
UMS 展示节电量、节电率和策略贡献。

输出：

实测节能报告。
回路能耗排行榜。
异常高耗提醒。

阶段 3：策略化节能

目标：让系统主动发现和执行优化机会。

增加节能策略模板。
将策略模板转成定时或联动规则。
加入策略建议、用户确认、执行记录。
增加安全边界配置。
输出每条策略的贡献度。

输出：

节能策略工作台。
策略建议列表。
策略贡献报告。

阶段 4：智能优化

目标：形成高级差异化能力。

基于历史数据识别最佳运行窗口。
结合天气、生产目标或环境目标做优化。
第一版支持建议模式，所有策略需要用户确认后才由 DataLogger 执行。
授权自动采纳作为后续能力；启用前必须可回滚、可暂停、可审计。

输出：

智能节能模式。
月度节能分析。
异常与维护建议。

11. 验证方法

节能验证建议采用“基线期 vs 优化期”：

基线期：不启用节能策略，只记录真实运行；第一版建议 7~14 天，条件允许时使用 30 天。
优化期：启用策略，持续记录；第一版建议 7~14 天，月报使用自然月或连续 30 天。
对比指标：总耗电、单位天耗电、单位业务量耗电、运行时长、峰值功率。
排除因素：设备数量变化、天气剧烈变化、生产规模变化、人工特殊操作。
输出结论：节电量、节电率、可信度、主要贡献策略、异常说明。

不要只用“优化后电量更低”作为证明，必须解释为什么可比。

数据窗口要求：

MongoDB 分钟级原始数据保留 90 天，适合做最近 3 个月内的重算、异常回溯和报告校验。
Worker/D1 聚合数据至少保留 12 个月，支持月报、季度趋势和历史策略效果复盘。
节能报告生成时应保存报告快照，避免 90 天后因原始数据过期无法复现当时结论。

12. 风险与边界

风险	说明	应对
节能效果不稳定	不同现场负载差异大	明确适用场景，不做无条件承诺
只有估算没有实测	缺少有效功率点位或累计电量点位	当前已有有效功率，第一版用功率积分；后续可增加累计电量提高可信度
误关关键设备	自动策略可能影响生产	设置人工锁定、关键回路白名单、安全边界
频繁启停损坏设备	泵、风机、电机不能高频启停	最小运行/停机时间和每日启停次数限制
数据频率不够	1 小时上传无法支撑精细分析	节能点位提高到 1~5 分钟或事件上报
客户不信报告	对比不公平或解释不足	增加基线期、归一化、策略贡献说明

13. 待澄清问题

后续只保留 5 个最高优先级架构问题，按顺序逐个确认。暂不讨论数据表字段、页面字段、省电算法细节和 recommendation API 细节。

已确认：DataLogger 给 Worker 提供标准输入能力，包括项目、设备、点位、当前状态、历史数据窗口、project 节能配置、已有定时器、已有规则和操作日志。
已确认：Worker 输出业务可展示结果到 DataLogger；完整分析过程和 trace 留在 D1。不展开结果表结构和字段。
已确认：Worker 输出结构化建议草稿；DataLogger 保存、展示、接受、拒绝，并在用户接受后承接 Schedule/Rule/Control。不展开 recommendation API 细节。
已确认：第一版优先 Worker 直连 MongoDB；如果 POC 失败，降级为 DataLogger 提供只读历史数据出口，Worker 仍是分析层。
已确认：第一版 MVP 验收标准为“技术链路 + 建议闭环 + 节电复盘”跑通。选择一个试点项目，完成基线期、优化期、建议生成、用户确认、DataLogger 落地和节电量复盘；节电率记录但不作为硬门槛。

14. 建议下一步

建议下一轮先做产品验证，而不是马上开发完整节能系统：

选定一个实际试点项目，可以是温室、工厂用电、泵站或其他智能配电箱项目。
在 UMS 完成项目配置、选择 scene profile、配置回路能力和传感器映射，并保存到 DataLogger 项目配置。
定义 4 路回路模板：控制点、状态点、电流点、有效功率点、无效功率点、火线端子温度点。
采集 7~14 天基线数据。
Worker 跑通每 15 分钟轻量分析和每天 1 次完整分析，输出业务可展示结果到 DataLogger。
Worker 生成结构化建议草稿，并通过 DataLogger recommendation API 提交。
用户在 DataLogger/UMS 中确认建议，由 DataLogger 承接 Schedule / Rule / Control。
进入优化期后复盘节电量、建议贡献和可信度。
再根据试点结果反推 DataLogger、UMS 和 Worker 的 MVP 开发范围。

这个路径能避免一开始做太重的 AI/算法，同时验证“能分析、能给建议、能落地、能复盘节电量”。节电率可以记录，但第一版不把 10%~20% 作为硬验收。

Y951 智能配电箱省电产品化计划 ​

1. 方向判断 ​

2. 产品定位 ​

3. 多场景 Profile 架构 ​

4. 节能能力分层 ​

4.1 基础版：运行时长节能 ​

4.2 标准版：电流/功率实测节能 ​

4.3 高级版：智能策略节能 ​

5. 数据闭环设计 ​

5.1 必要数据 ​

5.2 数据频率 ​

5.3 云端计算架构可行性 ​

5.4 能耗计算方式 ​

6. 策略方向 ​

6.0 真实省电机制 ​

6.0.1 结合传感器和第三方数据 ​

6.1 第一版只做一个简单通用策略模板 ​

6.2 再做建议型智能优化 ​

6.3 后续做授权自动采纳 ​

6.4 AI 的定位 ​

6.4.1 AI 建议类型 ​

7. 后端计划：DataLogger ​

7.1 解耦架构设计 ​

7.1.1 Worker 插件不直接理解原始点位 ​

7.1.2 标准化遥测事件 ​

7.1.2.1 标准化外部上下文 ​

7.1.3 Worker 插件内部模块 ​

7.1.3.1 智能配电箱电力插件 ​

7.1.3.2 Cloudflare Worker 部署形态 ​

7.1.3.3 代码组织 ​

7.1.4 控制链路解耦 ​

7.1.5 前端解耦 ​

7.1.6 第一阶段落地方式 ​

8. 前端计划：UMS ​

9. 硬件与规格书计划 ​

9.1 建议型号 ​

9.2 推荐硬件能力 ​

9.3 结合当前硬件的增配判断 ​

9.4 规格书新增章节 ​

10. MVP 阶段计划 ​

阶段 0：产品验证 ​

阶段 1：可视化和估算节能 ​

阶段 2：实测能耗闭环 ​

阶段 3：策略化节能 ​

阶段 4：智能优化 ​

11. 验证方法 ​

12. 风险与边界 ​

13. 待澄清问题 ​

14. 建议下一步 ​

Y951 智能配电箱省电产品化计划

1. 方向判断

2. 产品定位

3. 多场景 Profile 架构

4. 节能能力分层

4.1 基础版：运行时长节能

4.2 标准版：电流/功率实测节能

4.3 高级版：智能策略节能

5. 数据闭环设计

5.1 必要数据

5.2 数据频率

5.3 云端计算架构可行性

5.4 能耗计算方式

6. 策略方向

6.0 真实省电机制

6.0.1 结合传感器和第三方数据

6.1 第一版只做一个简单通用策略模板

6.2 再做建议型智能优化

6.3 后续做授权自动采纳

6.4 AI 的定位

6.4.1 AI 建议类型

7. 后端计划：DataLogger

7.1 解耦架构设计

7.1.1 Worker 插件不直接理解原始点位

7.1.2 标准化遥测事件

7.1.2.1 标准化外部上下文

7.1.3 Worker 插件内部模块

7.1.3.1 智能配电箱电力插件

7.1.3.2 Cloudflare Worker 部署形态

7.1.3.3 代码组织

7.1.4 控制链路解耦

7.1.5 前端解耦

7.1.6 第一阶段落地方式

8. 前端计划：UMS

9. 硬件与规格书计划

9.1 建议型号

9.2 推荐硬件能力

9.3 结合当前硬件的增配判断

9.4 规格书新增章节

10. MVP 阶段计划

阶段 0：产品验证

阶段 1：可视化和估算节能

阶段 2：实测能耗闭环

阶段 3：策略化节能

阶段 4：智能优化

11. 验证方法

12. 风险与边界

13. 待澄清问题

14. 建议下一步