Teslamate: Regenerated vehicle IDs | duplicate key value violates unique constraint "cars_vid_index"

[bahree]

OK, this seems to be new and sorry for all the noise I am creating with all the issues.

I noticed that the app on port 4000 wasn't loading and the data wasn't updated in the dashboard today and saw the following in the logs. This is not related to the synology NAS, as I am running this on a pi now.

Turns out a db constraint is kicking this which is causing this. The error is below. What ID do I need to fix in the database? And any ideas on what and why this is happening?

There is more to the log with my specific data which I didn't share and also retracted some details when sharing here such as VIN.

Thanks.

db_1         | 2019-09-03 06:03:24.916 UTC [36] ERROR:  duplicate key value violates unique constraint "cars_vid_index"
db_1         | 2019-09-03 06:03:24.916 UTC [36] DETAIL:  Key (vid)=(1310913525) already exists.
db_1         | 2019-09-03 06:03:24.916 UTC [36] STATEMENT:  INSERT INTO "cars" ("eid","name","vid","vin","inserted_at","updated_at") VALUES ($1,$2,$3,$4,$5,$6) RETURNING "id"
teslamate_1  | 23:03:24.940 [info] Application teslamate exited: TeslaMate.Application.start(:normal, []) returned an error: shutdown: failed to start child: TeslaMate.Vehicles
teslamate_1  |     ** (EXIT) an exception was raised:
teslamate_1  |         ** (MatchError) no match of right hand side value: {:error, #Ecto.Changeset<action: :insert, changes: %{eid: XXXXXXX, name: "Squirty", vid: XXXXXXXX, vin: "XXXXXXXXXXX"}, errors: [vid: {"has already been taken", [constraint: :unique, constraint_name: "cars_vid_index"]}], data: #TeslaMate.Log.Car<>, valid?: false>}
teslamate_1  |             (teslamate) lib/teslamate/vehicles.ex:71: TeslaMate.Vehicles.create_or_update!/1
teslamate_1  |             (teslamate) lib/teslamate/vehicles.ex:26: anonymous fn/2 in TeslaMate.Vehicles.init/1
teslamate_1  |             (elixir) lib/enum.ex:1336: Enum."-map/2-lists^map/1-0-"/2
teslamate_1  |             (teslamate) lib/teslamate/vehicles.ex:26: TeslaMate.Vehicles.init/1
teslamate_1  |             (stdlib) supervisor.erl:295: :supervisor.init/1
teslamate_1  |             (stdlib) gen_server.erl:374: :gen_server.init_it/2
teslamate_1  |             (stdlib) gen_server.erl:342: :gen_server.init_it/6
teslamate_1  |             (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
teslamate_1  | {"Kernel pid terminated",application_controller,"{application_start_failure,teslamate,{{shutdown,{failed_to_start_child,'Elixir.TeslaMate.Vehicles',{{badmatch,{error,#{'__struct__' => 'Elixir.Ecto.Changeset',action => insert,

🚨🚨🚨🚨🚨🚨 PLEASE NOTE: 🚨🚨🚨🚨🚨🚨

EDIT by @adriankumpf : update to the latest version (v1.8) to fix that issue!

[bahree]

Also, I wonder if this is related to #90 ?

[olexs]

Exactly the same for me this morning. I first noticed that the car remained "offline" in tracking despite me having driven to work. I thought it might be an API connectivity issue first and fired up the Tesla app on the phone - that connected, but it had to re-download the vehicle info, initially it showed "Model S" (I have a 3) and a blacked out car with no info, which doesn't usually happen.

I looked into TeslaMate container logs, and it showed a bunch of "vehicle not found" errors. I then restarted TeslaMate, only to see it fail to start up with the exactly same error as described above.

I assume there's been some server-side change in the Tesla API that caused both the re-download of the car data in the official app and the issues with TeslaMate.

[natrlhy]

@bahree yes seems related. I saw this, too on my db container and updated it with a new value on my synology. I'm seeing other issues still... Synology also has some issues with newer docker container versions not loading ENV variables in the .yml file

[bahree]

So, I got this fixed, and it is essentially the same issue as #90. Seems Tesla's backend changed a the ID. The update is simple, as outlined in #90 and the logs can give you the EID. You need to update the cars table in the database, with this new EID and should be good.

And to make it easier, I pasted the commands below to get this update when running docker-compose in detached, (or in another ssh shell). Credit goes to @netkruzer for sharing this on that other thread.

pi@pi-server:~/docker $ sudo docker-compose run --rm db psql -h db -U teslamate
Password for user teslamate:
psql (11.5 (Debian 11.5-1.pgdg90+1))
Type "help" for help.

teslamate=# SELECT * from cars;
teslamate=# UPDATE cars set eid=WHATEVER-YOUR-VALUE-IS;
teslamate=# exit

You of course don't need to do the select, but I like to double check and prefer to see the changes.

Now I wonder, if there is a way to replay some of the drives that it hasn't logged and has missed.

I am not closing this issue just yet and will leave it open in case someone else has it. I dont know how many cars are impacted by this - Tesla app was offline today for some changes.

[bahree]

Synology also has some issues with newer docker container versions not loading ENV variables in the .yml file

I was quite dissapointed with how Synology handled this and I can't trust that for now. Part of it was was fault to have auto-update on for the packages, but then I trusted it will be OK. I am running this on a docker container on a raspberry pi, and for now have disabled Docker on the Synology. Love Synology as a NAS and for other things, just not happy on this.

I just got the Raspberry Pi 4 delivered and am planning to attach a SSD to that, and run this off that - need to figure out how I can move the containers from one host to another. Am comfortable from a tech perspective, but not played that much with docker, so this is a good experience. :)

[olexs]

Can confirm, the fix also worked for me, with one correction: you have top UPDATE the EID, not the VID.

Now I wonder whether handling logic for this backend change can be built into TeslaMate itself, since this seems to be a repeating occurence for multiple users...

[bahree]

with one correction: you have top UPDATE the EID, not the VID.

Oh thanks - that was a typo when writing it up here. I went back and updated to make that correction.

[DrMichael]

So, I got this fixed, and it is essentially the same issue as #90. Seems Tesla's backend changed a the ID. The update is simple, as outlined in #90 and the logs can give you the EID. You need to update the cars table in the database, with this new EID and should be good.

How can I find out my new EID?

[adriankumpf]

Now I wonder whether handling logic for this backend change can be built into TeslaMate itself, since this seems to be a repeating occurence for multiple users...

Up until now only selected users had this problem. But Tesla seems to have changed the EIDs of a lot of cars in the last hours.

TeslaMate could use another identifier of course. However, the migration of existing users would not be trivial / could break a lot of things and even then it would not be bullet-proof since Tesla might still change things. It's still an unofficial API, unfortunately ....

[adriankumpf]

Okay, I think I have found a way to avoid that chaos in the future. The VIN can be obtained even if the vehicle is asleep or offline. The VIN should never change, I hope? If it is not available it falls back to the VID or the EID.

I already released that change as part of v1.8 to make life easier for those who runs into this issue later today. Hopefully that doesn't break anything else ...

Closing this for now.

[bahree]

Awesome, thank you.

[drklain]

Nice job. 1.8 fixed my problem as well. Wouldn't it be nice if Tesla would stop changing things...