Lost 1.5 week worth of data

[DaddyBoard]

Hi,

Unfortunately I was not aware with the issues, and went to check my grafana today to see last data on 12th June 2026... ouch...

Luckily, thanks to my immense laziness, I didnt cancel TeslaFi and I still have the data from there, but I cannot import it, I assume due to the fact the import logic instantly fails any import attempt if there's existing prior data in TeslaMate

{:event, %Vehicle{} = vehicle, state}
when vehicle.drive_state.timestamp >= state.date_limit ->
  processing_complete(state)

This is incredibly frustrating. Why can I not import gaps of data?

Furthermore, why is there no way to configure Webhooks, Pushover, Discord etc notifications for when polling has failed x times? Or connection to the car has been lost?

Any help here with how to import my gap of data would be very useful, please

[crazybadger]

I lost 4 days before noticing, but updating to 4.0.1 fixed the issue. A shame though, as I've tracked almost 40,000 miles over the past 5+ years and now have a 4 day gap 😢

[DaddyBoard]

Unfortunate mate! I assume you didn't have a TeslaFi secondary source of data like me?

[brianmay]

Unfortunately, when Tesla makes changes to the unofficial APIs, things will break. And the only solution for us is to push a new fixed version that people need to upgrade to.

But perhaps we could be better at notifying people about the need to upgrade.

• I think this can be divided into three parts:

  1. What tools are currently available to help here. But may not be widely known about, e,g. due to insufficient documentation.
  2. What we could do to improve.
  3. What we would like to do but it out of bounds

• Current tools

  • It is possible to subscribe to the github project and get informed of new releases.This probably a good idea for all Teslamate users.
  • Similarly it is possible to subscribe and get all bug reports. This might get a bit noisy though. And there are bug reports that majority of users don't need to worry about.
  • It is possible to setup monitoring tools to poll /health_check and alert if this goes down.

• What can we do to improve?

  • Somebody needs to volunteer their time to investigate (not me unfortunately) if any of these would actually help or be feasible.
    • email alerts?
    • dashboard alerts.
    • Webhooks, Pushover, Discord etc notifications for when polling has failed x times
    • anything else?
  • Part of the problem here is scope creep. Teslamate is designed to be an interface get data from Tesla. Not a monitoring tool, or a notification tool. If we need to implement code for numerous different notification backends we probably are straying away from this.
  • Maybe a better option would be to provide documentation on how Teslamate could be used with an existing monitoring tool.
  • I think if we supported exporting prometheus style metrics, for polling (two types), errors, etc, that might be a good thing also.

• What is out of bounds

  Unfortunately we have no way of obtaining lost data. Tesla does not provide us with any APIs to do this.

[JakobLichterfeld]

Furthermore, why is there no way to configure Webhooks, Pushover, Discord etc notifications for when polling has failed x times? Or connection to the car has been lost?

As Brian say:

• It is possible to setup monitoring tools to poll /health_check and alert if this goes down.

To do so, see #2304 (reply in thread)

Healthcheck was reporting it correctly, that's why we spotted it, and we were able to fix it with v4.0.0 and the next day the next issue with V4.0.1.
Related to: #4782, especially #4782 (comment)

[JakobLichterfeld]

Oh yeah I haven't committed it to GH, just pushed the docker build to my dockerhub and ran it that way.

Just a heads-up on AGPL-3 compliance: if you've published a modified Docker image on Docker Hub, the corresponding source for that exact build should also be available. Otherwise, you're likely not complying with the license.

That's exactly why we ask contributors to submit PRs instead of maintaining closed forks.

[DaddyBoard]

Oh thanks for that info - I have now locked it in a private repo on Dockerhub -- I wrongly assumed that would just be the default

[JakobLichterfeld]

No worries, that makes a lot more sense then. Thanks for fixing it. Since it was publicly accessible via Docker Hub, the AGPL requirement to provide the corresponding source would have applied as well. If you ever decide to publish those features, we'd definitely appreciate a PR. 🙂

[DaddyBoard]

It's definitely not in a state to be drafted as PR.

I threw it together in an afternoon, hyper-specific to my data gap import issue, aswell as the homeassistant webhook - if I find the time to generalise my edits, I sure will do

[JakobLichterfeld]

Makes sense — sounds like a very focused one-off solution. If you ever get around to generalising it, feel free to open a PR or share it, happy to take a look 🙂

[othyn]

Was about to post the same thing... this isn't the first time I've been stung by something like this, and I've ended up with large gaps of data quite a few times. 7th of June was my cut off... RIP to that data, basically all of June.

Had some pretty cool trips which would have been nice to have recorded on the map and history, but oh well. It's only data, but its that same feeling as going on a walk without your fitness tracker on, ya know? I shouldn't care, and probably won't next week, but still kinda bummed out about it.

I've now setup the /health-check endpoint to poll for 2XX's in Uptime Kuma, as I saw that on a post above and didn't realise it was a thing for this project. Wish I'd known about that sooner but oh well. Will hopefully catch the next time it silently fails.

Thanks for having a fix out already, just bumped it and all's good.