Home Assistant 报表生成与历史数据统计如何把用电、温湿度变成看得懂的报表【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core月底电费账单跳涨 80 块你却说不清是空调、烘干机还是那台跑了一整月的矿……不对NAS 干的。这就是 Home Assistant 历史数据统计要解决的问题它把你家的传感器、智能插座状态持续存进数据库再按 5 分钟和小时两级自动聚合成统计报表你随时能查、能导、能画。先跑通三步拿到第一张历史曲线想看到数据只需要确认三件事Recorder状态记录器负责把设备状态写进数据库在跑、你要查的实体没被排除、你手里有一个长期访问令牌。第一步确认 Recorder 已启用。默认配置下它写入 SQLite什么都不用改。想换库或调保留期在configuration.yaml里加recorder: db_url: mysql://hass:secretdb-server/homeassistant?charsetutf8mb4 purge_keep_days: 90 # 原始状态默认只留 10 天这里延长到 90 exclude: entity_globs: - sensor.*_rssi # 这类噪音数据不记录第二步用 REST 接口拉一段历史。把令牌、时间范围和实体 ID 填进去curl -H Authorization: Bearer 你的长期令牌 \ http://homeassistant.local:8123/api/history/period/2026-08-01T00:00:00Z?end_time2026-08-29T00:00:00Zfilter_entity_idutility_meter.energy_gridminimal_responsetrue返回的是按实体分组的 JSON每个条目含state、属性、last_updated。想看完整状态属性就去掉minimal_response。第三步在 Lovelace 仪表板放一个 History 卡片指向同一个实体——它底层走的是同一套历史查询。到这里你已经有了原始流水。原理拆解三层数据是怎么叠起来的Home Assistant 的历史数据不是一张大表而是三层流水账层存什么谁写典型用途states 表每次状态变化的原始记录Recorder精确回溯几点几分发生了什么history 查询层对 states 的显著变化筛选与压缩History 组件前端曲线、REST/WS 查询statistics 表5 分钟/小时两级聚合值均值、极值、求和Recorder 定时任务能源账单、月度对比等报表第一层是流水账设备每报一次新值就落一行。第二层做减法——只保留显著变化状态值本身变了才算仅属性更新会被过滤这就是你查曲线时不会看到一堆重复点的原因核心实现在 history 组件 的get_significant_states。第三层是真正的报表。两个定时任务在后台轮转每到 5 分钟边界把该区间内的状态压成一行均值、最大、最小对能源这类只增不减的计量实体额外算 sum整点时再对 4 个 5 分钟行做二次聚合落一行小时统计。入口函数是 recorder 统计源码 里的compile_statistics跑完会发出recorder.statistics_short_term_generated和recorder.statistics_hourly_generated事件你可以拿这两个事件当报表新鲜出炉的触发器。一句话记忆states 是流水history 是筛选过的流水statistics 是账本。电费这种累计值问题只有账本层能直接答。实战用例从查询到图表用 WebSocket 查统计适合仪表板实时刷新。前端和脚本都可以复用同一通道。连接ws://homeassistant.local:8123/api/websocket后先认证再发const sock new WebSocket(ws://homeassistant.local:8123/api/websocket); sock.onopen () { sock.send(JSON.stringify({ id: 1, type: auth, access_token: 你的长期令牌 })); }; sock.onmessage (e) { const r JSON.parse(e.data); if (r.id 1 r.type auth_ok) { // 拉最近 30 天的小时级统计报表数据一次到位 sock.send(JSON.stringify({ id: 2, type: recorder/get_statistics_during_period, start_time: new Date(Date.now() - 30 * 864e5).toISOString(), statistic_ids: [utility_meter.energy_grid], period_type: hour })); } else if (r.id 2 r.success) { renderChart(r.result.statistics); // 每行含 start, mean, sum, max, min } };用 REST 导出 CSV适合月度复盘。把上一条 curl 的结果喂给任何脚本都行end_time和filter_entity_id都是可选项不传时间默认取最近一天。画一张小时 × 日期热力图。拿到导出数据后按日期、小时透视一下用任意绘图库Matplotlib 或前端 ECharts渲染行是日期、列是 0–23 时、颜色深浅代表该小时用电 sum。哪一周、哪个时段在偷偷耗电一眼可见。这比逐日看柱状图快得多也更容易发现周三晚 21 点必有峰值这种规律。避坑清单曲线断点、查不到数据→ 该实体被exclude或全局排除规则挡掉了或原始数据已被purge_keep_days清掉 → 检查 Recorder 排除项关键计量实体单独保留并确认查询时间范围没超出保留期。5 分钟统计缺行→ 缺行多发生在 HA 停机跨越统计边界时重启后会触发回填 → 若长期缺行看日志中 statistics 相关报错能源实体缺行会直接让 sum 偏低建议对recorder.statistics_short_term_generated事件做监控。同一实体在报表里单位跳变比如 ℃ 变 ℉→ 统计元数据记录了首次登记时的单位 → 实体单位变更后需让 Recorder 重建该统计元数据修复任务会自动提示手动核对 statistics_meta。查询慢、前端卡顿→ 时间范围过大 返回完整属性 → 缩短窗口、加minimal_response、用filter_entity_id收窄实体MySQL 环境下确认start_time过滤走了索引。MySQL 部署连接不稳→ SQLite 之外换库后要设连接池参数并关注日志 → 数据量大时建议独立数据库实例别和主库挤在一起。收尾到这里你手里已经有了三层数据流水、筛选流水、聚合账本和三把钥匙REST、WebSocket、脚本导出。Home Assistant 的报表能力本质上是先记账、后对账把原始状态留足、让两级聚合去跑你要的月度电费对比、温度波动分析就只是换一种查询而已。延伸方向把小时统计接进自动化比如连续 3 天同时段峰值超阈值就发通知让报表从回看变成预警。【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Home Assistant 报表生成与历史数据统计如何把用电、温湿度变成看得懂的报表【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core月底电费账单跳涨 80 块你却说不清是空调、烘干机还是那台跑了一整月的矿……不对NAS 干的。这就是 Home Assistant 历史数据统计要解决的问题它把你家的传感器、智能插座状态持续存进数据库再按 5 分钟和小时两级自动聚合成统计报表你随时能查、能导、能画。先跑通三步拿到第一张历史曲线想看到数据只需要确认三件事Recorder状态记录器负责把设备状态写进数据库在跑、你要查的实体没被排除、你手里有一个长期访问令牌。第一步确认 Recorder 已启用。默认配置下它写入 SQLite什么都不用改。想换库或调保留期在configuration.yaml里加recorder: db_url: mysql://hass:secretdb-server/homeassistant?charsetutf8mb4 purge_keep_days: 90 # 原始状态默认只留 10 天这里延长到 90 exclude: entity_globs: - sensor.*_rssi # 这类噪音数据不记录第二步用 REST 接口拉一段历史。把令牌、时间范围和实体 ID 填进去curl -H Authorization: Bearer 你的长期令牌 \ http://homeassistant.local:8123/api/history/period/2026-08-01T00:00:00Z?end_time2026-08-29T00:00:00Zfilter_entity_idutility_meter.energy_gridminimal_responsetrue返回的是按实体分组的 JSON每个条目含state、属性、last_updated。想看完整状态属性就去掉minimal_response。第三步在 Lovelace 仪表板放一个 History 卡片指向同一个实体——它底层走的是同一套历史查询。到这里你已经有了原始流水。原理拆解三层数据是怎么叠起来的Home Assistant 的历史数据不是一张大表而是三层流水账层存什么谁写典型用途states 表每次状态变化的原始记录Recorder精确回溯几点几分发生了什么history 查询层对 states 的显著变化筛选与压缩History 组件前端曲线、REST/WS 查询statistics 表5 分钟/小时两级聚合值均值、极值、求和Recorder 定时任务能源账单、月度对比等报表第一层是流水账设备每报一次新值就落一行。第二层做减法——只保留显著变化状态值本身变了才算仅属性更新会被过滤这就是你查曲线时不会看到一堆重复点的原因核心实现在 history 组件 的get_significant_states。第三层是真正的报表。两个定时任务在后台轮转每到 5 分钟边界把该区间内的状态压成一行均值、最大、最小对能源这类只增不减的计量实体额外算 sum整点时再对 4 个 5 分钟行做二次聚合落一行小时统计。入口函数是 recorder 统计源码 里的compile_statistics跑完会发出recorder.statistics_short_term_generated和recorder.statistics_hourly_generated事件你可以拿这两个事件当报表新鲜出炉的触发器。一句话记忆states 是流水history 是筛选过的流水statistics 是账本。电费这种累计值问题只有账本层能直接答。实战用例从查询到图表用 WebSocket 查统计适合仪表板实时刷新。前端和脚本都可以复用同一通道。连接ws://homeassistant.local:8123/api/websocket后先认证再发const sock new WebSocket(ws://homeassistant.local:8123/api/websocket); sock.onopen () { sock.send(JSON.stringify({ id: 1, type: auth, access_token: 你的长期令牌 })); }; sock.onmessage (e) { const r JSON.parse(e.data); if (r.id 1 r.type auth_ok) { // 拉最近 30 天的小时级统计报表数据一次到位 sock.send(JSON.stringify({ id: 2, type: recorder/get_statistics_during_period, start_time: new Date(Date.now() - 30 * 864e5).toISOString(), statistic_ids: [utility_meter.energy_grid], period_type: hour })); } else if (r.id 2 r.success) { renderChart(r.result.statistics); // 每行含 start, mean, sum, max, min } };用 REST 导出 CSV适合月度复盘。把上一条 curl 的结果喂给任何脚本都行end_time和filter_entity_id都是可选项不传时间默认取最近一天。画一张小时 × 日期热力图。拿到导出数据后按日期、小时透视一下用任意绘图库Matplotlib 或前端 ECharts渲染行是日期、列是 0–23 时、颜色深浅代表该小时用电 sum。哪一周、哪个时段在偷偷耗电一眼可见。这比逐日看柱状图快得多也更容易发现周三晚 21 点必有峰值这种规律。避坑清单曲线断点、查不到数据→ 该实体被exclude或全局排除规则挡掉了或原始数据已被purge_keep_days清掉 → 检查 Recorder 排除项关键计量实体单独保留并确认查询时间范围没超出保留期。5 分钟统计缺行→ 缺行多发生在 HA 停机跨越统计边界时重启后会触发回填 → 若长期缺行看日志中 statistics 相关报错能源实体缺行会直接让 sum 偏低建议对recorder.statistics_short_term_generated事件做监控。同一实体在报表里单位跳变比如 ℃ 变 ℉→ 统计元数据记录了首次登记时的单位 → 实体单位变更后需让 Recorder 重建该统计元数据修复任务会自动提示手动核对 statistics_meta。查询慢、前端卡顿→ 时间范围过大 返回完整属性 → 缩短窗口、加minimal_response、用filter_entity_id收窄实体MySQL 环境下确认start_time过滤走了索引。MySQL 部署连接不稳→ SQLite 之外换库后要设连接池参数并关注日志 → 数据量大时建议独立数据库实例别和主库挤在一起。收尾到这里你手里已经有了三层数据流水、筛选流水、聚合账本和三把钥匙REST、WebSocket、脚本导出。Home Assistant 的报表能力本质上是先记账、后对账把原始状态留足、让两级聚合去跑你要的月度电费对比、温度波动分析就只是换一种查询而已。延伸方向把小时统计接进自动化比如连续 3 天同时段峰值超阈值就发通知让报表从回看变成预警。【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
