tesla_custom and keeping Tesla vehicles in Home Assistant

A fork of an integration Home Assistant removed

The tesla_custom integration exists because the official Home Assistant Tesla integration was withdrawn. The README describes it as a fork of that previous official integration, which was removed due to Tesla login issues, and it tells users not to report issues to Home Assistant because of that lineage.

The scope is a Home Assistant custom component. The repository root holds the Python package layout that Home Assistant expects, with the component living in a `custom_components/tesla_custom/` directory, alongside `hacs.json` for HACS discovery, `config/`, `tests/` and a Poetry managed `pyproject.toml`. The declared dependency set is small: `teslajsonpy` pinned to 3.13.2 for the Tesla cloud API, `async-timeout` for timeouts, and Python `^3.13.2`.

The licence is Apache-2.0, and the project is not archived, with the last push on 2026-10-22 and version 3.27.0 in `pyproject.toml`.

The refresh token has to come from a third-party app

This is the part that trips up new users. The README states that you need an application to generate a Tesla refresh token before you can use the component, and it lists the options it knows about: the Tesla Tokens app for Android, Auth App for Tesla on iOS, TeslaFi with its Tesla v3 API Tokens flow, and the Chromium Tesla Token Generator for Chromium and Edge browsers.

The logic of that list is worth understanding. The login is handled by someone else's application, and this integration consumes the refresh token that application produces. That is not a design choice the project advertises as a feature; it is a consequence of the login situation it inherited. Anyone evaluating this integration should assume that token generation is a manual, out-of-band step that may need repeating, and that the responsibility for it sits outside Home Assistant.

The README also warns that the integration wakes your vehicles during installation, which is worth knowing before you add it to a household with more than one car.

Installing through HACS or by copying the component directory

There are two documented routes and neither needs a shell command, so the README gives instructions in prose rather than a script.

With HACS, you open the integrations section, use the explore and add repositories flow to add `https://github.com/alandtse/tesla` as a custom repository, search for Tesla, and then jump to the later steps. Without HACS, the README walks through the manual path: open your Home Assistant configuration directory, the one holding `configuration.yaml`, create a `custom_components` directory if it does not exist, create a folder named `tesla_custom` inside it, download all the files from the repository's `custom_components/tesla_custom/` directory, and place them there.

After the files are in place you restart Home Assistant and add the integration through the user interface, going to Settings, then Devices & Services, clicking the add button and searching for Tesla Custom Integration. The last step in the README is a warning in disguise: for most vehicles you will also need the Fleet API proxy described next.

The Fleet API proxy is required for most vehicles

Tesla has deprecated the Owner API for most vehicles in favour of a Fleet API with end-to-end encryption, and the README explains how you recognise that your car is affected. The symptom is `teslajsonpy.exceptions.TeslaException` errors in the log when you try to send a command. Sensors continue to work regardless, which is a useful diagnostic: if reading works and commanding does not, the proxy question is the one to answer.

The fix is to install the Tesla HTTP Proxy add-on and point the component at it. The README is not gentle about the effort involved, calling it a complex setup and linking a wiki page with step-by-step instructions for proxy setup with DuckDNS and NGinx.

That external dependency is the single biggest operational difference between this integration and an ordinary Home Assistant component. It is a separate service, with its own hostname, its own TLS arrangement and its own maintenance, standing between Home Assistant and your car. The README's own framing, that most vehicles need it, is the reason this belongs in any evaluation of the project rather than in a footnote.

What the integration actually exposes in Home Assistant

The entity list is broad, and it is split between vehicle entities and energy site entities.

For vehicles you get binary sensors for charger connection, charging status, car online, parking brake, car asleep and door status. Buttons cover the horn, flashing lights, wake up, force data update, HomeLink and remote start. Climate offers HVAC on and off, target temperature, and preset modes such as defrost, keep on, dog mode and camp mode. Device tracker covers car location and the active route destination. Cover entities cover the charger door, frunk, trunk and windows. Locks cover the door lock and the charge port latch lock. Sensors report battery level, charge rate, energy added, charger power, inside and outside temperature, odometer, estimated range, time charge complete, TPMS pressure and route arrival times. Switches include the heated steering wheel, charger, sentry mode, polling and valet mode.

For energy sites, meaning Powerwall and solar installations, the integration provides binary sensors for Powerwall charging and grid status, selects for grid charging, export rule and operation mode, and sensors for solar power, grid power, load power, battery level, battery Wh remaining and backup reserve.

A few of these entities are marked in the README as diagnostics or configuration entities, and some depend on hardware the car may not have. The HomeLink button is disabled by default because some vehicles do not have that option, and it can be enabled through configuration entities.

Polling wakes the car and costs battery

The most interesting part of the README for anyone who actually owns the car is the battery section. The `polling_interval` option sets how often the integration checks whether the car is awake and has new information, and the default is every 660 seconds.

The important detail is that polling itself does not wake a sleeping car. The integration checks, and only queries a car that is already awake. The README does warn that polling too frequently can keep the car awake and drain the battery, and notes that different firmware versions take between 11 and 15 minutes to enter sleep mode, with no official information on those timings, so the guidance is to experiment with the interval.

Commands do wake the car. Sending a door unlock or turning on the HVAC wakes it, and while it is awake the integration also fetches updates based on the polling interval. The README notes a further trick: sending a harmless command such as a lock command can intentionally wake the car to fetch recent information, which is useful in an automation that wants fresh data every morning. The trade-off is the related option, wake cars on start, which lets you choose whether cars keep sleeping and stay uninformed, or get woken on Home Assistant startup at the cost of interrupting long term hibernation and increasing vampire drain.

TeslaMate over MQTT as a second data path

The README lists a polling policy option and an MQTT option in the same menu, and the second is a genuinely different approach to getting data into Home Assistant. Enabling sync of data from a TeslaMate instance via MQTT effectively turns on the Streaming API for updates, and it requires MQTT to be configured in Home Assistant.

The difference from polling is the source of the data. Polling asks Tesla for the current state of the vehicle on a timer. The TeslaMate path reads updates that another tool has already collected and published to a broker, so the car is not being asked anything on this schedule. For a setup that already runs TeslaMate, that removes a second source of wake-ups and a second credential flow.

The cost is running another service and wiring MQTT into Home Assistant. If you do not already have TeslaMate installed, the README offers no guidance on setting it up, so the option is only attractive to people who are already in that ecosystem.

Where this integration is the wrong tool

The strongest argument against is that none of this is vendor supported. The project exists because the official integration was removed, and it asks users to obtain credentials through third-party applications and to run a proxy add-on with a DuckDNS and NGinx setup. If your vehicle still works through the Owner API, the official integration path may still be available to you and this fork is unnecessary.

The second limit is that the integration is not harmless to your car. The README says the installation wakes your vehicles, and it details the ways polling and commands can extend how long the car stays awake. For a daily driver with a healthy charging routine, that is manageable. For a car parked for weeks that you want to hibernate, it is a real cost, and the polling policy option is the tool for managing it.

Third, the README itself flags the token workflow as outside its control, and the docs contain no statement about long term support for either the token apps or the proxy add-on. The repository is a single maintained fork with versioned releases, v3.27.0 published on 2026-07-20 and v3.26.5 a few days earlier, but nothing in the documentation promises that the third-party pieces it depends on will keep working.

Editorial conclusion

tesla_custom fits Home Assistant users whose vehicles were dropped by the official integration and who can host the Tesla HTTP Proxy and accept the token workflow. It does not fit owners who want a vendor supported integration with a documented login path. Before installing, check whether your vehicles still work against the Owner API, because the README says most require the proxy, and decide on a `polling_interval` that leaves the car able to sleep.

Frequently asked questions

Official sources

1. alandtse/tesla on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases