TeslaMate电池健康仪表盘对LFP电池容量计算存在误差问题分析
2025-06-02 23:10:56作者:段琳惟
问题背景
TeslaMate作为一款开源的Tesla车辆数据记录工具,其电池健康仪表盘功能在v1.29.2版本中对锂铁磷酸盐(LFP)电池的容量计算存在明显偏差。这一问题源于系统错误地将适用于镍钴锰(NCM)三元锂电池的计算公式应用到了LFP电池上,导致显示的"可用容量(新)"和"当前可用容量"数据不准确。
技术细节分析
当前错误实现
系统当前对所有电池类型统一使用以下SQL查询计算当前容量:
SELECT AVG(Capacity) AS Capacity
FROM (
SELECT
c.[[preferred_range]]_battery_range_km * aux.efficiency / c.usable_battery_level AS Capacity
FROM charging_processes cp
INNER JOIN charges c ON c.charging_process_id = cp.id
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
AND cp.charge_energy_added >= aux.efficiency
AND c.usable_battery_level > 0
ORDER BY cp.end_date DESC LIMIT 10
) AS lastCharges
这种计算方式基于电池的预估里程和效率参数,适用于NCM电池,但对LFP电池会产生较大误差。
正确的LFP电池计算方法
对于LFP电池,应采用基于充电能量变化的计算方法:
SELECT AVG(Capacity) AS CurrentCapacity
FROM (
SELECT (100.0 * cp.charge_energy_added) /
(GREATEST(1,MAX(usable_battery_level) - MIN(usable_battery_level))) AS Capacity
FROM charging_processes cp
INNER JOIN charges c ON cp.id = c.charging_process_id
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.charge_energy_added >= aux.rated_efficiency
AND cp.end_date >= date_trunc('month', current_date - interval '1 month')
GROUP BY cp.charge_energy_added, cp.end_date
) AS lastEstimatedCapacity
这种方法通过计算充电过程中实际能量增加与电池百分比变化的比值来估算容量,更适合LFP电池的特性。
最大容量计算差异
同样的问题也存在于最大容量计算中:
当前LFP电池的最大容量计算
SELECT MAX(c.rated_battery_range_km * cars.efficiency * 100.0 / c.usable_battery_level) AS MaxCapacity
FROM charging_processes cp
JOIN (SELECT charging_process_id, MAX(date) as date
FROM charges
GROUP BY charging_process_id) AS last_charges
ON cp.id = last_charges.charging_process_id
INNER JOIN charges c
ON c.charging_process_id = cp.id AND c.date = last_charges.date
INNER JOIN cars ON cp.car_id = cars.id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
AND cp.end_rated_range_km > cp.start_rated_range_km
AND c.charge_energy_added >= cars.Efficiency
NCM电池的最大容量计算
SELECT
MAX(c.[[preferred_range]]_battery_range_km * aux.efficiency / c.usable_battery_level) AS Capacity
FROM charging_processes cp
INNER JOIN (
SELECT charging_process_id, MAX(date) as date FROM charges WHERE usable_battery_level > 0 GROUP BY charging_process_id
) AS gcharges ON cp.id = gcharges.charging_process_id
INNER JOIN charges c
ON c.charging_process_id = cp.id AND c.date = gcharges.date
INNER JOIN aux ON cp.car_id = aux.car_id
WHERE cp.car_id = $car_id
AND cp.end_date IS NOT NULL
问题影响
这种计算方法的错误会导致:
- LFP电池的健康状态显示不准确
- 用户无法正确评估电池的实际衰减情况
- 可能影响用户对车辆维护和使用的决策
解决方案建议
TeslaMate应针对不同电池类型实现差异化的计算逻辑:
- 增加电池类型检测机制
- 对LFP电池采用基于充电能量变化的计算方法
- 对NCM电池保留现有的里程估算方法
- 在UI上明确标注不同电池类型的计算方式差异
这种改进将确保所有Tesla车主都能获得准确的电池健康数据,无论其车辆配备的是LFP还是NCM电池。
登录后查看全文
热门项目推荐
相关项目推荐
kernelopenEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。C051
MiniMax-M2.1从多语言软件开发自动化到复杂多步骤办公流程执行,MiniMax-M2.1 助力开发者构建下一代自主应用——全程保持完全透明、可控且易于获取。Python00
kylin-wayland-compositorkylin-wayland-compositor或kylin-wlcom(以下简称kywc)是一个基于wlroots编写的wayland合成器。 目前积极开发中,并作为默认显示服务器随openKylin系统发布。 该项目使用开源协议GPL-1.0-or-later,项目中来源于其他开源项目的文件或代码片段遵守原开源协议要求。C01
PaddleOCR-VLPaddleOCR-VL 是一款顶尖且资源高效的文档解析专用模型。其核心组件为 PaddleOCR-VL-0.9B,这是一款精简却功能强大的视觉语言模型(VLM)。该模型融合了 NaViT 风格的动态分辨率视觉编码器与 ERNIE-4.5-0.3B 语言模型,可实现精准的元素识别。Python00
GLM-4.7GLM-4.7上线并开源。新版本面向Coding场景强化了编码能力、长程任务规划与工具协同,并在多项主流公开基准测试中取得开源模型中的领先表现。 目前,GLM-4.7已通过BigModel.cn提供API,并在z.ai全栈开发模式中上线Skills模块,支持多模态任务的统一规划与协作。Jinja00
agent-studioopenJiuwen agent-studio提供零码、低码可视化开发和工作流编排,模型、知识库、插件等各资源管理能力TSX0126
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00
项目优选
收起
deepin linux kernel
C
26
10
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
445
3.35 K
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
823
398
Ascend Extension for PyTorch
Python
250
285
暂无简介
Dart
702
166
React Native鸿蒙化仓库
JavaScript
278
329
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
10
1
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.24 K
679
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
142
51
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
65
19