TeslaMate
๐ก Quick Navigation
TeslaMate is the service I use to preserve long-term Tesla vehicle data. The official app is good for checking current state, but it is not designed for long-term analysis. TeslaMate keeps trips, charging sessions, efficiency, and state changes so I can review how the car is actually used over time.
This kind of service is different from normal Home Lab tools because it stores highly personal behavior data. Vehicle telemetry can reveal routines, commute patterns, frequently visited places, charging habits, and even likely home or work locations. Because of that, this public note documents architecture and operations principles only. It does not publish real dashboards or full configuration details.
Important
This is a public note, so it intentionally does not include real domains, internal addresses, ports, Tesla account details, tokens, encryption keys, database passwords, VIN, license plate, vehicle name, home/work locations, GPS coordinates, charging locations, trip screenshots, or Grafana dashboard screenshots.
๐ฏ Why I Use It
The official app shows now; TeslaMate shows history
The Tesla app is useful for answering questions like โwhere is the car now, what is the battery level, and is it charging?โ What I want from TeslaMate is longer-term context:
- How many miles are driven each month
- How commute and road-trip efficiency differ
- The balance between home charging and external charging
- How weather, speed, and route affect efficiency
- Whether long-term battery trends show meaningful changes
These are not things I need to check every day, but they become useful after months or years of data. With enough history, I can move from โit feels inefficientโ to โthese situations are actually less efficient.โ
Keep vehicle data in my own system
I do not want vehicle history to exist only inside third-party platforms. TeslaMate lets me keep the data in my own database and use Grafana for long-term analysis.
Owning the data also means owning the operations:
- Service updates
- Token / session state
- Database backup
- Grafana dashboard maintenance
- Privacy boundaries and public-sharing control
๐งฑ Role in the Home Lab
TeslaMate runs in Docker on OMV, so it belongs to the App Layer. It does not need to sit close to large media files like Immich, and it is not part of the storage layer like TrueNAS. It is closer to a long-term collection and analytics system.
flowchart TD CAR[Tesla Vehicle / Tesla Cloud] --> TM[TeslaMate] TM --> DB[(Postgres Database)] TM --> MQTT[Mosquitto MQTT] TM --> API[TeslaMate API] DB --> GF[Grafana] USER[User / Browser] --> NPM[Nginx Proxy Manager] NPM --> API NPM -. When needed .-> GF
Deployment summary
| Item | Current approach |
|---|---|
| Placement | OMV / Docker |
| Core services | TeslaMate, Postgres, Grafana, Mosquitto, TeslaMate API |
| Database | Postgres stores vehicle history and configuration state |
| Visualization | Grafana reads from the database and provides dashboards |
| MQTT | Mosquitto acts as an internal message channel for the TeslaMate stack |
| Public entry | nginx-proxy-manager controls which endpoints are exposed or proxied |
Note
The actual compose file, environment variables, mount paths, ports, tokens, and proxy host settings stay in private configuration. This public note only records component relationships and operational priorities.
About Mosquitto
In this stack, Mosquitto is an internal component mainly used by TeslaMate / API-related flows. The important part is not treating the MQTT broker as a public entry point or exposing it to networks that do not need it.
๐ Data I Actually Review
TeslaMate can be dashboard-heavy, but the useful data is the data that changes decisions.
Areas I check
| Type | Purpose |
|---|---|
| Mileage | Understand monthly usage and road-trip share |
| Efficiency | Compare commute, weather, speed, and route effects |
| Charging sessions | Review home/external charging split, duration, and frequency |
| Battery state | Track long-term trends without overreacting to single readings |
| Sleep state | Confirm the car can sleep normally and avoid unnecessary drain |
Data I do not publish
- Individual trip routes
- Frequently used parking places
- Charging locations and timing patterns
- Geofences near home or work
- Raw maps, coordinates, or dashboard screenshots
TeslaMate data is useful for personal review, but it is not safe to publish directly. Even a simple screenshot can leak travel patterns or fixed locations.
๐ Privacy and Security Boundaries
TeslaMate interacts with Tesla account / API flows and stores long-term vehicle telemetry, so I treat its security boundary more strictly than a normal dashboard.
Public principles only
| Area | Principle |
|---|---|
| Tesla account | Do not publish account details, auth flow, tokens, or recovery details |
| Vehicle identity | Do not publish VIN, license plate, vehicle name, or identifiable details |
| Location data | Do not publish GPS, geofences, home, work, or frequent locations |
| Grafana | Do not publish real dashboard screenshots or query details |
| API | Do not publish tokens, endpoints, headers, or actual routes |
Entry protection model
TeslaMate, Grafana, and API exposure should be considered separately:
- The TeslaMate management UI should not be casually public
- Grafana dashboards can leak location and trip data even when read-only
- API access should be limited to explicitly needed integrations
- NPM handles entry and HTTPS, but it is not the only security boundary
Warning
The sensitive part of vehicle telemetry is not only credentials. It is behavior. Long-term location and charging records can reveal daily routines.
๐พ Backup and Restore
TeslaMateโs main value is long-term history, so backup focus is the database and configuration state.
Data that needs protection
| Data type | Notes |
|---|---|
| Postgres data | Trips, charging, states, locations, vehicle metadata |
| TeslaMate settings | Authorization state, vehicle settings, location/geofence settings |
| Grafana data | Dashboards, data sources, user settings |
Compose / .env | Service definition and required environment variables, stored privately |
| Import / backup files | Backup material used for migration or restore |
Post-restore checks
- Postgres starts normally
- TeslaMate can connect to the database
- Vehicle data sync resumes
- Grafana dashboards can read data
- Mosquitto works for internal stack usage
- TeslaMate API remains usable by required integrations
- NPM exposes only the necessary services
Backup notes need to match the real stack
The current stack includes TeslaMate, Postgres, Grafana, Mosquitto, and TeslaMate API. Backup and restore notes need to track the actual service count so disaster recovery does not miss a component.
๐ Grafana and Review Habits
The value of TeslaMate is not the number of dashboards. The value comes from reviewing the data regularly.
Questions I review
- Has average efficiency changed recently?
- Does the home-charging ratio match expectations?
- Should road-trip charging strategy change?
- Is there abnormal drain or failure to sleep?
- Did seasonal or route changes affect usage patterns?
If the data is collected but never reviewed, it becomes just another database to maintain. For me, TeslaMate is useful because it turns vehicle history into behavior adjustments.
How I would share charts publicly
If I ever share charts, I would anonymize them first:
- Remove date and time detail
- Avoid maps and location labels
- Keep only aggregated trends
- Do not publish raw dashboard screenshots
- Do not show vehicle name or account information
โ ๏ธ Pitfalls I Ran Into
Collecting data without reviewing it has little value
TeslaMate can easily become โthe data exists, but no one uses it.โ Without scheduled review, it adds maintenance cost without changing driving or charging habits.
Dashboard screenshots are more sensitive than they look
Grafana charts may look like simple statistics, but they often contain time, location, route, charging station, and vehicle-state information. Individually those details may seem harmless. Together they reveal private patterns.
Confirm backups before updates
TeslaMate depends on a database, and Grafana has its own persistent state. If I only think about the app container, I may miss database migrations, dashboard settings, or API integration compatibility.
โฌ๏ธ Upgrade and Maintenance Principles
TeslaMate has multiple components, so I treat upgrades as a stack-level operation instead of updating one container in isolation.
Before upgrading
- Confirm Postgres backup is available
- Confirm Grafana data is backed up
- Keep private backups of compose and
.env - Read TeslaMate, Grafana, and Postgres-related changes
- Avoid changing NPM, the database, and TeslaMate in the same maintenance window
After upgrading
- TeslaMate Web UI works
- Vehicle data keeps updating
- Grafana dashboards still render
- API integrations still work
- Mosquitto is healthy
- Backup jobs still succeed
Routine checks
- Last vehicle sync time is reasonable
- The car can sleep normally
- Database growth is expected and controlled
- Grafana dashboards can still read data
- Public entry points expose only necessary services
- Backup files can be restored in a drill
Conclusion
TeslaMate is one of the more practical data services in my Home Lab. It changes vehicle ownership from checking current state to understanding long-term trends, helping me review mileage, efficiency, charging habits, and sleep behavior.
But it is also a high-privacy data service. When publishing notes, I only document architecture, backup scope, and operations principles. I do not publish anything that can reveal vehicle identity, trip patterns, locations, or account authorization details.
Further reading: Home Lab Overview, OpenMediaVault, Nginx Proxy Manager, Home Assistant