Missing starts of drives

[rikbrown]

Describe the bug

I've noticed a number of drives from my home show the start as a location anywhere 5-10mins into the drive. Presumably this is caused by some type of polling delay, but TeslaFi doesn't have the same problem usually.

Expected behavior

The full drive is reported

How to reproduce it (as minimally and precisely as possible):

Take your first drive of the day and see if the start is missing.

Relevant entries from the logs

Let me know what would be useful from logs and I can try to pull.

Screenshots

https://imgur.com/a/M202mEs

Drive started in the middle of a highway.

Data

I can pull if the answer isn't "unfortunately this is expected"

Environment

• TeslaMate version: latest
• Type of installation: Docker
• OS TeslaMate is installed on: Linux (Synology NAS)
• User OS & Browser: Mac Chrome
• Others:

[tonypilborg]

I experience the same - And have put it to "the car have to switch from wifi to LTE - this can have some delay"...
But that should be similar on TeslaFi, except if this was not with the streaming API, and thus having some kind of "buffer" kept in the car, that was relayed to the old api once connection was established, but not through the streaming API..

I that is the case, could it be possible to combine the 2 approaches? Streaming API when connection IS really streaming, and the old pull method until then....

[adriankumpf]

I that is the case, could it be possible to combine the 2 approaches? Streaming API when connection IS really streaming, and the old pull method until then....

The regular poll-based API is still called every 15 seconds if streaming is enabled.

A direct comparison with TeslaFi would be interesting. It would surprise me if TeslaFi and TeslaMate would be very different here.

[tonypilborg]

The regular poll-based API is still called every 15 seconds if streaming is enabled.

Cool - good design choice :)

A direct comparison with TeslaFi would be interesting. It would surprise me if TeslaFi and TeslaMate would be very different here.

Agree - but the premise from OP was that he wasn't seeing this with TeslaFi... That doesn't make sense, but worth investigating...

[elgeniskogen]

I experience the same: TeslaFi is logging the whole trip, while Teslamate is missing the first minutes. I have enabled Streaming API. The start of the trip is from a WiFi location. I notice that TeslaFi has lower resolution on the tracks, so perhaps they are not using the streaming API?

[Kevga]

I also had this issue using the streaming API. I worked around it by only connecting the car to the WiFi when there is an update pending, because the switch from WiFi to LTE when the car starts driving seems to disconnect TeslaMate for quite a while. Not sure if that is a TeslaMate issue or a Tesla API issue, but since other loggers have no problem with that, I think it might be the former. Additionally, I use data from a garage door sensor to call the /resume endpoint of TeslaMate's API to inform it that the car is about to wake up, so that TeslaMate starts logging earlier.

As I said though, those are just workarounds and I wish that wouldn't be necessary.

[elgeniskogen]

Great input Kevga :-) I will try this do you have some more details on how to call the /resume endpoint of TeslaMate's API? I would love to this in Home Assistant.

[tonypilborg]

So it seems:
a. The polling every 15 seconds when streaming is enabled is not automatically switching to a more frequent polling, if the streaming API is not responding.... This could be changed (in line with #928)

b. It appears the streaming api access takes more time to initiate, when switching from WiFi to LTE... A higher frequency polling in this transition would most likely remedy this, to a level where TeslaMate is on par, or better, than any comparable solution..

[Kevga]

@elgeniskogen see #91 for details about how this works.

[emilfors]

I am seeing this behavior too. Mostly when leaving home (where the car is on a WiFi connection), but it has also happened when there was no WiFi involved. Just yesterday, the whole trip from home to the tire shop was recorded, but when I went back home again the first few hundred meters of the trip were missing.

[bikeymouse]

I have the same issue. Loggin often does not start until after 500+ meter driving when starting.
So the start location of many of my drives is not correct (and is recorded as being different from the end-location of the previous drive, which is of course not logical).

I have geofences for many of my locations, but because of this "bug", it looks like my trips often start from different random addresses.

So in addition to trying to solve this with polling adjustments to the API, why not also alway assume that the start location of a drive is the same as the end-location of the previous drive?

(to be sure that this assumption is correct, you could do this only if the odometer reading at the end of the previous drive is within e.g. 1 or 2 km's of th start of the current drive).

[emilfors]

That's a good idea, except that it would produce bad results if the car has been towed, for instance. I would suggest that instead of using the odometer, check the first GPS location fix of a new drive against the last one of the previous, and if they're sufficiently close together (within 1 km or so apart), then use the last location of the previous drive as the start of the new one. That'd produce a short, straight line possibly looking pretty weird on a map but at least the starting address would be correct and the driven distance would be less wrong.

[bikeymouse]

Good point. A bit more difficult to implement, but using the GPS location would be more fail save.

[bikeymouse]

Any chance that something like suggested by @emilfors will be implemented?