TeslaSolarCharger

TeslaSolarCharger is a service to set one or multiple Teslas' charging current.

• How to install
  • Docker compose
  • Setting up TeslaSolarCharger
    • docker-compose.yml content
    • First startup of the application
    • HTTPS
    • Install and setup BLE API
• Setting up solar power values
  • Templates
  • REST values
  • Modbus values
  • JSON Path
  • XML Path
  • Correction Factors
• Often used optional settings
  • Power Buffer
  • Home Battery
  • Telegram integration
• How to use
  • Charge Modes
• Generate logfiles
• Privacy notes

You can either install the software in a Docker container or download the binaries and deploy it on any server. In June 2024, Tesla implemented rate limits to their API, so there is a BLE (Bluetooth Low Energy, implemented since Bluetooth Version 4.0) capable device needed near the car. You can find details on how to set up BLE here.

Check out pricing on Solar4Car.com and the migration guide here.

The easiest way to use TeslaSolarCharger is with Docker.

Depending on your system, you have to install Docker first. To do this on a Raspberry Pi (should be the same on standard Linux systems), you need to execute the following commands in your Terminal window:

1. Install Docker

   curl -sSL https://get.docker.com | sh
   

2. Add permissions to the pi user. If you have another username, update the command accordingly

   sudo usermod -aG docker pi
   

3. Reboot your Raspberry Pi

   sudo reboot
   

4. Test the Docker installation

   docker run hello-world
   

If any issues occur, try to identify them using this more detailed instruction.

If you are using a Windows host, install the Software from here. Windows 11 is highly recommended. Select Linux Containers in the installation process. Note: The SMA Energy Meter template is not supported on Docker on Windows.

To set up TeslaSolarCharger, you must create a docker-compose.yml (name is important!) file in a new directory.

In most cases TeslaSolarCharger only needs its own container. You configure your inverter, energy meter or home battery later directly in the web interface using a Template or a generic REST, Modbus or MQTT source (see Setting up solar power values).

SMA, Solax and Tesla Powerwall are supported through built-in templates and need no extra container. SolarEdge is integrated through a dedicated plugin container.

To edit files with Linux, you can either use your normal Linux desktop environment, or when accessing via SSH, you can use the nano editor, or when accessing from a Windows PC, you can use WinSCP.

Below you can see the content for your docker-compose.yml. This is everything most users need; the inverter/battery is added later via the web interface. Note: I recommend changing as few things as possible on this file as this will increase the effort to set everything up but feel free to change the Timezone.

services:
  teslasolarcharger:
    image: pkuehnel/teslasolarcharger:latest
    container_name: teslasolarcharger
    logging:
        driver: "json-file"
        options:
            max-file: "10"
            max-size: "100m"
    restart: always
    network_mode: host
    environment:
      - TZ=Europe/Berlin ##You can change your Timezone here
#      - ASPNETCORE_URLS=http://+:7190 ##Optional: change the HTTP port here
#      - HttpsPort=7443 ##Optional: change the HTTPS port here, 0 switches HTTPS off
    volumes:
      - teslasolarcharger-configs:/app/configs

volumes:
  teslasolarcharger-configs:

SolarEdge is integrated through a dedicated plugin container. The SolarEdge Plugin uses the cloud API, which is limited to 300 requests which are reset after 15 minutes. When the limit is reached the SolarEdge API does not gather any new values. This results in TSC displaying 0 grid and home battery power until 15 minutes are over.

To use the plugin, just add these lines before the volumes section of your docker-compose.yml. Note: You have to change your site ID and your API key in the CloudUrl environment variable. The plugin is later added in TSC as a REST source.

  solaredgeplugin:
    image: pkuehnel/teslasolarchargersolaredgeplugin:latest
    container_name: teslasolarcharger_solaredgeplugin
    logging:
        driver: "json-file"
        options:
            max-file: "5"
            max-size: "10m"
    restart: always
    environment:
      - CloudUrl=https://monitoringapi.solaredge.com/site/1561056/currentPowerFlow.json?api_key=asdfasdfasdfasdfasdfasdf& ##Change your site ID and API Key here
    ports:
      - 7193:80

You can also copy the complete content from here:

services:
  teslasolarcharger:
    image: pkuehnel/teslasolarcharger:latest
    container_name: teslasolarcharger
    logging:
        driver: "json-file"
        options:
            max-file: "10"
            max-size: "100m"
    restart: always
    network_mode: host
    environment:
      - TZ=Europe/Berlin ##You can change your Timezone here
#      - ASPNETCORE_URLS=http://+:7190 ##Optional: change the HTTP port here
#      - HttpsPort=7443 ##Optional: change the HTTPS port here, 0 switches HTTPS off
    volumes:
      - teslasolarcharger-configs:/app/configs
  
  solaredgeplugin:
    image: pkuehnel/teslasolarchargersolaredgeplugin:latest
    container_name: teslasolarcharger_solaredgeplugin
    logging:
        driver: "json-file"
        options:
            max-file: "5"
            max-size: "10m"
    restart: always
    environment:
      - CloudUrl=https://monitoringapi.solaredge.com/site/1561056/currentPowerFlow.json?api_key=asdfasdfasdfasdfasdfasdf& ##Change your site ID and API Key here
    ports:
      - 7193:80

volumes:
  teslasolarcharger-configs:

1. Move to your above created directory with your docker-compose.yml.
2. Start all containers using the command docker compose up -d.
3. Open http://your-ip-address:7190. On the first start, you are automatically redirected to the Setup Assistant (/setup), which guides you through all required settings step by step:
   1. Welcome
   2. Cloud Connection: Log in to your Solar4Car account to connect your installation to the cloud and generate a Tesla Fleet API token. A base license is required to use TeslaSolarCharger — you can check pricing at solar4car.com/subscriptions. You cannot continue past this step until your installation is connected and licensed.
   3. Solar & Battery: Configure where TSC gets your solar power (and optionally home battery) values from. Use a Template for supported devices, or a generic REST, Modbus or MQTT source. See Setting up solar power values.
   4. Location: Use the map to select your home area. This is the area where TSC starts charging your car based on solar power.
   5. Charge Prices: Configure your grid and solar energy prices.
   6. Charging Stations: Optionally connect OCPP charging stations.
   7. Cars: Add and configure the cars TSC should manage.
   8. Finish
4. After finishing the setup, wake up the car by opening a car door. Now the SoC values, car name,... should be displayed on the Overview page:
5. If there are any messages displayed below your car name, just follow the instructions.

You can change all of these settings later at any time via the menu (Cloud Connection, Base Configuration, Car Settings, …).

If you only want to charge based on Spot Price, you are done now.

Besides HTTP on port 7190, TSC is available via HTTPS on port 7443: https://your-ip-address:7443. Use HTTPS especially on iPhone, iPad and Mac: from version 27 on, Safari runs TSC up to ten times slower over plain HTTP.

TSC creates its own certificate for HTTPS and adds every host name and IP address it is opened with. For your browser to trust it without a warning, install TSC's certificate on each device once: open Base Configuration, click Download certificate and follow the steps for your device shown below the button.

On iPhone, iPad and Mac, where the slowdown occurs, the home page additionally shows the download button and a link to the secure address as long as TSC is opened via HTTP. You can close that hint, then it stays hidden on that device.

• With network_mode: host, as in the docker-compose files above, nothing else is needed and HTTPS works after a docker compose pull and docker compose up -d. If your container uses ports: instead, add - 7443:7443; until then TSC says so on the home page and in the base configuration instead of offering an address that cannot be reached.
• To use other ports, remove the # in front of the ASPNETCORE_URLS (HTTP) or HttpsPort (HTTPS) line in your docker-compose.yml, change the port and run docker compose up -d, e.g. - HttpsPort=8443. HttpsPort=0 switches HTTPS off. If ASPNETCORE_URLS already contains an https:// URL, TSC uses its certificates for that one instead.
• TSC learns the host names and addresses you use from your browser's requests. Base Configuration > Additional host names and IP addresses is only needed for names it never sees, e.g. one you use exclusively over HTTPS before ever opening it over HTTP.
• The certificate's private key is not part of TSC backups. After restoring a backup on a new device, install the newly created certificate on your devices again.

To go around Teslas API limitations, you can use Bluetooth (BLE) to control your car. You can do this either by using the same device as your TSC is running on, or by using a separate device. Note: The device needs to be placed near the car. Even if it is working when being a few meters away or in different rooms, I can guarantee you, that you will have issues sooner or later. The device needs to be in one room with the car without any walls between them.

Confirmed working hardware:

• Raspberry Pi Zero 2W (only capable when used as separate device)
• Raspberry Pi 3 Model B
• Raspberry Pi 4 Model B
• Raspberry Pi 5

To set up the BLE API on the same device as your TSC is running on, you need to add the following lines to your docker-compose.yml:

services:
#here are all the other services like TeslaMate, TSC, etc.
  bleapi:
    image: ghcr.io/pkuehnel/teslasolarchargerbleapi:latest
    container_name: TeslaSolarChargerBleApi
    privileged: true
    restart: unless-stopped
    network_mode: host
    environment:
      - ASPNETCORE_URLS=http://+:7210
#      - BluetoothAdapter=hci0#Optional: If you have multiple Bluetooth adapters, specify the one to use here
    volumes:
      - tscbleapi:/externalFiles
      - /var/run/dbus:/var/run/dbus

volumes:
  #here are all the other volumes like teslamate-db, teslamate-grafana-data, etc.
  tscbleapi:

You can also copy the complete content from here:

services:
  teslasolarcharger:
    image: pkuehnel/teslasolarcharger:latest
    container_name: teslasolarcharger
    logging:
        driver: "json-file"
        options:
            max-file: "10"
            max-size: "100m"
    restart: always
    network_mode: host
    environment:
      - TZ=Europe/Berlin ##You can change your Timezone here
#      - ASPNETCORE_URLS=http://+:7190 ##Optional: change the HTTP port here
#      - HttpsPort=7443 ##Optional: change the HTTPS port here, 0 switches HTTPS off
    volumes:
      - teslasolarcharger-configs:/app/configs
  
  bleapi:
    image: ghcr.io/pkuehnel/teslasolarchargerbleapi:latest
    container_name: TeslaSolarChargerBleApi
    privileged: true
    restart: unless-stopped
    network_mode: host
    environment:
      - ASPNETCORE_URLS=http://+:7210
#      - BluetoothAdapter=hci0#Optional: If you have multiple Bluetooth adapters, specify the one to use here
    volumes:
      - tscbleapi:/externalFiles
      - /var/run/dbus:/var/run/dbus

volumes:
  teslasolarcharger-configs:
  tscbleapi:

To set up a separate device for the BLE API, you need to install Docker on the device, like described here. Thereafter, you can use the following docker-compose.yml and start the container with docker compose up -d:

services:
  bleapi:
    image: ghcr.io/pkuehnel/teslasolarchargerbleapi:latest
    container_name: TeslaSolarChargerBleApi
    privileged: true
    restart: unless-stopped
    network_mode: host
    environment:
      - ASPNETCORE_URLS=http://+:7210
#      - BluetoothAdapter=hci0#Optional: If you have multiple Bluetooth adapters, specify the one to use here
    volumes:
      - tscbleapi:/externalFiles
      - /var/run/dbus:/var/run/dbus

volumes:
  tscbleapi:

The BLE API Base URL is configured per car. Go to Car Settings, open the car you want to control, enable Use BLE and enter the BLE API Base URL http://<IP of device with BLE API running>:7210/. Click Save and then click on Pair Car. Note: It could take up to three tries to pair the car. After you get a message that pairing succeeded, you can test the API by clicking on the Set to 7A. Note: The car needs to be awake during the pairing and test process.

Pairing fails with RF-kill on a freshly installed Raspberry Pi

If pairing or any BLE command fails with an error like this:

ble: failed to enable device: can't init hci: no devices available: (hci0: can't up device: operation not possible due to RF-kill)

then the Bluetooth adapter is blocked by the host operating system, not by the BLE API container. Raspberry Pi OS keeps the Wi-Fi and Bluetooth radios disabled (rfkill soft block) until a WLAN regulatory country has been configured, which is often not the case after a fresh install. As the block is enforced by the host kernel, the container cannot work around it, even though it runs with privileged: true and network_mode: host.

Run the following commands on the device that runs the BLE API (not inside the container):

1. Check the current state. The Bluetooth entry will most likely show Soft blocked: yes.

   rfkill list
   

2. Remove the block

   sudo rfkill unblock all
   

3. Set your WLAN country, otherwise the block is reapplied on the next reboot. Replace DE with your own country code.

   sudo raspi-config nonint do_wifi_country DE
   

4. Bring the adapter up and verify it is available

   sudo hciconfig hci0 up && hciconfig
   

5. Restart the BLE API container, so it can initialize the adapter again

   docker restart TeslaSolarChargerBleApi
   

If rfkill list shows Hard blocked: yes or does not list a Bluetooth device at all, Bluetooth is disabled in the firmware configuration instead. Check if /boot/firmware/config.txt contains a dtoverlay=disable-bt line, remove it and reboot. You can also check whether the Bluetooth stack is running at all with systemctl status bluetooth hciuart.

Unreliable BLE connection on a Raspberry Pi: Wi-Fi and Bluetooth share one antenna

On a Raspberry Pi the onboard Wi-Fi and Bluetooth radios share a single antenna. A poor Wi-Fi link therefore starves Bluetooth, and the symptom is not an obvious Wi-Fi problem: BLE connections to the car keep failing while the car is standing right next to the device. This was measured on a Pi 5 whose 5 GHz link had degraded to 6 Mbit/s: of 491 connection attempts only 8 completed (1.6 %). Moving the same Pi to Ethernet brought it to 95 % without any other change.

If BLE is unreliable, check in this order:

1. Use Ethernet for the device that runs the BLE API, or improve the Wi-Fi link (move the device, switch to 2.4 GHz, use a better access point). If the device does not need Wi-Fi at all, block the radio with sudo rfkill block wifi so it cannot interfere.
2. Use a USB Bluetooth adapter. A USB adapter has its own antenna and is not affected by Wi-Fi at all. Plug it in and select it per car (see below) - this is the most reliable fix if Ethernet is not an option.
3. Check the distance to the car. Without walls in between, roughly 4 metres is the practical limit for the onboard adapter.

Choosing which Bluetooth adapter a car uses

One BLE API container serves all Bluetooth adapters of its host. Each adapter gets its own worker process that opens the adapter once and keeps it open, so two adapters can talk to two cars in parallel.

In Car Settings, every BLE car has a Bluetooth adapter selection listing the adapters the container found, showing whether an adapter is onboard (UART) or USB and whether it is currently in use. The default is Container default, which behaves exactly as before: the adapter from the container's BluetoothAdapter environment variable, or the first available one.

Cars are pinned by the adapter's Bluetooth address, not by its hciX name, because hciX numbering follows the probe order and can change between reboots or after replugging a USB adapter. If a selected adapter is not present anymore (for example the USB adapter was unplugged), the affected car reports an error instead of silently falling back to a different radio.

A note on "car is not at home"

TSC decides whether a car is at home by listening for its Bluetooth advertisement, without connecting to it. Only repeated scans without any sign of the car mark it as away, so a single failed connection never moves a car that is standing in the garage. Note that at a location where no other Bluetooth devices are ever nearby, a completely dead radio cannot be told apart from an absent car - if the car is reported as away although it is at home, check the radio using the steps above.

To let the TeslaSolarCharger know how much power there is to charge the car, you need to set TSC up to gather the solar values. This is done on the Base Configuration page (or during the Setup Assistant) in the Solar value sources section.

You have four ways to add a value source:

• Template (recommended for supported devices)
• REST (JSON/XML APIs, also used by the SolarEdge plugin)
• Modbus
• MQTT

Templates are the easiest way to integrate a supported device — no extra container and almost no configuration is required. In the Template sources section, click Add new source, choose the matching type and fill in the few required fields. The following templates are available:

• Sma Energy Meter: Reads the grid power directly from the SMA EnergyMeter's (or Sunny Home Manager 2.0's) Speedwire multicast messages. The only (optional) field is the serial number, which you need in case you have multiple SMA EnergyMeter/Home Managers in your network. Note: As this listens to multicast messages, the TeslaSolarCharger container needs network_mode: host (which is the case in the docker-compose files above) and it is not supported on Docker on Windows.
• Sma Inverter Modbus / Sma Hybrid Inverter Modbus: Reads the values directly from your SMA inverter via Modbus TCP. Enter the Host (IP address or hostname), Port (Modbus TCP port, default 502) and Unit Id of your inverter.
• Solax Api: Reads the values directly from your Solax inverter. Enter the Host (IP address of your inverter/Wi-Fi dongle) and the Password (the Wi-Fi dongle's serial number).
• Kostal Hybrid Inverter Modbus: Reads the values from a Kostal hybrid inverter via Modbus TCP. Enter the Host, Port and Unit Id.
• Tesla Powerwall Fleet Api: Reads your Powerwall/home battery values via the Tesla Fleet API. You need to be connected to the Solar4Car cloud and have generated a Fleet API token (see First startup). Afterwards just select your energy site from the list.

To set up a REST API click on Add new source in the REST sources section on the Base Configuration page and fill out the fields.

If you are using the SolarEdge plugin, you need to use the following values:

• Url: http://<IP of your Docker host>:7193/api/CurrentValues/GetCurrentPvValues
• Set Result types to json and use the following json patterns:
  • Grid Power: $.gridPower
  • Inverter Power: $.inverterPower
  • Home Battery SoC: $.homeBatterySoc
  • Home Battery Power: $.homeBatteryPower

To set up Modbus values, click on Add new source in the Modbus sources section on the Base Configuration page and fill out the fields according to the documentation of your inverter:

• unitIdentifier: Internal ID of your inverter (in most cases, 3 or 1)
• Host: IP Address or hostname of your inverter
• port: Modbus TCP Port of your inverter (default: 502)
• Connect Delay Milliseconds: Delay before communicating the first time (you should use 1000)
• Read Timeout Milliseconds: Timeout until returning an error if the inverter is not responding (you should use 1000)
• Address: Register address of the value you want to extract.
• Length: Number of registers to read from (for integer values should be 2)
• Correction Factor: Factor to multiply the resulting value with. The result should be Watt, so if your inverter returns Watt, you can leave 1. If your inverter returns 0.1W, you have to use 10.

If you have the following JSON result:

{
  "request": {
    "method": "get",
    "key": "asdf"
  },
  "code": 0,
  "type": "call",
  "data": {
    "value": 14
  }
}

You can use $.data.value as Json Pattern.

If your energy monitoring device or inverter has no JSON, but an XML API, use the following instructions: Given an API endpoint http://192.168.xxx.xxx/measurements.xml which returns the following XML:

<?xml version="1.0" encoding="UTF-8"?>
<Device Name="PIKO 4.6-2 MP plus" Type="Inverter" Platform="Net16" HmiPlatform="HMI17" NominalPower="4600" UserPowerLimit="nan" CountryPowerLimit="nan" Serial="XXXXXXXXXXXXXXXXXXXX" OEMSerial="XXXXXXXX" BusAddress="1" NetBiosName="XXXXXXXXXXXXXXX" WebPortal="PIKO Solar Portal" ManufacturerURL="kostal-solar-electric.com" IpAddress="192.168.XXX.XXX" DateTime="2022-06-08T19:33:25" MilliSeconds="806">
  <Measurements>
    <Measurement Value="231.3" Unit="V" Type="AC_Voltage"/>
    <Measurement Value="1.132" Unit="A" Type="AC_Current"/>
    <Measurement Value="256.1" Unit="W" Type="AC_Power"/>
    <Measurement Value="264.3" Unit="W" Type="AC_Power_fast"/>
    <Measurement Value="49.992" Unit="Hz" Type="AC_Frequency"/>
    <Measurement Value="474.2" Unit="V" Type="DC_Voltage"/>
    <Measurement Value="0.594" Unit="A" Type="DC_Current"/>
    <Measurement Value="473.5" Unit="V" Type="LINK_Voltage"/>
    <Measurement Value="18.7" Unit="W" Type="GridPower"/>
    <Measurement Value="0.0" Unit="W" Type="GridConsumedPower"/>
    <Measurement Value="18.7" Unit="W" Type="GridInjectedPower"/>
    <Measurement Value="237.3" Unit="W" Type="OwnConsumedPower"/>
    <Measurement Value="100.0" Unit="%" Type="Derating"/>
  </Measurements>
</Device>

Grid Power: Assuming the Measurement node with Type GridPower is the power your house feeds to the grid, you need the following values in your Base configuration:

- Url=http://192.168.xxx.xxx/measurements.xml
- CurrentPowerToGridXmlPattern=Device/Measurements/Measurement
- CurrentPowerToGridXmlAttributeHeaderName=Type
- CurrentPowerToGridXmlAttributeHeaderValue=GridPower
- CurrentPowerToGridXmlAttributeValueName=Value

Inverter Power: Assuming the Measurement node with Type AC_Power is the power your inverter is currently feeding, you can use the following values in your Base configuration:

- Url=http://192.168.xxx.xxx/measurements.xml
- CurrentInverterPowerXmlPattern=Device/Measurements/Measurement
- CurrentInverterPowerAttributeHeaderName=Type
- CurrentInverterPowerAttributeHeaderValue=AC_Power
- CurrentInverterPowerAttributeValueName=Value

The correction factor is used to multiply the input value so that the results correspond with what TeslaSolarCharger expects.

You can use the correction factors to scale/ correct these values as appropriate. For example:

• Grid Power input expresses a positive integer as an import and a negative as an export: Select Minus as operator and 1 for the correction factor (this multiplies by -1).
• Inverter Power is expressed as kW instead of W: Select Plus for the operator and 1000 for the correction factor (this multiplies by 1000).
• Home Battery expresses its state of charge as an absolute value in kWh: Select Plus for the operator and a correction factor of 1/(Full Charge Capacity) e.g. if the battery has a full charge capacity of 100kWh the correction factor is 1/100 or 0.01

When you are at this point, your car connected to any charging cable in your set home area should start charging based on solar power. But there are a few additional settings that are maybe helpful for your environment:

If you set PowerBuffer to a value different from 0, the system uses the value as an offset. E.g., If you set 1000, the car's current is reduced as long as less than 1000 Watt power goes to the grid.

To configure your home battery, you need to add the following settings:

• Home Battery Minimum SoC
• Home Battery Charging Power

As long as your home battery's SoC is below the set value, the configured charging power is reserved for the home battery. E.g. if you set Home Battery Minimum SoC to 80% and Home Battery Charging Power to 5000W TSC lets the home battery charge with 5000W as long as its SoC is below 80%.

Note: If your battery is discharging, the power should be displayed in red. If the battery is charging, the power should be displayed in green. If this is the other way around, you must update the Operator to be Minus.

In this section, you learn how to create the Telegram Bot Key and where you get the Telegram ChannelID from:

• Create a bot by chatting with BotFather

• Ask BotFather to reate a new bot with the /newbot command and follow the instructions

• Click on the link starting with t.me/ (second line of BotFarther's answer in the chat) and send any message to your newly created bot. The reason for that is, that a chat exists, where TSC can send messages to.
• Copy the Bot token as Telegram Bot Key to your TSC

• To get a chat ID, you have to chat with the userinfobot

• Ask the bot for your UserID with the command /start

• Copy the user ID as Telegram Channel ID to your TSC

After setting everything up, you can use the software via http://your-ip-address:7190.

Currently, there are four different charge modes available:

1. Off: The car does not charge at all. This is useful if you need your solar power for other devices and do not want to charge the car at all.
2. Manual: You can set the charging speed manually.
3. Auto: TSC automatically sets the charging speed based on the available solar power. If a charging target is set, TSC automatically sets the charging speed to reach the target in time based on predicted solar energy and energy prices.
4. Max Power: The car charges with maximum power. This is useful if you want to charge the car as fast as possible, e.g., if you are going on a trip and need the car charged quickly.

You can download the logs of the TeslaSolarCharger container directly from the web interface: open the Support page from the menu. In the Logging section you can:

• Download Server Logs: downloads the most recent in-memory logs.
• Download Server File Logs: downloads the logs written to disk.
• Change the In Memory Log Level and File Log Level (e.g. set them to Verbose to create a more detailed logfile). These settings are reset to their defaults after a restart.

Note: Logs might contain sensitive information like your vehicle's location. Do not share logs publicly.

If you need the logs of a plugin container (e.g. the SolarEdge plugin), you can grab them via the Docker CLI:

docker logs teslasolarcharger_solaredgeplugin > teslasolarcharger_solaredgeplugin.log

If you get an error like Error: No such container: you can look up the container names with

docker ps

As the new Tesla Fleet API requires a domain and external Token creation from version 2.23.0 onwards, TSC transfers some data to the owner of this repository. By using this software, you accept the transfer of this data. As this is open source, you can see which data is transferred. For now (4th July 2024), the following data is transferred:

• Your access code is used to get the access token from Tesla (Note: the token itself is only stored locally in your TSC installation. It is only transferred via my server, but the token only exists in memory on the server itself. It is not stored in a database or log file)
• Your installation ID (GUID) is at the bottom of the page. Do not post this GUID in public forums, as it is used to deliver the Tesla access token to your installation. Note: There is only a five-minute time window between requesting and providing the token using the installation ID. After these 5 minutes, all requests are blocked.)
• Your installed version.
• Error and warning logs
• Your VIN and if using the Fleet API the data for each request (e.g. change-charging-amp to 7A)
• A statistic of your Fleet API and BLE API usage (e.g. changed car amps 58 times including Timestamps of the request)
• Your configuration regarding using BLE API, the configured Fleet API Refresh Interval, if getting Data from TeslaMate is enabled