contributing open-telemetry collector (receiver) for Tesla would be a booster for adoption.
The OTLP protocol is based on protobuf too...
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main

So, I setup a Kubernetes on DigitalOcean, connected to it and installed helm on my Mac.
So far so good...

No I went on to continue with the helm documentation:
https://github.com/teslamotors/helm-charts/blob/main/charts/fleet-telemetry/README.md

But on helm install fleet-telemetry teslamotors/fleet-telemetry -n fleet-telemetry --create-namespace I get this error:
Error: INSTALLATION FAILED: execution error at (fleet-telemetry/templates/1-secret.yaml:9:14): tlsSecret.tlsCrt is required

What additional steps I'm missing here. Can someone point me to the right direction?

Can the definitions for the flatbuffers be committed to the repo? Thanks!

The Field enums for the proto vehicle data are without definitions. This is hard for those of us who use this data. We need to understand it, to work with it correctly.

Please, add descriptions to these enums. It will help us all – those who want to use this thing and not as close to it.

I tried to fix it, with guesses and GPT4's help. I'll send a pull request. Maybe it's a start.

P.S Thanks for making great products, my model s is the greatest thing I have ever owned   😊

Hi thre,

We have succesfully started using the 3rd party API, and it's working well. Now we have a need to start streaming data, so we need to setup fleet-telemetry as well. We have setup the CSR steps as it's required on 3rd party as well. It is hosted on tesla.ourdomain.com/.well-known/appspecific/com.tesla.3p.public-key.pem

I have some prior experience with K8s, but I'm finding the steps to setup the server a little confusing. If I want to try out setting this whole service up using a minikube cluster to make sure everything is sorted, how do I go about doing that? Is that possibe at all? I have installed the helmcharts, but I'm getting a http://10.244.0.3:8080/status 10.244.0.3:8080: connect: connection refused error from the dashboard. What service is supposed to be hosted on port 8080 anyways?

I see that the README was updated to include more details on the previous steps, but I'd appreciate if you can please clarify/add more details to the actual server part.

For example, what is the docker-compose.yml file for? Is it possibel to test this locally at all, or we'd have to setup all the cloud infra first using K8s? Would appreciate some pointers!!

I keep hitting this error, Its fixable by increasing the interval of some fields of course. But it could be helpful to know what the total allowed interval is. Has anybody been able to figure out what the total allowed interval is or how to determine it, any answers or resource will go a long way. Thanks

Great project!

The README is pretty self-explanatory, but step 6 is a bit vague:

How can this config be shared? Is there some site where interested service providers (and hopefully individuals?) can sign up/upload the config?

Externally the app should expose a /status path to verify app status on the primary port. We will need to skip auth checks for this path.

I want to develop a offline app which only use the BLE. In this project, I found the vehicle_data.proto. So can I get the vehicle_data by BLE, like the Command SDK?

Hi @patrickdemers6 . I've followed your guide and generated a cert for mTLS using certbot / Let's Encrypt. The certificate has been delivered and loaded by the fleet-telemetry server however it fails the first step of the check_server_cert.sh tool.

When running this step manually I get the following output:

jay@Jays-MacBook-Pro fleet-telemetry % openssl s_client -connect "tesla.chqtest.net:443" -servername "tesla.chqtest.net" -showcerts 2>/dev/null            
CONNECTED(00000005)
---
Certificate chain
 0 s:CN=tesla.chqtest.net
   i:C=US, O=Let's Encrypt, CN=R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  2 00:41:56 2024 GMT; NotAfter: May 31 00:41:55 2024 GMT
-----BEGIN CERTIFICATE-----
MIIEJDCCAwygAwIBAgISAzTarMvBl9d/8+FWEIMiGfb8MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yNDAzMDIwMDQxNTZaFw0yNDA1MzEwMDQxNTVaMBwxGjAYBgNVBAMT
EXRlc2xhLmNocXRlc3QubmV0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeFFA
gnqtpE3oXAS0pZsJdw3xIpneD0ISiwOT1KnpMxeha2nQTlmuUrS2YAqmxJ4H+qfm
ExUlTyKjyuq1NZIIEKOCAhMwggIPMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU/0kK
h0lZN1Q3PI6zMwgD97zw2NAwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsU
wsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5j
ci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wHAYDVR0R
BBUwE4IRdGVzbGEuY2hxdGVzdC5uZXQwEwYDVR0gBAwwCjAIBgZngQwBAgEwggEE
BgorBgEEAdZ5AgQCBIH1BIHyAPAAdQA7U3d1Pi25gE6LMFsG/kA7Z9hPw/THvQAN
LXJv4frUFwAAAY380zQEAAAEAwBGMEQCIHiQSBd4Uh3om8ODlB8EVD2L378nihTI
ZDdpNtVPhSwWAiBAiiRcU5m7aMHygQ6HIYJXGw/0MrEGGu76OF3u7ba0WQB3AHb/
iD8KtvuVUcJhzPWHujS0pM27KdxoQgqf5mdMWjp0AAABjfzTNAoAAAQDAEgwRgIh
APD34ni4V8lkkUlD7COnM/tR6GIIb7M+1/74EylzChMoAiEArda8ZwkKtavOOfWf
3oCy8Iam3TzbWTjix8u6tbFRFxQwDQYJKoZIhvcNAQELBQADggEBAEJywcL+IQES
geQLSNK2MV7Ib+HVgv13Yoarg+JckpPJ7wgn+JDmZGgeJnwBg5BJkb8XOKPJF9q0
ryyGTOemXceeskiKiweV8QNYOBnJiwU2kNH6D+O8ZBSG+0f+XmvZTJ0z/NcwzOTN
WvyJjO+I6xw9II0750HcoUQVJWvSHQVotZUlOCumr2+eqLsXk1Ki4XsVX5AcG1IN
fK4MuZGk6uJijGK881Dt22jCVP7N0ZUuUDFFXJ5zzB54+Dzt2wj/AQS1sd9ZBXz8
eKvCYKJIW8KF7HE2E7C9rlvxtYpqh2z6DcZaumOMMckktyvJIbWkTgAYqk7RAuJT
hwsonBfIV1A=
-----END CERTIFICATE-----
---
Server certificate
subject=CN=tesla.chqtest.net
issuer=C=US, O=Let's Encrypt, CN=R3
---
Acceptable client certificate CA names
CN=Tesla Issuing CA, O=Tesla Motors, L=Palo Alto, ST=California, C=US
CN=Tesla Motors GF Austin Product Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors GF Berlin Product Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors GF0 Product Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors GF3 Product Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors GF3 Product RSA Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors Product Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors Product RSA Issuing CA, OU=Motors, OU=PKI, O=Tesla Inc., C=US
CN=Tesla Motors Products CA
CN=Tesla Motors Root CA
CN=Tesla Policy CA, O=Tesla Motors, L=Palo Alto, ST=California, C=US
CN=Tesla Product RSA Root CA, OU=PKI, O=Tesla, C=US
CN=Tesla Product Root CA, OU=PKI, O=Tesla, C=US
CN=Tesla Root CA, O=Tesla Motors, L=Palo Alto, ST=California, C=US
Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2865 bytes and written 419 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---

The exact same output is produced on a Linux server.

The fleet telemetry server is running at tesla.chqtest.net:443 so you can confirm for yourself. Server is dockerhub image tesla/fleet-telemetry:v0.1.11

Any help would be appreciated! Cheers.

I'm running docker image tesla/fleet-telemetry:v0.1.13

After adding the vehicle config via api/1/vehicles/:id/fleet_telemetry_config endpoint. I see this error in the fleet-telemetry logs

{"activity":true,"context":"fleet-telemetry","level":"info","method":"GET","msg":"request_start","remote_ip":"192.168.130.103:12842","time":"2024-04-04T16:36:38Z","urlPath":"/","uuid":"fdf28b05-4b08-4a77-86b4-989dd0b8fcdb"}
{"X-Forwarded-For":"","activity":true,"context":"fleet-telemetry","level":"info","method":"GET","msg":"socket_connected","network_interface":"","path":"/","time":"2024-04-04T16:36:38Z","txid":"ba87938c-e739-427e-8908-f3fa99c8d26c","user_agent":"Hermes/1.16.2 (vehicle_device)"}
{"activity":true,"context":"fleet-telemetry","duration_sec":0,"level":"info","msg":"socket_disconnected","time":"2024-04-04T16:36:39Z","total":"0"}
2024/04/04 16:36:39 http: panic serving 192.168.130.103:12842: runtime error: invalid memory address or nil pointer dereference
goroutine 92 [running]:
net/http.(*conn).serve.func1()
	/usr/local/go/src/net/http/server.go:1854 +0xbf
panic({0x1304fe0, 0x1f3bed0})
	/usr/local/go/src/runtime/panic.go:890 +0x263
github.com/beefsack/go-rate.(*RateLimiter).Try(0xc000431ae0)
	/go/pkg/mod/github.com/beefsack/[email protected]/rate.go:55 +0xe8
github.com/teslamotors/fleet-telemetry/server/streaming.(*SocketManager).ProcessTelemetry(0xc00028f200, 0xc00028f200?)
	/go/src/fleet-telemetry/server/streaming/socket.go:198 +0x23a
github.com/teslamotors/fleet-telemetry/server/streaming.(*Server).ServeBinaryWs.func1({0x1738090?, 0xc0000c2460?}, 0xc0000be800)
	/go/src/fleet-telemetry/server/streaming/server.go:102 +0x29a
net/http.HandlerFunc.ServeHTTP(0x0?, {0x1738090?, 0xc0000c2460?}, 0x0?)
	/usr/local/go/src/net/http/server.go:2122 +0x2f
net/http.(*ServeMux).ServeHTTP(0x1314880?, {0x1738090, 0xc0000c2460}, 0xc0000be800)
	/usr/local/go/src/net/http/server.go:2500 +0x149
github.com/teslamotors/fleet-telemetry/server/streaming.serveHTTPWithLogs.func1({0x1738090, 0xc0000c2460}, 0xc0000be800)
	/go/src/fleet-telemetry/server/streaming/server.go:73 +0x391
net/http.HandlerFunc.ServeHTTP(0x0?, {0x1738090?, 0xc0000c2460?}, 0x50794e?)
	/usr/local/go/src/net/http/server.go:2122 +0x2f
net/http.serverHandler.ServeHTTP({0xc0002fe630?}, {0x1738090, 0xc0000c2460}, 0xc0000be800)
	/usr/local/go/src/net/http/server.go:2936 +0x316
net/http.(*conn).serve(0xc0003ae870, {0x1738bd8, 0xc00055e780})
	/usr/local/go/src/net/http/server.go:1995 +0x612
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:3089 +0x5ed
{"context":"fleet-telemetry","level":"debug","msg":"return_stop_chan","time":"2024-04-04T16:36:39Z"}
{"context":"fleet-telemetry","level":"debug","msg":"writer_done","time":"2024-04-04T16:36:39Z"}

if I check the /api/1/partner_accounts/fleet_telemetry_errors endpoint, I see this error:

            {
                "created_at": "2024-04-04T16:47:45.308654633Z",
                "error": "\"webconnection error: read tcp 192.168.0.252:57868->99.80.125.251:443: i/o timeout\" cm_type=stream",
                "error_name": "cloud_manager_error",
                "hostname": "tesla-telemetry.mydomain.com",
                "name": "7dc3946c846c-42bc-a2fc-ec2c1117a1f7",
                "port": "443",
                "txID": "add6841e-f9c2-4ed1-8f89-eb90c8a0b325",
                "vin": "....."
}

Have anyone else facing this issue? It could be a miss configuration?

for the reference the servers's config is:

    {
      "host": "0.0.0.0",
      "port": 443,
      "log_level": "trace",
      "json_log_enable": true,
      "namespace": "tesla.original-vehicle-data.v1",
      "reliable_ack": true,
      "monitoring": {
        "prometheus_metrics_port": 9090,
        "profiler_port": 4269,
        "profiling_path": "/tmp/trace.out"
      },
      "rate_limit": {
        "enabled": false
      },
      "records": {
        "alerts": [
            "logger"
        ],
        "errors": [
            "logger"
        ],
        "V": [
            "logger"
        ]
      },
      "tls": {
        "server_key": "/etc/ssl-tesla/key.key",
        "server_cert": "/etc/ssl-tesla/key.crt"
      },
      "ca": "-----BEGIN CERTIFICATE-----\n...<content of full certificate chain file> ==\n-----END CERTIFICATE-----\n"
    }

This morning I received the email saying I was Fleet Telemetry ready.

I create a brand new CA cert using my private key, and issued a certificate to my fleet telemetry server. I then used the fleet_telemetry_config endpoint to install config on my Model 3. However the fleet_telemetry_errors endpoint has told me certificate signed by unknown authority

I ran ./check_server_cert.sh conf.json and it returned:

/tmp/tmp.xmvFF6Cnk1: OK
The server certificate is valid.

So it would seem my configuration and Fleet Telemetry server are configured correctly, yet my vehicle does not like my certificate authority.

Drivers can send a DELETE request to fleet_telemetry_config and delete the config.

This is strange because only Owners can POST requests to fleet_telemetry_config.

If only owners can create, you would expect only owners to be able to delete.

Does the fleet telemetry provide actual charging current and voltage?

The fields in Fleet API are charger_actual_current and charger_voltage.

I received yesterday messages, but today it doesn't seem to get any messages. Maybe it is related to the port feature:
#114 (comment)

https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/vehicles/fleet_telemetry_config
with port set to 4445 will response:

{
	"response": {
		"updated_vehicles": 1
	}
}

Car is online.

https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/partner_accounts/fleet_telemetry_errors
just old errors from yesterday.

Docker up and running

2024/02/27 11:44:09 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
time="2024-02-27T11:44:09Z" level=info msg=starting
time="2024-02-27T11:44:09Z" level=info msg=status_server_configured
time="2024-02-27T11:44:09Z" level=info msg=profiler_started
time="2024-02-27T11:44:09Z" level=info msg="registered kafka for namespace: tesla_telemetry"

http://localhost:8080/status

ok
BTW: it would be nice to see some more infos like connected cars...

if i connect from a browser i can see a connection has been declined:

2024/02/27 12:09:40 http: TLS handshake error from 78.43.56.144:26896: EOF
2024/02/27 12:09:40 http: TLS handshake error from 78.43.56.144:26897: EOF
2024/02/27 12:09:41 http: TLS handshake error from 78.43.56.144:26898: tls: client didn't provide a certificate

What else can I check?

In the "Setup Steps" section, step 2 creates a file called "private-key.pem", but in step 5, the command references "private_key.pem". Copy/pasting these commands yields an error because of the mismatched file name.

I would like to run this software behind a HTTP proxy that would terminate the mTLS connections. Because the proxy terminates the connections, the fleet-telemetry server would not see the client cert. However, many proxies can forward the client certificate, or common name to the backend via HTTP headers, e.g SSL_CLIENT_CERT/SSL_CLIENT_S_DN for Apache.

Would you accept a patch, that adds a config to enable reading the cert, from the HTTP headers, instead of from the SSL connection? If so, I'd be happy to contribute. Reading from headers would be purely optional, and need to be enabled to avoid the security risk of letting clients providing unauthenticated certs.

Is it on the roadmap to support older Model S/X?

if not, is it because of missing virtual key (bluetooth) on older Model S/X?

How is fleet telemetry enabled on a particular vehicle for a particular third party app?

Is there a step that the driver/owner needs to perform?

Does it build upon the Third Party App permission mechanism?

At what point is the third party client_config.json installed and activated on the vehicle?

We still haven't supplied our client_config.json to Tesla as there are no instructions as per #41.

Thanks!

Which network port should the telemetry service (load balancer) be listening on?

The setup instructions do not specify a port, and the config endpoint does not mention supplying a port.

I realise that the server allows specifying the listening port in server_config.json, but what port do the vehicles connect to? Is it 443?

Can you include the port in config.hostname in the telemetry config, eg "test-telemetry.com:8443"?

Fleet telemetry was working for me, but now I'm receiving a 404 vin not found when trying to (re)configure it on a vehicle which was working before.

endpoint: POST /api/1/vehicles/fleet_telemetry_config
reply: http 404

{
  response: null,
  error: '<REDACTED VIN> not_found',
  error_description: ''
}

UPDATE: this was caused by attempting to use a Tesla account with DRIVER (not OWNER) access to the vehicle. See comments below for more. Tesla have indicated that this should start working in future.

Experiencing TLS Handshake Error

I've successfully deployed the Fleet Telemetry Service on EKS using the Helm Chart, and I've generated self-signed certificates for both the server and client using the same Certificate Authority (CA).
Despite a seemingly correct setup, I'm encountering a TLS handshake error when checking the POD logs.

2023/11/15 22:48:22 http: TLS handshake error from 100.94.115.106:38807: EOF 2023/11/15 22:48:23 http: TLS handshake error from 100.94.115.106:14949: EOF 2023/11/15 22:48:24 http: TLS handshake error from 100.94.115.106:27763: EOF 2023/11/15 22:48:26 http: TLS handshake error from 100.94.115.106:53347: EOF 2023/11/15 22:48:27 http: TLS handshake error from 100.94.115.106:29178: EOF 2023/11/15 22:48:28 http: TLS handshake error from 100.94.115.106:23737: EOF 2023/11/15 22:48:28 http: TLS handshake error from 100.94.115.106:20794: EOF 2023/11/15 22:48:29 http: TLS handshake error from 100.94.115.106:64515: EOF 2023/11/15 22:48:29 http: TLS handshake error from 100.94.115.106:64614: EOF 2023/11/15 22:48:30 http: TLS handshake error from 100.94.115.106:7163: EOF 2023/11/15 22:48:31 http: TLS handshake error from 100.94.115.106:2937: EOF 2023/11/15 22:48:32 http: TLS handshake error from 100.94.115.106:64564: EOF 2023/11/15 22:48:32 http: TLS handshake error from 100.94.115.106:21975: EOF

Could you provide guidance on troubleshooting this step?

Greetings.
Recently set up a 3rd party account in FleetAPI and tried to go through the authentication procedure to generate a client token, but encountered a problem at the stage of exchanging the authentication code for the access token and refresh token pair.

The response
{ "error": "server_error", "error_description": "Internal server error" }

This could be because we are not planning to generate a partner authentication token and hence skipping the step of generating the public/private key pair for signing commands ?

Note: we are using deeplink as redirect_uri

And an additional question: what is the purpose of redirect_uri in post /token endpoint? Per RFC 6749 there is no mention of POST /token requiring redirects.

Regards.

Hi, I noticed that the fields that are accessible in the Payloads in this project do not cover all fields that are documented to be available for example in the vehicle_data endpoint. Especially for our use case, having access to the steering wheel heater is essential. Will fields like these be added, or is there some fundamental difference in the type of data that will be available via fleet-telemetry and the vehicle_data endpoints?

We're seeing client_info_parse_error reported on new connections. This looks like a bug related to how the certificate is stored in the context.

We have too many vehicles to make 1 partition <> 1 consumer work.

I've implemented a manual solution for multi-partition support, but it'd be really good for others if the partition count was configurable. I looked for a way to do this but didn't find any obvious way.

I was wondering if it will soon be possible to send commands to the vehicle via fleet-telemetry, for example to open or close doors or to enable engine start.

Is there already a plan when this will be available?

Thank you for the help!

A security issue with Github has been used in phishing attempts.

The issue tracker will be re-enabled when Github releases a fix.

In the meantime, please send urgent bug reports to [email protected]. (Please do not use this email address to submit issues for this repository once the issue tracker is re-enabled).

Should the FQDN for fleet telemetry (as supplied in client_config.json) be the same as the domain supplied when registering a public key for vehicle pairing (virtual keys for signed commands) in the fleet API?

For example, our fleet API domain (for virtual keys) is tesla.chargehq.net.

Should (or MUST?) our FQDN for fleet telemetry be tesla.chargehq.net? Or can we use a different subdomain, eg telemetry.chargehq.net?

Can anyone clarify how to generate the keys and certificate required to use fleet telemetry mTLS?

I can't find instructions on generating the keys in this repo.

The vehicle-command repo has instructions for generating a key for TLS for the http proxy, which are:

openssl req -x509 -nodes -newkey ec \
    -pkeyopt ec_paramgen_curve:secp521r1 \
    -pkeyopt ec_param_enc:named_curve  \
    -subj '/CN=localhost' \
    -keyout key.pem -out cert.pem -sha256 -days 3650 \
    -addext "extendedKeyUsage = serverAuth" \
    -addext "keyUsage = digitalSignature, keyCertSign, keyAgreement"

Will that work? Just need to set an appropriate value for subj?

What is the relationship between these fleet-telemetry mTLS keys and the public key registered against our domain for API access? Does the CN value in these keys need to exactly match the domain that was registered? Is the API private/public key pair somehow used in the creation of the mTLS keys?

Hi, what is the best way to implement a logger?

For example while driving these fields are important:

• Location
• Heading
• Battery level (SoC)
• Rated range
• Autopilot state
• Gear
• Speed
• maybe also TPMS
• Temperature inside/outside

But experience with FleeAPI shows, that already 4 fields with 10 seconds interval already exceeding API rate limits.
So, what is the best practice to do it?

Feature Request:
Client(=Logger) asks server for some fields (for example see above)
Server responds only that fields that was changed between last API calls from this client.
In this case Gear, Autopilot state, (speed), temperatures, battery level and some other doesn't change most of the time, so mostly only location and heading will be changed. that reduces traffic but the data quality stays the same.

Moved this out of #122 and created new issue

@patrickdemers6 Update: I am able to fix the certificate issue. And using acme Bash https://github.com/acmesh-official/acme.sh/wiki/Issue-a-cert-from-existing-CSR i generated the certificates.

And now the server is running. Where do i check the logs?
Here is what i got when docker compose up. I have already created telemetry config for my tesla vehicle with full chain cert. No telemetry data is received to the server

$ docker-compose up
[+] Running 1/0
✔ Container fleetfiles-app-1 Created 0.0s
Attaching to app-1
app-1 | 2024/03/13 19:35:12 maxprocs: Leaving GOMAXPROCS=1: CPU quota undefined
app-1 | time="2024-03-13T19:35:12Z" level=info msg=config_skipping_empty_metrics_provider
app-1 | time="2024-03-13T19:35:12Z" level=info msg=starting
And no telemetry errors from fleet_telemetry_errors endpoint

{
"response": {
"fleet_telemetry_errors": []
}
}

Still check_server_cert.sh fails for the cert that i got from acme client.

/tmp/tmp.FMNmhcx9pU: CN = <domain name>
error 20 at 0 depth lookup:unable to get local issuer certificate
/tmp/tmp.FMNmhcx9pU: CN = <domain name>
error 20 at 0 depth lookup:unable to get local issuer certificate
The server certificate is invalid.

Hi, i have a problem with my CSR when creating the fleet-telemetry config. However, my CSR has been validated because with this third-party token I can use the API in the usual way, like ‘vehicle_data’ for example.

I've followed all the previous steps to get fleet-telemetry on my server, but I get this error. Thanks in advance

I've noticed that it's only related to my bearer, because I can put anything in the body, it won't change anything.
Here's my "URL" : bib-data.fr

For example, here I have access to the classic API, my CSR has been accepted and I've already received an email about it.

Thanks in advance.

We submitted a CSR back in December and are awaiting approval. Getting telemetry data is critical to the future of our product. Assuming we've done something incorrectly, we tried to validate the CSR using the new check_csr.sh script.

We have our public key registered at our root domain but have issued the CSR with the fleet telemetry endpoint as the common name.

The fleet telemetry endpoint is being hosted on a sub-domain (i.e. tesla.<rootdomain>.com), whereas the public key is hosted at the root: https://<rootdomain>.com/.well-known/appspecific/com.tesla.3p.public-key.pem

This causes check_csr.sh to fail as it reflects on the CN from the CSR to try and pull the public key from https://tesla.<rootdomain>.com

Does the CSR need to be supplied with the root domain as the common name, or does it need to be supplied with the eventual sub-domain for the fleet telemetry server?

If it turns out the root domain is what is expected, will it still work to have fleet telemetry hosted on a sub-domain?

Error: buildx failed with: ERROR: failed to solve: fleet-telemetry-integration-tests: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

Likely caused by #38

Outside of the US, it is extremely common to lease vehicles. It would be very cool if lessees could enable this.

Perhaps if they have already added the Virtual Key for the partner domain?

We've setup our fleet server, supplied the CSR to the fleet support email and received confirmation, and can now register vehicles (and confirmed the tokens include the fleet urls in the aud array). But no data or requests are ever coming to our server.

Wondering if there is anything else we need to do, or anyway we can check if data is even trying to be sent.

Thanks!

When running integration tests twice in a row, Docker caching should minimize the work performed on the second run.

Current Behavior

Go packages are installed on both runs of the integration test suite. This takes upwards of one minute, wasting valuable developer time.

Expected Behavior

The Dockerfile and integration test script is configured in such a way that dependencies are cached between runs. The second run of the tests is faster since Go packages are not re-downloaded.

I'm building a third-party service that needs to pull the location and heading of a user's vehicle once or twice daily. I'm currently calling wake_up and then waiting until the vehicle_data API is available. I've found that waking up is not always reliable and I'm worried that it could be contributing to battery drain. Would the fleet telemetry API be better for my use case?

Also, I notice that TeslaPy has a stream() function, has anyone tried using that?

As I'm not familiar with installing and managing a Kubertetes server.
I would like to use DigitalOcean for this.

Where can I find some good and easy to understand information on the topic?

Thank you for all the hard work making Fleet Telemetry available to the developer community. We have successfully switched our app from polling to fleet telemetry and it is working well.

One thing we have noticed is that it takes a while for a vehicle to start sending data after it has been enrolled via 'fleet_telemetry_config create'. For our test fleet it has taken anywhere from a few hours to almost a full day for the sync to happen.

• What determines the timing of the vehicle connecting to the backend to receive the target config?
• Is there any way to force the sync or make the timing more predictable? If not today, are there any plans to improve this in the future?
• Should telemetry data start as soon as the sync parameter returns true via 'fleet_telemetry_config get'?

One of our test vehicles is a 2018 Model S (Gen 2). We know this vehicle is not (yet) supported by Fleet Telemetry but we are successfully able to push a config to it (sync flips to true) but we do not receive telemetry (as expected). Should an error be returned when targeting an unsupported model?

Any insight you can offer is much appreciated. Keep up the great work!

1. How can I determine the total battery capacity from the vehicle data?
2. How can I obtain the energy consumption information?
3. How can I distinguish between the new Model 3 and the old Model 3?
4. How can I differentiate between the long-range version and the standard version?

When I access this interface,https://fleet-api.prd.cn.vn.cloud.tesla.cn/api/1/vehicles/fleet_telemetry_config. The interface returns...

{"response":null,"error":"upstream internal error","error_description":""}. What could be the reasons for this return

Furthermore，What should be filled in for this parameter（config.ca） in this interface?

Running the server without a monitoring block in the configuration causes a panic:
ex.:

    "monitoring": {
        "prometheus_metrics_port": 9273,
        "profiler_port": 4269,
        "profiling_path": "/tmp/trace.out"
    },

Hi there,

I'm trying to retrieve the ChargingState from the telemetry data. I assumed this was returned in the ChargeState.

I assumed that ChargeState had type charging_value, so I could check i.e. for ChargeStateDisconnected (enum value 1).

However, ChargeState only returns a string_value which is Idlewhenever the vehicle is not charging.

Help is appreciated, thanks in advance!

After following the installation instructions, including the check_csr, I get:
{"response":null,"error":"Validation failed: Csr is not a valid CSR","error_description":"","txid":"8ebdc3bed961facfc62dba400a988185"}

tools/check_csr returns:

CSR: elmert.com.csr
Host: www.elmert.com
Public keys are matching

I've regenerated the csr, but no luck.

I submitted a CSR Feb 7:th and I'm still waiting for approval. I attached the Application client_id and a short description of the fields I need and why. The CSR has also passed the tools/check_csr.sh script.

• How long does confirmation usually take?

Would it make sense to have discussions for the repo so we can use that to open conversations rather than attaching it on emails or an open issue? it's under Repo -> Settings -> Features [ Discussions ]. it would provide for a nice discussion area. thanks for considering.

I have problem receiving vehicle data in my server. I'm not sure if it's the server key config issue or it's something else.

Anyhow I'd like to go through the steps I took and the result I'm experiencing and hopefully you can point me to the right direction:

Steps:

I have followed the guides based on the fleet docs

1. Register domain

I create the keys:

openssl ecparam -name prime256v1 -genkey -noout -out private-key.pem
openssl ec -in private-key.pem -pubout -out com.tesla.3p.public-key.pem

openssl req -new -x509 -key private-key.pem -out client-certificate.pem

I have registered a partner account domain:

I submitted client-certificate.pem as ca and host com.tesla.3p.public-key.pem as https://mysubdomain.high-mobility.com/.well-known/appspecific/com.tesla.3p.public-key.pem

curl https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/partner_accounts --data '{...}'

{
    "response": {
        "client_id": '....',
        "domain": "mysubdomain.high-mobility.com",
        "ca": "-----BEGIN CERTIFICATE-----\n....",
        "public_key": "04418....b3c9",
   }
}

2. Distribute key in the car.

I also followed the stepped Distributing your public key in Vehicle Command SDK repo and the vehicle as my "Fleet Key"

Question

So the question that I have is how to configure server_config.json ?

This is my current config:

{
  "host": "0.0.0.0",
  "port": 443,
....
  "records": {
   ...
   "V": ["logger", "kafka"]
  },
  "tls": {
      "server_cert": "/etc/certs/server/tls.crt",
      "server_key": "/etc/certs/server/tls.key"
  }
}

the tls.crt and tls.key are valid certificates I obtained for this domain from GlobalSign.

However I see that it doesn't work. No data in log nor in Kafka, the LB is receiving many request while I'm driving the car but all I see in the fleet-telemtey log is TLS errors.

Did I configure the server with wrong keys?

Notes

1. I can confirm the TLS terminates on my fleet-telemetry instance
2. I can verify the certificates are working because running

openssl s_client -connect mysubdomain.high-mobility.com:443 -servername mysubdomain.high-mobility.com -showcerts 

CONNECTED(00000006)
depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
verify return:1
....
....
issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
---
Acceptable client certificate CA names
CN = Tesla Issuing CA, O = Tesla Motors, L = Palo Alto, ST = California, C = US
CN = Tesla Motors GF Austin Product Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors GF Berlin Product Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors GF0 Product Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors GF3 Product Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors GF3 Product RSA Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors Product Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors Product RSA Issuing CA, OU = Motors, OU = PKI, O = Tesla Inc., C = US
CN = Tesla Motors Products CA
CN = Tesla Motors Root CA
CN = Tesla Policy CA, O = Tesla Motors, L = Palo Alto, ST = California, C = US
CN = Tesla Product RSA Root CA, OU = PKI, O = Tesla, C = US
CN = Tesla Product Root CA, OU = PKI, O = Tesla, C = US
CN = Tesla Root CA, O = Tesla Motors, L = Palo Alto, ST = California, C = US
Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4798 bytes and written 426 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
402B4345F87F0000:error:0A000412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:ssl/record/rec_layer_s3.c:1586:SSL alert number 42

Hi,

I've only just sent my csr for approval so I haven't setup my server yet but have a couple of questions please.

1. If I want to seperate my prod vehicles from test vehicles (where test vehicle data is streamed to server A and prod vehicle data is streamed to Server B) can I use the same 'Application' to do this?

2. Can the same certificate for ourdomain.com be registered at both regional endpoints (I have test vehicles in both North US and European regions) and can I stream data from both regions to the same server?

3. I am likely to need to introduce at least one more domain, but possibly more. Do I need a seperate 'Application' for each domain and would I be able to stream the data for multiple domains to the same server (Eg. ourdomain.com & theirdomain.com both streaming to server A)?

Thankyou