TeslaLogger

TeslaLogger 深度剖析：把行车数据从云端夺回自己的树莓派

项目背景与痛点

特斯拉官方 App 提供的历史数据是有"保质期"的——几个月之后，你的充电记录、行程明细会悄无声息地消失。对于一个把车当作长期资产的用户来说，这意味着无法回答几个真正重要的问题：电池三年衰减了多少？冬天热泵到底省不省电？每次静置一夜，车自己掉了多少续航？充电桩的实际充电效率是否达标？

SaaS 类第三方记录服务能解决一部分，但代价是把 GPS 轨迹、家庭住址、每日作息全部托管到别人的服务器上。对一部分开发者来说，这不是一个可以接受的交换。

TeslaLogger 的定位非常清晰：一个可自托管的单体数据记录器。一个 .NET 程序 + 一个内嵌 Web 界面，扔到 Raspberry Pi 3B/4B、Docker 或群晖 NAS 上就能跑，数据库、图表、通知全部自己掌握。

而它面对的真正技术难题，是所有特斯拉第三方工具共同的梦魇——观察者效应。特斯拉车辆在静置一段时间后会进入深度休眠以节省电量，此时云端 API 无法触达；而每一次 API 轮询都可能把车"叫醒"，唤醒本身又会产生额外耗电。你的记录行为，正在污染你要测量的数据。这是 TeslaLogger 整个架构设计的核心约束。

核心技术揭秘

技术栈上，TeslaLogger 选择了 C#（早期依赖 Mono 跨平台，后迁移到现代 .NET），数据落地到 MySQL，前端不引入任何构建工具链——纯静态 HTML + JavaScript + Canvas 绘图，由程序内嵌的轻量 HTTP 服务器直接吐出。这种"反现代前端"的取舍换来了极低的部署门槛：没有 Node、没有 npm、没有容器编排，一个可执行文件就是全部。

真正的复杂性藏在调度层。程序维护一个长期轮询循环，并根据车辆状态动态调整采样频率，而不是无脑定时拉取：

状态机的输入是 API 返回的 state 字段，加上 speed、charger_power 等信号交叉推导，最终收敛到 online / asleep / offline / charging / driving 几个稳定态。休眠态是唯一不会触发主动唤醒的分支——程序转而用"最后一条有效数据的时刻"来估算入睡时间点，用前后两次采样之间的电量差反推静置损耗率。这套"以退为进"的策略，是它相比高频轮询方案最大的工程价值。

行程（Trip）与充电会话的切分则依赖启发式规则：位置跳变超过阈值、采样间隔长时间断档、状态从 driving 迁移到 online，这些信号组合起来判定一段行程的起止点；充电会话则靠 charger_power > 0 的时间窗口做聚合，并剔除短暂的中断抖动。这类算法没有标准答案，本质是工程经验的沉淀，也是同类项目分道扬镳的地方。

功能亮点与差异

和知名度更高的 TeslaMate 相比，TeslaLogger 走的是完全相反的路线。TeslaMate 是 Elixir + PostgreSQL + Grafana 的"三件套"，架构现代、扩展性强，但部署复杂度也高一个量级。TeslaLogger 则是全内置：图表自带、通知自带、配置靠一个 Windows GUI 工具生成，用户不需要理解任何编排概念。

几个值得点名的设计：

• ABRP 实时对接：行驶中把 SOC、位置、能耗实时推给 A Better Route Planner，让规划算法吃到真实车况，这是很多记录器没有做的闭环。
• MQTT 发布：把车辆状态喂给 Home Assistant，可以直接触发"到家自动开充电桩"这类自动化。
• 地理围栏与 POI 识别：靠坐标距离计算判断"是否在家/在公司"，从而决定要不要在特定地点做额外采样。
• 多车支持与 CSV 导出：数据不是被锁死在图表里，MySQL 表结构相对直白，想自己跑 SQL 做二次分析完全可行。

配置方式是个容易被忽略的差异点：它不追求"配置文件即代码"的时髦范式，而是提供图形化配置器。对目标用户群——懂点技术但不一定想读文档的车主——这反而是更友好的选择。

应用场景与落地建议

它最适合的场景是：家里有常年开机的 NAS 或树莓派，车主愿意投入半天时间做初始配置，并打算持有这辆车三年以上。长期数据留存对电池健康评估的价值，随时间线性增长。

落地时有几个坑必须提前想到：

不要让 Web 界面裸奔在公网。 内嵌服务器的鉴权机制相对简单，正确做法是套一层 Nginx/Caddy 反代，加 HTTPS 和 Basic Auth，或者干脆只在内网访问，靠 VPN 回家。

数据库别落在 SD 卡上。 MySQL 的写入频率和树莓派 SD 卡的寿命是天然冲突的，把数据目录挂到 SSD 或 NAS 存储卷上是基本操作。同时配置定期 mysqldump 备份——它是自托管的，没有第二份副本。

OAuth 令牌是脆弱点。 特斯拉的 API 体系近年多次变动，令牌刷新失败会导致程序静默停摆。建议对进程做存活监控，并把日志里的认证错误纳入告警。

别指望它做实时告警。 轮询模型天生不适合"车被撞了立刻通知"这类场景，那是官方 App 和哨兵模式的活儿。

综合评价

优点：部署极简、数据主权完整、图表开箱即用、对车辆休眠的克制处理体现了对真实工程约束的理解、MySQL + CSV 的出口保证了数据不会被锁死。

缺点：代码结构带有明显的"个人工程"痕迹，模块边界不够清晰，缺少正式测试套件；前端界面停留在十年前的技术审美；文档主要服务于德语社区，英文资料零散；每当特斯拉调整 API 或认证流程，项目就会经历一段脆性期，社区需要等作者适配。

一句话总结：TeslaLogger 不是最优雅的实现，但它是在"我想自己掌控数据"这个诉求下，性价比最高、心智负担最小的那一类工具。它证明了一件事——在云服务唾手可得的年代，一个结构朴素的单体程序，依然可以是解决特定问题的最优解，前提是作者真正理解了他所操作的那个物理世界。