点一下 3D 场景里的电表，就能展开对应读数和趋势。这个效果很直观，但做能耗系统时，真正费功夫的是后面的几件事：图上点中的究竟是哪块表，曲线用了什么字段，总表和分表有没有重复统计。
这篇结合联犀能源应用的现有前端实现与历史演示，分享统计口径、分时费用、场景绑定和 AI 查询的处理方法。画面用于说明交互，不作为客户现场数据或节能成绩。
2026-09-14 建筑数字孪生交付演示：展开楼层，选择空间与系统，查看对应读数。
先把功率、累计读数和用电量分开
拿到电表数据后，先别急着画曲线。同样是一个数，字段含义不同，聚合方式就不同。
现有能源前端使用的电表字段包括：
| 字段 | 含义 |
|---|---|
P | 有功功率，单位 kW |
TotalEnergy | 累计电能读数，单位 kWh |
TotalEnergyChange | 电能变化量，单位 kWh |
TotalEnergyRate1～4 | 分费率累计电能 |
功率按窗口查看均值、最大值和最小值；用电量汇总所选范围的增量。累计读数不能直接相加，分费率读数则分别计算期间变化量，再匹配对应费率。
数据监控页按小时查询。下面是代码中聚合请求的核心参数，省略了日期、设备品类和区域筛选，并非完整 API 调用：
{
interval: 1,
intervalUnit: 'h',
aggs: [
{
dataID: 'P',
argFuncs: ['avg', 'max', 'min'],
noFirstTs: true
},
{
dataID: 'TotalEnergyChange',
argFuncs: ['sum'],
noFirstTs: true
}
]
}
这样，一小时的功率变化和这一小时的用电量可以放在同一张图里，分别使用 kW 与 kWh 坐标轴。缺失值保留为空，曲线使用 connectNulls: false，让断点显露出来。
缺记录和用电量为零，是两种状态。 把缺测补成零，图看起来连续了，后面的排名、对比和异常判断却可能一起跑偏。
2026-09-11 历史演示界面：区域排名、设备用电分布和告警记录；不代表客户经营数据。
排名也要先统一范围。比较两栋楼时，统计周期、计量覆盖和记录完整性应一致；面积、运行时长和产量不同，用量排名只能提供核查线索，不能直接当作能效排名。
分时费用，从累计读数算起
复费率报表查询四个费率字段的 first 和 last，再按配置中的费率计算费用。其核心计算可以概括为：
某费率期间电量 = 该费率累计读数末值 - 首值
某费率电量费用 = 期间电量 × 对应单价
分时电量费用合计 = 各费率电量费用之和
查询同一期间的首末记录，避免把每次上报的累计数值直接加起来。报表中的费率名称和价格读取配置，不能只凭“Rate1”这个名字推断现场一定采用哪种计费约定。
费用计算示意，不包含实测金额；基本电费等账单项目需另行核对。
这里有两个实现边界值得单独检查。
第一，首末记录不一定恰好落在周期边界。 查询区间内有记录，不等于覆盖了整个期间；若拿报表对账，还要检查采样时点与完整性。
第二，负差值不能直接当作负用电量。 当前报表计算用 Math.max(lastValue - firstValue, 0) 将负差钳制为零，但这一步不能还原电表清零、换表或回卷前后的真实用量。遇到这些情况，仍需核查采集记录与设备维护记录，不能因为页面显示零就认为没有用电。
报表算出来的是所配置费率下的电量费用。是否能与供电账单对应，还要看费率适用时间、基本电费和其他计费项目。
总分表的差额，先查边界
区域层级和计量层级很容易混在一起：一层楼有几块表，是空间关系；总进线表覆盖哪些分表，是计量关系。同一个区域里的表，不一定能直接相加。
计量关系示意：总表已覆盖的用量，不能再与下级分表重复累计。
比较总分表时，可以先写清计算范围：
待核查差额 = 同期总表用量 - 同期已纳入范围的分表用量合计
这个差额只是待核查量。把它直接标成设备损耗，会掩盖共用负荷未装分表、漏采、时点不齐或计量范围配置错误等问题。
实际核查时，先确认总分表关系，再对齐时间范围，最后查看记录缺口。尤其要排除总表与分表重复汇总，否则图表做得再漂亮，统计结果也没有解释力。
3D 场景绑定，要落到设备和字段
建筑模型帮助找位置，设备身份决定查谁的数据。把这两件事连起来，点击电表才有实际意义。
2026-09-14 配电站交付演示节选：点选电表，展开对应读数与趋势。
制作这类交互时，建议把下面的对应关系单独核对。这是绑定检查项，并非平台接口的字段定义：
| 对应关系 | 核对内容 |
|---|---|
| 场景对象 → 电表 | 图上的表与后台设备身份是否一致 |
| 电表 → 物模型字段 | 当前展示的是电压、功率还是累计电能 |
| 字段 → 展示 | 单位、更新时间和历史查询范围是否一致 |
| 查询 → 状态 | 无数据、无权限、查询失败能否分清 |
先选一块身份已确认的电表，核对读数、单位和时间，再批量配置其他点位。业务上同属“空调用电”的设备，未必位于同一排柜体；区域名称不能代替现场位置。
点击后没有数据，也可以顺着这条链检查：后台是否有近期上报，图中绑定的是不是这台设备，查询字段和权限是否正确。这样排查，比反复调整模型和界面更直接。
AI 查询，保留对象、字段和来源
自然语言适合表达需求，但真正查询设备历史时，仍要把对象、字段和时间范围确定下来。例如这条请求示例：
查询这块电表今天 8 点到 10 点的电压，返回曲线与明细，注明设备和记录时间；没有记录的时段单独说明。
2026-09-16 AI 工作台测试界面：展示电压查询结果、记录时间及明细入口。该图与上方请求示例不是同一次查询。
这里需要核对的不是回答是否流畅，而是查询有没有落到正确设备、是否使用电压字段、时间范围是否一致，以及曲线能否继续查看明细。
查不到记录，就保留“查不到”这个结果。不能让 AI 根据相邻时段补出测量值，也不能把一个设备查询结果扩写成整栋楼的节能结论。涉及电费上涨或故障原因，还需要结合运行安排、费率和现场状态判断。
告警也沿用相同原则：阈值与通知规则先确认，再在测试环境验证触发、通知和处理记录。AI 可以参与已配置的判断流程，现场保护与设备控制仍有各自的执行边界。
从一条能核对的数据链开始
做这类系统，可以先挑一块电表和一个小时窗口，把原始记录、聚合结果、图表与 3D 点位逐项对上，再扩展到多表、分时费用和 AI 查询。
我们觉得最值得打磨的地方就在这里：点得准、算得清、查得到依据。 这些细节做好了，数字孪生和 AI 才能接进日常工作。
欢迎关注我们的开源项目
联犀 things · Go 物联网开源模块
提供设备接入、物模型、设备数据与 OTA 等基础能力；本文的能源界面与 3D 应用属于配套平台，不代表克隆该仓库即可获得完整应用。
欢迎交流实现思路，也欢迎关注联犀，持续分享 AI＋物联网的开发进展与开源实践。
