Gafana errors after importing teslamate postgres database

[SemoTech]

Attempting to "move" (backup and restore) a full teslamate database between two different hosts (servers) fails!

• The Source host was using CentOS 7 and an older postgres:12 database and was configured for separate FQDN's:
  teslamate.example.com & garfana.example.com

• The Target host was setup with Ubuntu Server 22.04 and the newest postgres:16 database, as well as one FQDN with a subpath:
  tm.example.com & tm.example.com/grafana

• Both hosts confirmed running latest Docker (v26.0.0 / v26.1.4) and Docker Compose (vv2.25.0 / v2.27.1) versions.

These are the steps taken with great care and with no errors occurred in the import process, only in Grafana when accessing the imported data:

A - Ensured teslamate on Source host was running properly and was recording data from the Tesla API.
B - Upgraded Source host teslamate from v1.29.1 to latest current version of v1.29.2
C - Exported Source host teslamate postgres:12 database into a file without any errors using:
docker compose exec -T database pg_dump -U teslamate teslamate > teslamate.bck
D - Deployed a fresh teslamate v1.29.2 environment on the Target host, using postgres:16 and single FQDN for Grafana as tm.example.com/grafana
E - Prepared Target host for database import, as follows:
E1 - Stopped the new teslamate container
E2 - Accessed new postgres:16 DB and issued cleanup commands as per HERE (with no errors) using:
docker exec -i teslamate-postgres /bin/bash -c "PGPASSWORD=<TM_DB_PASS> psql --username teslamate teslamate" << .
Result was:

> drop schema public cascade;
> create schema public;
> create extension cube;
> create extension earthdistance;
> CREATE OR REPLACE FUNCTION public.ll_to_earth(float8, float8)
> RETURNS public.earth
> LANGUAGE SQL
> IMMUTABLE STRICT
> PARALLEL SAFE
> AS 'SELECT public.cube(public.cube(public.cube(public.earth()*cos(radians(\$1))*cos(radians(\$2))),public.earth()*cos(radians(\$1))*sin(radians(\$2))),public.earth()*sin(radians(\$1)))::public.earth';
> .
NOTICE:  drop cascades to 25 other objects
DETAIL:  drop cascades to extension cube
drop cascades to extension earthdistance
drop cascades to type billing_type
drop cascades to type range
drop cascades to type states_status
drop cascades to type unit_of_length
drop cascades to type unit_of_pressure
drop cascades to type unit_of_temperature
drop cascades to function convert_celsius(numeric,text)
drop cascades to function convert_km(numeric,text)
drop cascades to function convert_m(double precision,text)
drop cascades to function convert_tire_pressure(numeric,character varying)
drop cascades to table addresses
drop cascades to table car_settings
drop cascades to table cars
drop cascades to table charges
drop cascades to table charging_processes
drop cascades to table drives
drop cascades to table geofences
drop cascades to table positions
drop cascades to table schema_migrations
drop cascades to table settings
drop cascades to table states
drop cascades to table tokens
drop cascades to table updates
DROP SCHEMA
CREATE SCHEMA
CREATE EXTENSION
CREATE EXTENSION
CREATE FUNCTION

F - Imported database backup file copied to Target host (no errors) using:
docker exec -i teslamate-postgres /bin/bash -c "PGPASSWORD=<TM_DB_PASS> psql --username teslamate teslamate" < teslamate.bck
Results can be seen HERE
G - Started new teslamate container successfully
H - Accessed tm.example.com with no Tesla token prompt shown, so it means the original token imported correctly!
I - Manually changed the access paths under teslamate's Settings Page for the cars
From:

To:

J - Attempted to access the Dashboards which opened up Grafana correctly and using the new path of tm.example.com/grafana, but there is no actual data shown only errors like this:

Followed moments later by a Grafana "Failed to Fetch" Error notice:

K - Checked all containers log files and only errors were in the grafana container logs, see HERE

L - As a last resort used the pgAdmin manager tool to access the teslamate postgres:16 database, and confirmed the data imported correctly (cars were there, and so was old data), yet something is still broken!

QUESTIONS:

1 - Since the Target host had a fresh / newly deployed postgres:16 database, are the specific cleanup restore instructions outlined HERE to "Drop existing data and reinitialize" as per previous step "E2" still needed on a fresh setup before a backup file import is performed?

2 - Any other adjustments needed on the backup data file prior to importing, due to differences in the postgres:12 to postgres:16 versions?

3 - Before and After the database import, are there any other changes or database commands needed to properly display the historical data in Grafana without errors?

ANY IDEAS HOW TO FIX?

Thank you.