bug: fresh setups can fail before profile data is populated

[Suitear]

sudo docker compose logs teslamateapi
teslamateapi-1  | 2026/04/17 13:08:00.435728 [info] TeslaMateApi running in release mode.
teslamateapi-1  | 2026/04/17 13:08:00.441654 [info] initAuthToken - environment variable API_TOKEN is set and good.
teslamateapi-1  | 2026/04/17 13:08:00.441695 [error] getAllowList error with COMMANDS_ALLOWLIST: allow_list.json not found and will be ignored
teslamateapi-1  | 2026/04/17 13:08:00.441774 [info] mqtt connecting...
teslamateapi-1  | 2026/04/17 13:08:00.442572 [info] mqtt connected.
teslamateapi-1  | 2026/04/17 13:08:00.442762 [info] subscribed to: teslauieemate/cars/#
teslamateapi-1  | 2026/04/17 13:08:19.812180 [error] TeslaMateAPICarsV1 - (/api/v1/cars?token=&&&&&&). Unable to load cars.; sql: Scan error on column index 11, name "spoiler_type": converting NULL to string is unsupported
teslamateapi-1  | 2026/04/17 12:56:01.985893 [error] TeslaMateAPICarsV1 - (/api/v1/cars?token=&&&&&&). Unable to load cars.; sql: Scan error on column index 10, name "exterior_color": converting NULL to string is unsupported

and it can't pop up login window with basic-auth in .yml file.

[GentleHoneyLover]

Same here. Just set up teslamateapi for the first time and bumped into the same error. My car's color is ultra red.

[tobiasehlert]

Thanks for reporting @Suitear and @GentleHoneyLover.

I would be interested in what the value is that TeslaMate is injecting into the database. Could you please run following command in the database and return the output?

select id, model, trim_badging, exterior_color, spoiler_type from cars;

This is how the output should look like, which I run on one instance:

teslamatedatabase=# select id, model, trim_badging, exterior_color, spoiler_type from cars;
 id | model | trim_badging | exterior_color | spoiler_type 
----+-------+--------------+----------------+--------------
  1 | S     | 75D          | SignatureBlue  | None
  2 | 3     | 50           | PearlWhite     | None
(2 rows)

Regards,
Tobias

[jmcombs]

Adding a data point that might explain the inconsistent repro on this thread.

The affected columns are only NULL during the window before the car first comes online. On a fresh TeslaMate setup, if you authenticate and then query /api/v1/cars while the car is still offline/asleep, TeslaMate hasn't fetched the full vehicle profile yet, so exterior_color / spoiler_type / trim_badging are NULL and the endpoint returns {"error":"Unable to load cars."}.

As soon as the car comes online once, TeslaMate populates the real values and the error resolves on its own. In my case (2026 Model Y):

model: Y
trim_badging: 74D
exterior_color: UltraRed
spoiler_type: None
wheel_type: Crossflow19

So the values themselves are fine — the issue is purely that teslamateapi can't scan a NULL string column during that initial pre-online window. Handling these with sql.NullString (or COALESCE(col, '') in the SELECT) would make the endpoint resilient instead of 500-ing until the car wakes up.

Workaround in the meantime: wake the car once, or add a BEFORE INSERT OR UPDATE trigger on cars that coerces those columns to ''.

[GentleHoneyLover]

I can confirm that the car being offline during the first teslamate launch was the culprit for me.

[tobiasehlert]

Hi guys and thanks for the digging and the finding!

This looks like a bit of a corner case when it's a fresh TeslaMate setup, while the car is still offline/asleep and the full vehicle profile has not been populated yet, some of those fields can indeed still be NULL.

There is a similar nullable value already for the Model and TrimBadging in place that we can simply reuse for those fields as well.
I'll create a PR to address this shortly :)

Thanks, Tobias

[tobiasehlert]

This should have been adressed in #511 by now.
If someone wants to verify that it's not appearing that would be awesome :)

Thanks for reporting this issue!