Drive end time was recorded as the start time of a new drive

[fracai]

Describe the bug

Two consecutive trips are listed on the Drives board, but don't list any data. I can click the timestamp and the Drive Details board opens with a correct starting timestamp and an end timestamp set to "a few seconds ago". I can see, based on vehicle activity, that the end time of the first drive should be the start time of the second drive. I can manually change the time range and all data looks to have been properly recorded. It just looks like the drive end time was recorded as the start of a new drive and then both drives (the second of which shouldn't even exist) never receive a proper end time.

Is there anything I can do to recalculate the drive info? I'm perfectly happy to pull out a calculator and enter sql commands if necessary.

Thanks for your help.

Expected behavior

The end time should have been detected and recorded for the drive. If this is missed somehow, a new drive should at least be forced to be recorded as the end time of the previous drive. Maybe a clean up task to detect when the end time should have been based on vehicle activity? Maybe that's how it is already supposed to work?

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

Not really sure how to reproduce as this has only happened this one time.

1. Go on a drive
2. Check Drives dashboard
3. Does each drive have data recorded and correct end times on the Drives and Drive Details boards?

Relevant entries from the logs

It's been almost a month since the drive in question, so I unfortunately don't think I have the logs. The Grafana log starts well after the drive in question. I'm running this in a FreeBSD jail and I don't see a log file for tesla-mate, but I'm happy to dig around with a hint as to where to look. If it's just printed to stdout I think I'm out of luck as I'm not currently redirecting that anywhere.

Screenshots

Data

# psql teslamate teslamate -c "COPY (select * from drives where start_date > '2020-09-23' and start_date < '2020-09-24') TO STDOUT WITH CSV HEADER" | column -ts, 
id   start_date                  end_date                 outside_temp_avg  speed_max  power_max  power_min  start_ideal_range_km  end_ideal_range_km  start_km     end_km       distance           duration_min  car_id  inside_temp_avg  start_address_id  end_address_id  start_rated_range_km  end_rated_range_km  start_position_id  end_position_id  start_geofence_id  end_geofence_id
226  2020-09-23 10:01:22.49      2020-09-23 10:33:12.211  13.0              105        114        -54        342.40                314.50              3525.428966  3557.920169  32.49120300000004  32            1       19.3             2                 7               342.40                314.50              335572             340364           1                  2
228  2020-09-23 20:38:49.530643  1
227  2020-09-23 20:15:05.997     2020-09-23 20:28:25.381  25.8              76         80         -22        283.39                278.50              3557.951169  3564.33217   6.381001000000197  13            1       37.2             7                 54              283.39                278.50              340471             340521           2                  25
229  2020-09-23 21:11:44.980112  1

# psql teslamate teslamate -c "COPY (select id, car_id, drive_id, date from positions where date > '2020-09-23 20:35' and date < '2020-09-24') TO STDOUT WITH CSV HEADER" | sed 's/,/, /g' | column -ts,
id       car_id   drive_id   date
340524   1                   2020-09-23 20:38:17.27
340525   1        228        2020-09-23 20:38:49.288
340526   1        228        2020-09-23 20:38:53.131
340527   1        228        2020-09-23 20:39:09.113
340528   1        228        2020-09-23 20:39:25.05
340529   1        228        2020-09-23 20:39:41.301
340530   1        228        2020-09-23 20:39:57.392
…
340630   1        228        2020-09-23 21:07:27.179
340631   1        228        2020-09-23 21:07:44.548
340632   1        228        2020-09-23 21:08:20.809
340633   1        228        2020-09-23 21:08:36.96
340634   1        228        2020-09-23 21:08:53.083
340635   1        228        2020-09-23 21:09:09.202
340636   1        228        2020-09-23 21:09:25.615
340637   1        228        2020-09-23 21:09:43.767
340638   1        228        2020-09-23 21:10:00.919
340639   1        228        2020-09-23 21:10:23.644
340641   1        229        2020-09-23 21:11:43.049
340640   1                   2020-09-23 21:11:43.049
340642   1        229        2020-09-23 21:11:58.777
340643   1                   2020-09-23 21:12:13.427
340644   1                   2020-09-23 21:14:42.494
340645   1                   2020-09-23 21:17:19.238
340646   1                   2020-09-23 21:17:55.458
340647   1                   2020-09-23 21:19:33.696
340648   1                   2020-09-23 21:22:39.001

Environment

• TeslaMate version: 1.19.3
• Type of installation: Manual
• OS TeslaMate is installed on: FreeBSD jail 11.3-RELEASE running inside FreeNAS 11.2-U7
• User OS & Browser: macOS 10.15.6 Safari

[dyxyl]

Check for files tmp/log/erlang.log.* in the app's directory to see the TeslaMate logs (though it has probably rotated them by now).

[fracai]

Thanks for the tip, though I couldn't find any 'erlang.log*' files in the entire jail. I guess I have those turned off?

[dyxyl]

I think the logging depends on how you start TeslaMate. I run bin/teslamate daemon which passes various command line args to enable the erlang.log.* files.

[fracai]

Ah, looks like I'm currently using the FreeBSD daemon and teslamate start. I'll have to look in to changing that. For now, I'm starting to put together a script to generate what the drives table should have and I'll update the relevant rows.