|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Project Overview |
| 6 | + |
| 7 | +Python library (`tesla_fleet_api`) providing async interfaces for Tesla Fleet API, Teslemetry, and Tessie services, plus BLE communication. Published to PyPI as `tesla-fleet-api`. |
| 8 | + |
| 9 | +## Development Commands |
| 10 | + |
| 11 | +```bash |
| 12 | +# Install dependencies |
| 13 | +pip install -e . |
| 14 | + |
| 15 | +# Type checking (strict mode) |
| 16 | +pyright tesla_fleet_api |
| 17 | + |
| 18 | +# Linting |
| 19 | +ruff check tesla_fleet_api |
| 20 | +ruff format tesla_fleet_api |
| 21 | +``` |
| 22 | + |
| 23 | +No test suite exists in this repo. |
| 24 | + |
| 25 | +## API References |
| 26 | + |
| 27 | +- Tesla Fleet: https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-endpoints |
| 28 | +- Tessie: https://developer.tessie.com/llms.txt |
| 29 | +- Teslemetry: http://api.teslemetry.com/openapi.yaml |
| 30 | + |
| 31 | +## Architecture |
| 32 | + |
| 33 | +### Class Hierarchy |
| 34 | + |
| 35 | +Three API client classes all inherit from `TeslaFleetApi`: |
| 36 | + |
| 37 | +``` |
| 38 | +Tesla (base - tesla/tesla.py) |
| 39 | + └── TeslaFleetApi (tesla/fleet.py) - core HTTP client with _request(), access_token handling |
| 40 | + ├── TeslaFleetOAuth (tesla/oauth.py) - adds OAuth flow (login URL, token refresh) |
| 41 | + ├── Teslemetry (teslemetry/teslemetry.py) - fixed server, Teslemetry-specific endpoints |
| 42 | + └── Tessie (tessie/tessie.py) - fixed server, Tessie-specific endpoints |
| 43 | +``` |
| 44 | + |
| 45 | +`Tesla` base holds EC key management for signed commands. `TeslaFleetApi` provides the `_request()` method used by all submodules. |
| 46 | + |
| 47 | +### Vehicle Command Layers |
| 48 | + |
| 49 | +Vehicle commands have three implementations sharing the same method signatures, selected by how you create the vehicle: |
| 50 | + |
| 51 | +``` |
| 52 | +Vehicle (vehicle/vehicle.py) - base with VIN and model detection |
| 53 | + └── VehicleFleet (vehicle/fleet.py) - REST API commands (unsigned) |
| 54 | + └── VehicleSigned (vehicle/signed.py) - signed command protocol via Fleet API |
| 55 | +Commands (vehicle/commands.py) - protobuf-based signed command implementation (ABC) |
| 56 | + └── VehicleSigned - multiple inheritance: Commands + VehicleFleet |
| 57 | + └── VehicleBluetooth (vehicle/bluetooth.py) - BLE transport for signed commands |
| 58 | +``` |
| 59 | + |
| 60 | +`VehicleSigned` uses multiple inheritance: `Commands` for signed command logic, `VehicleFleet` for data endpoints and fallback. |
| 61 | + |
| 62 | +### Vehicle Collections |
| 63 | + |
| 64 | +`Vehicles` (vehicle/vehicles.py) is a `dict[str, Vehicle]` with factory methods: |
| 65 | +- `createFleet(vin)` → `VehicleFleet` |
| 66 | +- `createSigned(vin)` → `VehicleSigned` |
| 67 | +- `createBluetooth(vin)` → `VehicleBluetooth` |
| 68 | + |
| 69 | +Teslemetry/Tessie override `Vehicles` with their own vehicle classes (`TeslemetryVehicle`, `TessieVehicle`) extending `VehicleFleet` with service-specific commands (e.g., `closure()`, `seat_heater()` for Teslemetry; `wake()`, `lock()` for Tessie). |
| 70 | + |
| 71 | +### Submodule Pattern |
| 72 | + |
| 73 | +Each API client lazily attaches submodules in `__init__` via class attributes on `Tesla`: |
| 74 | +- `charging`, `energySites`, `user`, `partner`, `vehicles` |
| 75 | + |
| 76 | +Scope flags on `TeslaFleetApi.__init__` control which submodules are instantiated. |
| 77 | + |
| 78 | +### Error Handling |
| 79 | + |
| 80 | +`exceptions.py` maps HTTP status codes and error keys to specific exception classes. `raise_for_status()` parses responses and raises the appropriate exception. Signed command faults have separate hierarchies: `TeslaFleetInformationFault`, `TeslaFleetMessageFault`, `SignedMessageInformationFault`, `WhitelistOperationStatus`. |
| 81 | + |
| 82 | +All exceptions inherit from `TeslaFleetError(BaseException)`. |
| 83 | + |
| 84 | +### Protobuf |
| 85 | + |
| 86 | +Generated protobuf files live in `tesla/vehicle/proto/` and are excluded from ruff and pyright. Do not edit these directly. |
| 87 | + |
| 88 | +## Code Style |
| 89 | + |
| 90 | +- **Type checking**: pyright strict mode. Use `TYPE_CHECKING` guards for circular imports. |
| 91 | +- **Linting**: ruff (proto files excluded). |
| 92 | +- **Async**: All API methods are `async`. Uses `aiohttp` for HTTP, `aiofiles` for file I/O, `bleak` for BLE. |
| 93 | +- **Enums**: Custom `StrEnum`/`IntEnum` in `const.py` (not stdlib). `Region` is a `Literal["na", "eu", "cn"]`, not an enum. |
| 94 | +- **Naming**: camelCase for class instance attributes that mirror API structure (`energySites`, `createFleet`). Snake_case for method names that are API endpoints. |
0 commit comments