The badge and latest stable release link update automatically. Native vehicle software push, charging Live Activities, and navigation Live Activities are optional and remain disabled until a compatible My T build supplies a secure relay pairing.
My T: the public App Store downloadable version is whatever Apple’s listing shows. A newer My T build may be in App Review; this repo does not hard-code or claim a private review version. Parking timeline, observed events, trajectories, and destination-session history work when the App can reach
/api/v1/capabilities; push and Live Activities still need pairing. See My T feature availability.
This companion is built specifically for the My T iPhone app — download it from the App Store. Install My T first if you are looking for the app that uses these enhanced TeslaMate features.
Need to deploy the server stack? Download HostBox on the App Store. Its product guide and launch video cover guided VPS deployment from iPhone.
For the complete My T product overview, TeslaMateAPI setup, connection security, and troubleshooting, see the My T documentation repository. For help with this component, see SUPPORT.md.
This optional, standalone service adds complete TeslaMate vehicle-state history, retained parking-event observation (plug, charging, security, climate), and reliable live-drive trajectories to My T. Parking monitoring and live navigation use the same container, authentication, installer, and update command. It reads the existing TeslaMate PostgreSQL database without changing TeslaMate or creating tables.
TeslaMate remains the source of truth. Database-backed history is never duplicated, deleted, or rewritten. Starting with 1.9.2, the companion also stores a small local event log for genuine MQTT transitions that TeslaMate does not preserve historically, such as a cable being connected before charging. The first retained value after install or restart is baseline-only and never becomes an event. Event timestamps mean “first observed by TeslaMate/Companion,” not a promised physical-action timestamp. The event log is kept long-term by default, with a 50,000-event capacity guard, in the existing companion data volume. Temporary navigation and push-delivery state expires independently. See DATA_LIFECYCLE.md.
After secure pairing, each iPhone can also opt into a notification when a vehicle is observed locked and unoccupied. The server-wide choices are defaults for every vehicle. A compatible My T build can independently override every notification category for a named vehicle; new vehicles inherit the defaults. Changing the vehicle selected in My T never changes server-side notification scope. Companion sends only the signed event; the visible alert sound is selected locally on that iPhone. Imported audio, filenames, and the silent/default choice never reach Companion.
Each iPhone can independently opt into a low-battery alert for every vehicle on that paired TeslaMate server, or override that category for individual vehicles, when it is parked, not charging, and strictly below 20 percent. The first complete retained MQTT snapshot is baseline-only, the episode rearms at 25 percent, and a fall below 10 percent can issue one stronger escalation. My T offers acknowledge or one four-hour snooze; action state stays on that user's VPS and is scoped to the responding installation. Companion uses only TeslaMate-reported MQTT values and never wakes or polls the vehicle.
If a relay is temporarily unavailable or ActivityKit has not registered the
session token yet, Companion keeps only the minimum signed event in its local
0600 data store and retries it. Retry rows expire by event type (10 minutes
to 24 hours), are capped at 256 total, and are removed on delivery, pause, or
unpair. This temporary queue remains on the user's VPS; it is not copied into
the developer relay's delivery audit.
Install this add-on after TeslaMate is already deployed and working. It is not a replacement for TeslaMate or TeslaMateAPI.
| Path | Who | What happens |
|---|---|---|
| HostBox (recommended for most phone users) | iOS deploy app on the App Store | Installs TeslaMate + TeslaMateAPI + this companion, tries to wire a unified entry (edge on temporary IP, or Tunnel paths), MQTT host.docker.internal, and health checks. You still paste one base_url + Token into My T. See the product guide. |
| Self-install (this repo) | You run Docker / install.sh |
Follow the verified release install below, then ensure gateway routes (see ports table). Same My T connection rules. |
HostBox is the deploy layer; My T is the car UI. Neither app replaces the other.
My T is an iPhone client for viewing data stored on the user's own TeslaMate server. Standard TeslaMate and TeslaMateAPI endpoints remain sufficient for most trips, charging sessions, statistics, and current vehicle information.
Three My T experiences need more precise server-side data:
- Enhanced parking history needs the complete sequence of recorded
online,offline, andasleepintervals, plus real battery/range samples on both sides of each transition. A phone cannot reconstruct events that happened while the app was closed. - Live navigation during an active drive needs TeslaMate's immutable first GPS point and incremental trajectory points. The position visible when My T opens must never be presented as the true trip start.
- Parking events (plug/unplug, charging, Sentry, lock/doors, climate) need an always-running observer. iOS cannot reliably collect them while My T is suspended. Companion 1.9.2+ retains genuine MQTT transitions that TeslaMate does not keep as history.
This companion provides only those missing read-only capabilities. It keeps
TeslaMate as the source of truth and lets My T automatically enable enhanced
views when /api/v1/capabilities is available.
| My T feature | Without the companion | With the companion |
|---|---|---|
| Trips, charging, statistics | Normal TeslaMate API data | Unchanged |
| Basic parking history | Available from ordinary trip/parking records | Unchanged |
| Sleep and wake timeline | May be incomplete; My T does not estimate missing events | Full TeslaMate-recorded state sequence |
| Parking battery/range change | Shown only when real observations already exist | Real transition-boundary observations within 30 minutes |
| Charging while parked | Existing charging sessions remain visible | Charging can be placed alongside the state timeline |
| Plug/security/climate events | No durable history while My T is closed | Long-term genuine MQTT transitions, with battery/range only when reported |
| Active-drive map | Real current position and speed only when the true route start is unavailable | Immutable true start plus incremental real trajectory |
| Locked-and-unoccupied alert | No server-side observation while the App is suspended | Optional per-iPhone signed event; My T applies the visible message and device-local sound |
| Parked low-battery alert | No server-side observation while the App is suspended | Optional per-iPhone alert below 20%, one severe escalation below 10%, and acknowledge/four-hour snooze actions |
The component is optional. My T detects it automatically; users do not add a second server, account, or vehicle connection in the app.
The companion works with a TeslaMate database hosted on a LAN, but My T must
reach TeslaMateAPI and the companion through one unified base URL. My T
checks /api/v1/capabilities on the same server address already configured for
TeslaMate; it does not require or expose a second companion address.
| LAN setup | Result |
|---|---|
| TeslaMateAPI and companion are routed through the same Caddy/Nginx/Traefik gateway address | Supported |
| My T connects to a host-mapped TeslaMateAPI port with no reverse proxy / gateway | Basic TeslaMate features work; companion is not reachable |
| Access through a VPN, Tailscale, or another private network using one reverse-proxy address | Supported |
| Port | Meaning |
|---|---|
| 8080 (container) | TeslaMateAPI listens inside the container; compose right-hand side is usually :8080. |
| Host map (example 8080 or 8081) | Whatever you publish on the host for TeslaMateAPI (e.g. 8081:8080 or 8080:8080). HostBox defaults to host 8081. Docs that say “8080” usually mean “the host port you chose,” not a magic constant. |
| 8083 | Companion on the host, bound to 127.0.0.1 only. Never give My T a second base URL for 8083. |
My T always uses one base URL (the gateway or unified entry). Port 8083 intentionally remains bound to 127.0.0.1 and must not be exposed
directly to the LAN or Internet. If My T currently points at a bare host API port
(e.g. http://LAN-IP:8081 with no proxy), first add a reverse proxy / gateway that
sends the companion routes to 127.0.0.1:8083 and ordinary TeslaMateAPI routes to
the internal API address (often 127.0.0.1:<host-api-port> or 127.0.0.1:18081 when the gateway took over the public host port). Then set My T to that single gateway URL.
The supplied Caddyfile.snippet contains the required companion routes.
The installer can update a recognized system Caddy configuration or a
compatible TeslaMate containerized Caddy automatically. System gateways route
to loopback 127.0.0.1:8083; containerized Caddy is accepted only after the
installer verifies the shared Docker network, then routes directly to
companion:8080. Nginx, Traefik, an unrecognized container proxy, or a custom
LAN gateway remains unchanged and requires the administrator to add the
routes. Installation of the container alone does not make the enhanced
features reachable from My T.
This does not change the deployment method — only the usual order people follow:
- TeslaMate + TeslaMateAPI — My T uses
http://IP:host-api-port(or HTTPS if you already have a reverse proxy). Basic car data works. - Companion — keep the same My T base URL. A unified entry (system Caddy,
Caddyfile.snippet, or the installer edge) must send companion paths to127.0.0.1:8083and the rest of/api/*to stock TeslaMateAPI. Token does not change. - Cloudflare Tunnel (optional security) — My T switches base URL to
https://your-hostname. Tunnel is the new unified entry; path split stays the same idea as Caddy (Caddyfile.snippetpaths →8083, otherapi/*→ stock API host port).
When stage 2 used an edge on the public API port (API often moved to loopback 18081), stage 3 must finish the handoff so there is only one public entry:
| Do | Why |
|---|---|
Point Tunnel companion paths at http://127.0.0.1:8083 |
Same routes as Caddyfile.snippet |
Point Tunnel other api/* at the port where TeslaMateAPI actually listens (commonly restore stock 127.0.0.1:8081 or 8080, not a dead public edge) |
Wrong target → My T HTTP 502 |
Stop / remove the temporary-IP edge so it does not keep port 8081 |
Two entries fight for the same port |
In My T, use https://hostname (not http://IP:8081) |
Outer security layer changed; token stays the same |
Clean target after Tunnel (matches the documented “one base URL” contract):
https://hostname
├─ companion paths → 127.0.0.1:8083
└─ other /api/* → 127.0.0.1:<stock-api-host-port> # e.g. 8081
Vehicle → TeslaMate → PostgreSQL
│ read-only Docker network
▼
My T Companion
│ existing HTTPS/API authentication
▼
My T App
- Tesla account authorization remains entirely inside TeslaMate.
- My T Companion never connects to Tesla or wakes the vehicle.
- My T does not send vehicle history through a developer-owned cloud service.
- Data travels between the user's own VPS and iPhone through the user's existing secured API hostname or private network.
| Item | Created or changed? | Purpose |
|---|---|---|
| A standalone Docker service and container | Yes | Runs the read-only companion API |
A loopback listener on 127.0.0.1:8083 |
Yes | Keeps the service behind the existing protected reverse proxy |
| Companion reverse-proxy routes | Yes | Makes capability, parking-state/event, current-drive, and notification endpoints available through the My T base URL |
| Installer configuration and recovery backups | Yes | Supports repeatable updates, rollback, and uninstall |
| A new database or TeslaMate table | No | TeslaMate PostgreSQL remains the only source of truth |
| A duplicate vehicle-history store | No | The companion queries data only when My T requests it |
| TeslaMate data changes or vehicle commands | No | Database sessions are read-only and the service never connects to Tesla |
The service reads only the TeslaMate states, drives, and positions data
needed for its endpoints. It returns derived JSON state intervals, nearby real
battery/range observations, the current drive's immutable first point, and
incremental trajectory points. It does not run a background collector or define
its own retention period; available history follows the TeslaMate database.
| Companion version | Capability added |
|---|---|
| 1.10.43 | Nonblocking ordered parking-event capture with coalesced durable snapshots and graceful-shutdown flush |
| 1.10.39 | Source-scoped charging, navigation, and Lock Secure delivery plus collision-safe Live Activity sessions |
| 1.10.38 | Four named-door history/status, active-parking observations, source-scoped software updates, and route repair |
| 1.10.37 | Per-iPhone all-vehicle defaults plus category-specific vehicle overrides; paused-phone capacity recovery |
| 1.10.36 | Server-scoped all-car push subscriptions with automatic migration of obsolete selected-car filters |
| 1.10.35 | low_battery_push: parked/not-charging low-battery alerts with per-iPhone acknowledge and four-hour snooze |
| 1.10.33 | Immediate corrected trip-origin delivery when TeslaMate resolves the authoritative start after the navigation card begins |
| 1.10.32 | Continuous verified destination-navigation distance refresh, with immediate first-progress delivery to remote Live Activities |
| 1.10.31 | Privacy-minimal anonymous vehicle count and first/last-seen reporting, scoped per Companion rather than per phone |
| 1.10.30 | Authoritative TeslaMate trip origins and targeted catch-up when one iPhone enables an active charging or navigation Live Activity |
| 1.10.29 | Live TeslaMate version probing with explicit source/time metadata and safe fallback to install metadata |
| 1.0.0 | Read-only parking state-history endpoint |
| 1.1.0 | Existing TeslaMate API authentication boundary |
| 1.2.0 | Timestamped, freshness-limited battery and rated-range observations |
| 1.3.0 | Immutable current-drive start and incremental trajectory paging |
| 1.4.0 | Capability discovery, hardened container/database access, safe install and uninstall |
| 1.4.1 | Checksummed release updates, rollback backups, unified-route verification, and broader LAN/proxy guidance |
| 1.5.0 | MQTT software-update detection, persistent deduplication, signed relay delivery, and authenticated status |
| 1.5.1 | Patched MQTT and Go networking dependencies; no API or deployment changes |
| 1.6.1 | Automatic charging Live Activities with true percentage/range, power, and completion updates |
| 1.7.0 | Proactive destination-navigation Live Activities with verified drive progress |
| 1.7.1 | Full-snapshot token recovery, immediate catch-up, and trailing navigation updates |
| 1.9.3 | Long-term bounded parking events, repeated-pairing stability, log rotation, and resource limits |
| 1.10.0 | Backup/restore lifecycle and bounded temporary delivery state |
| 1.10.2 | App compatibility metadata, official push domain, and secure unpairing |
| 1.10.4 | Persistent destination-navigation session history with real trip timing |
| 1.10.5 | Push-history route/deadlock repair |
| 1.10.6 | Separate closed sessions when the destination changes mid-drive |
| 1.10.7 | Genuine start-place name for start → destination trip titles |
| 1.10.8 | Reliable start_name (sticky geofence + drive address backfill) for start → destination |
| 1.10.10 | Correct runtime version reporting in capabilities and diagnostics |
| 1.10.19 | Reliable upgrades when saved MQTT settings no longer match the live Docker topology |
| 1.10.28 | Official-relay pinning, redirect refusal, bounded navigation history, and synchronized trilingual compatibility documentation |
| 1.10.27 | Durable per-iPhone push outbox, installation-specific preferences, invalid-device isolation, and stricter database/network timeouts |
Version 1.7.0 observes TeslaMate's genuine MQTT active route and driving state. A compatible My T build can automatically start, update, and end a destination card on the Lock Screen and Dynamic Island while the App is not open.
The card receives destination, remaining distance/time, estimated arrival, vehicle-reported arrival battery, and progress verified against the current TeslaMate drive. The relay does not receive coordinates, trajectory, VIN, TeslaMate credentials, or vehicle history. Missing values are omitted rather than estimated.
Without this companion, My T's ordinary in-App destination card, live vehicle position, and speed continue to work. The genuine route start, traveled trajectory, complete-route progress, and proactive Live Activity require a paired companion.
Authenticated status:
GET /api/v1/notifications/navigation-live-activity/status
Version 1.6.1 observes genuine TeslaMate MQTT charging state, battery percentage, rated range, charge limit, power, and remaining time. A compatible My T build can therefore show and update a Lock Screen/Dynamic Island charging card even when the App is not open.
Routine updates are coalesced to a minimum 45-second interval; charging at
50 kW or above uses a 15-second interval. The signed
payload contains only the fields required by the card. It excludes VIN,
location, routes, TeslaMate credentials, and kWh. Range gain is calculated only
when genuine TeslaMate start/current rated_battery_range_km observations are
available; missing kilometers are omitted rather than estimated.
Authenticated status:
GET /api/v1/notifications/charging-live-activity/status
Version 1.5.0 observes TeslaMate's genuine MQTT update_available,
update_version, and installed-version fields. It does not guess availability,
contact Tesla, or wake the vehicle.
Push is off by default. A compatible My T build will provide an opaque installation ID, the official HTTPS relay URL, and a unique per-installation secret. All three must be configured together. Events are HMAC-SHA256 signed and deduplicated across container restarts. The App writes the pairing through the user's existing authenticated connection. Preferences and status are scoped to that iPhone's installation ID:
POST /api/v1/notifications/software-update/pair
From 1.10.37, a compatible App may include the optional vehicle_preferences array. Each item contains one positive TeslaMate car_id and a complete set of category switches. Cars not in that array use the top-level all-vehicle defaults. Omitting the field preserves any stored overrides so an older App cannot erase settings it cannot display; sending an empty array explicitly removes all overrides.
For SSRF protection, the Companion accepts only My T's official relay URL.
Payloads never contain VIN, location, TeslaMate credentials, database passwords, battery data, routes, or driving history. The APNs signing key is not part of this repository and must never be copied to a user's VPS. Pairing is automatic after the user enables notifications in My T; parking and live navigation continue to work normally if push remains disabled.
The official relay is used because Apple Push Notification service does not accept notifications directly from an arbitrary user VPS without an App-owned APNs credential. It stores the APNs device token and an opaque installation identifier needed for delivery, and receives only the privacy-minimal software-update event documented above. Each VPS signs its own events; one installation cannot send notifications for another installation.
When push is paired, Companion also reports an anonymous inventory for operator counting. It generates and keeps a random namespace in its own data volume and HMAC-derives one stable alias for every TeslaMate car on the paired server. The relay retains only the alias and first/last seen times; it does not persist the alias together with an installation ID and does not receive a raw car ID, vehicle name, VIN, server address, Apple ID, phone identity, location, route, telemetry, software version, or notification content for this statistic. The same car therefore counts once across multiple paired iPhones on that Companion.
Authenticated status:
GET /api/v1/notifications/software-update/status
See CHANGELOG.md for complete changes or the latest GitHub Release.
Install it when all of the following are true:
- You use My T with a self-hosted TeslaMate connection.
- You want reliable long-term parking sleep/wake review or the complete active-drive trajectory.
- You control the TeslaMate Docker host and can run a
sudocommand. - Your TeslaMate API is already protected by HTTPS/VPN and authentication.
You do not need it when using My T only with Tessie, when basic trip/charge/statistics views are enough, or when you cannot administer the TeslaMate server. Installing it does not improve TeslaMate collection quality; it can only return observations TeslaMate actually stored.
Installation uses a numbered GitHub Release rather than the mutable main
branch. With GitHub CLI installed:
version="$(gh release view -R MatchHar/My-T-Companion --json tagName --jq '.tagName | ltrimstr("v")')"; workdir="$(mktemp -d)" && gh release download "v$version" -R MatchHar/My-T-Companion -D "$workdir" && (cd "$workdir" && sha256sum -c "my-t-companion-$version.tar.gz.sha256") && tar -xzf "$workdir/my-t-companion-$version.tar.gz" -C "$workdir" && sudo "$workdir/my-t-companion-$version/install.sh"; status=$?; rm -rf "$workdir"; exit $statusOfficial release archives and checksum files also carry GitHub build provenance. Before installation, an operator can independently verify a downloaded file with:
gh attestation verify my-t-companion-X.Y.Z.tar.gz \
--repo MatchHar/My-T-Companion \
--signer-workflow MatchHar/My-T-Companion/.github/workflows/release.ymlWithout GitHub CLI:
version="$(curl -fsSL https://api.github.com/repos/MatchHar/My-T-Companion/releases/latest | sed -n 's/.*"tag_name": *"v\([^"]*\)".*/\1/p')"; test -n "$version" && workdir="$(mktemp -d)" && base="https://github.com/MatchHar/My-T-Companion/releases/download/v$version" && curl -fL "$base/my-t-companion-$version.tar.gz" -o "$workdir/my-t-companion-$version.tar.gz" && curl -fL "$base/my-t-companion-$version.tar.gz.sha256" -o "$workdir/my-t-companion-$version.tar.gz.sha256" && (cd "$workdir" && sha256sum -c "my-t-companion-$version.tar.gz.sha256") && tar -xzf "$workdir/my-t-companion-$version.tar.gz" -C "$workdir" && sudo "$workdir/my-t-companion-$version/install.sh"; status=$?; rm -rf "$workdir"; exit $statusFull success is reported only after both the local service and the unified My T proxy route are verified. Manual Nginx, Traefik, and unrecognized container proxy setups must add and verify the supplied routes.
The installer keeps My T connection setup unchanged. My T Companion reuses the
authentication already accepted by the existing TeslaMate API reverse proxy,
including Bearer token, Basic authentication, X-API-Token, and Cloudflare
Access service-token headers. There is no second credential to enter in My T.
The installer detects the existing API hostname and uses its normal protected
/api/ping route to validate requests. Future updates use the installed,
checksummed updater described below.
The command is interactive only when the server needs sudo authentication.
It detects the TeslaMate database container/network, reuses the existing
database and API credentials, and creates backups before proxy changes.
The installer automatically edits a system Caddy configuration when it can identify the existing protected API route. It can also edit a TeslaMate Docker Caddyfile when Caddy shares the detected TeslaMate network, without widening the host's loopback-only 8083 binding. Nginx, Traefik, unrecognized container proxies, and custom TeslaMate layouts require the supplied routes to be added manually. The installer stops with an actionable error instead of guessing.
- Real
online,offline,asleep, and other state intervals recorded by TeslaMate. - Real battery percentage and rated-range observations immediately before a state begins and after it ends.
- Boundary telemetry includes its real observation timestamp and is returned only when sampled within 30 minutes of the state transition. Older values are left unknown rather than being presented as sleep/wake consumption.
- A capability endpoint so My T can distinguish “not deployed” from “no events”.
- No estimated wake events or estimated battery consumption.
- PostgreSQL sessions are forced into read-only transaction mode, even though the existing TeslaMate database credential is reused.
- The current TeslaMate drive ID, its immutable earliest real GPS point, and timestamped real trajectory points.
- Incremental trajectory paging with
afterPointId, so a phone can resume the same drive after reopening without repeatedly downloading the full route. - Explicit
waiting_for_positionswhen TeslaMate has opened a drive but has not stored a valid point yet. The service never substitutes the phone-open vehicle location as the trip start. - Future observed history for each named door and window, plus last observed lock/door/window values without waking a sleeping vehicle.
GET /api/v1/capabilitiesGET /api/v1/cars/{car_id}/states?startDate=...&endDate=...GET /api/v1/cars/{car_id}/parking-events?startDate=...&endDate=...GET /api/v1/cars/{car_id}/companion-statusGET /api/v1/cars/{car_id}/navigation/current-drive?afterPointId=0&limit=5000GET /api/v1/cars/{car_id}/navigation/push-historyGET /api/healthz
All data and capability endpoints require the same authentication used by the
TeslaMate API connection. /api/healthz contains no vehicle data and is
available only on the loopback-bound service port.
- A working Docker Compose TeslaMate installation under
TESLAMATE_DIR(default/opt/teslamate). - Database password available as
DATABASE_PASS(orPOSTGRES_PASSWORD) from any of: shell export,docker compose config, a running DB/API container, or optional$TESLAMATE_DIR/.env. A.envfile is not required. - Prefer service name
databasefor Postgres; the installer also triesdb/postgresand can setDATABASE_HOSTfrom discovery. - Same API bearer token as TeslaMateAPI (
API_TOKEN/MY_T_API_TOKEN) when My T uses Bearer auth. - Gateway routes so My T keeps one base_url (see
Caddyfile.snippet).
# From a release extract or git checkout of this repo:
sudo TESLAMATE_DIR=/opt/teslamate ./install.sh
# Optional overrides when auto-discovery is incomplete:
# sudo DATABASE_PASS=… API_TOKEN=… MQTT_BROKER_URL=tcp://mosquitto:1883 ./install.shThe installer builds the companion, joins the TeslaMate Docker network, and
tries to wire a unified entry (system Caddy, docker Caddyfile, or API-port edge).
Gateway snippets must include all Companion paths under
/api/v1/notifications/* (software-update and Live Activity status), not
only parking/navigation routes.
- Copy this directory next to your TeslaMate stack (or use
/opt/my-t-companion). - Merge
docker-compose.snippet.ymlunderservices:if you prefer a hand-written compose layout. - Apply
Caddyfile.snippet(ornginx.snippet.conf) before the general TeslaMateAPI route. - Start with
docker compose up -d --build.
Keep port 8083 bound to 127.0.0.1. Do not expose it directly to the public
Internet.
The installed container runs as an unprivileged user with a read-only root
filesystem, all Linux capabilities removed, no-new-privileges, and an
authenticated reverse-proxy boundary.
curl --fail http://127.0.0.1:8083/api/healthz
curl --fail \
-H "Authorization: Bearer ${MY_T_API_TOKEN}" \
http://127.0.0.1:8083/api/v1/capabilitiesThe first response should report OK. The second should include
parking_state_history, state_boundary_battery, and
state_boundary_rated_range, and current_drive_trajectory.
The permanent command below follows GitHub's latest stable Release (drafts and prereleases are excluded), downloads that numbered archive, verifies its SHA-256 manifest, and backs up the existing installation before applying it:
sudo /opt/my-t-companion/update.shMy T may instead show a version-pinned command such as
sudo MY_T_VERSION=<verified-version> /opt/my-t-companion/update.sh. That is intentional:
the App pins the newest Companion version verified with that App build, while
the permanent command is for administrators who explicitly want the newest
stable server release.
Trusted deployment tools may additionally set
MY_T_EXPECTED_SHA256=<signed-catalog-digest>; the updater then rejects an
archive even when its separately downloaded release manifest also changed.
The service has no private SQL database or migration. Its bounded local state volume keeps parking observations and push-delivery state; updating it does not alter TeslaMate data.
For installer-managed deployments:
sudo /opt/my-t-companion/uninstall.shThe command removes the standalone container and installer-owned Caddy routes,
but preserves /opt/my-t-companion for recovery. Manually configured
custom reverse proxies must have the supplied companion routes removed manually.
TeslaMate continues to operate normally because this add-on is independent.
See COMPATIBILITY.md for the tested release matrix. The installer intentionally fails closed on unknown layouts. A manual Compose and reverse-proxy deployment remains available for advanced installations.
Review SECURITY.md before exposing the API through a public
hostname. Never include .env, database passwords, API tokens, Cloudflare
service tokens, or private keys in an issue.
For an offline interval, start_telemetry is the last observation at or
before sleep and end_telemetry is the first observation when TeslaMate sees
the car again. Their difference is therefore an observed parking consumption,
not a calculated estimate. An ongoing sleep has no end observation until the
vehicle wakes.
My T checks /api/v1/capabilities. If the add-on is unavailable, the app keeps
the normal TeslaMate features working and explains that complete long-term
parking wake history requires this optional VPS deployment. It does not invent
missing events or battery consumption.
The live-navigation module follows the same rule. Without this capability, My T can fall back to the standard TeslaMate API, but it must label a route as partial when the real first point is unavailable. It must not promote the vehicle location observed when the app opens into a “true start”.
The source in this repository is public under the MIT License. It may be self-hosted, modified, and redistributed under that license. My T iOS source, the developer-operated relay implementation and APNs provider credentials, HostBox app and deployment source, and the HostBox catalog signing private key are separate private components and are not included in this repository.
The MIT license does not make a fork an official My T or HostBox release. Redistributed forks should use distinct product branding and must not use the My T or HostBox names, icons, or presentation in a way that implies endorsement or an official build.
This is an independent companion project designed for My T. It is not affiliated with or endorsed by Tesla, Inc., the TeslaMate maintainers, or the TeslaMateAPI maintainers. It does not contain Tesla credentials, issue vehicle commands, wake a vehicle, or replace the official TeslaMate deployment.
No. Queries run in PostgreSQL read-only transaction mode. Companion has no SQL database or migrations. Its background MQTT observer writes only the bounded local event state described in DATA_LIFECYCLE.md.
It can show old events that still exist in TeslaMate's states table. It
cannot recover observations that TeslaMate never recorded or that were removed
by the user's retention policy.
No. It reads the database only and never calls Tesla vehicle-control APIs.
Normally no. The installer reuses the existing TeslaMate API hostname and authentication. My T detects the capability endpoint automatically.
Yes. The companion is a separate Compose project. The uninstall script removes its container and installer-managed proxy routes while preserving TeslaMate and its database.