> ## Documentation Index
> Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Telemetry Dashboard

> The web application on the track machine: monitoring fleet battery health, viewing connection health, and driving the charging export.

The dashboard is the only part of Telemetry with a user interface, and the only way charging data leaves a track machine. It runs on the track machine on **port 4200** and does no work itself: every screen is a view over the [Exporter API](/software/developer/estate/systems/telemetry/exporter-api).

> [!NOTE]
>
> This is not the InfluxDB UI. InfluxDB serves its own interface on port 8086, which is where you go to see raw measurements. The dashboard shows named signals only, so a kart with nothing decodable looks blank here while being clearly busy there. See [Troubleshooting](/software/developer/estate/systems/telemetry/troubleshooting).

## The Three Screens

An Angular application, served by nginx, with three routes:

| Route | Screen | What it is for |
| - | - | - |
| `/` | Export Charging | The export workflow. The default screen, because exporting is the job that has to happen before the day is stopped |
| `/monitor-charging` | Monitor Charging | Live fleet battery health during the day |
| `/view-connections` | Connections Viewer | Connection health per kart over a window |

## How It Reaches The API

nginx serves the built application and proxies `/api/` through to `exporter_api:5432` inside the compose network. So the browser only ever talks to port 4200, and the API is not exposed to the track network by the dashboard.

> [!NOTE]
>
> Caching is disabled everywhere in that nginx configuration, for static files and proxied API calls alike, and proxy timeouts are set to a day. The long timeouts matter: an export of a full day of charging data is a single request that can legitimately take a very long time.

## Monitoring

The monitor screen ticks every second. It treats a kart as connected if it has been seen in the **last 60 seconds**, and each kart's battery tile comes from the API's stats endpoint, which looks back 15 minutes and flags data older than 2 minutes as stale rather than hiding it.

> [!NOTE]
>
> That distinction is deliberate and worth knowing when reading the screen. A kart showing values that are quietly out of date is a different fault from a kart showing nothing, and the API tells the dashboard which it is. See [Exporter API](/software/developer/estate/systems/telemetry/exporter-api#live-monitoring).

## Exporting

The export screen drives the whole export sequence, one API call per step, and it is the operator's responsibility to run it before the day is stopped. The steps and what each one does to the data are covered in [Charging Export](/software/developer/estate/systems/telemetry/charging-export).

> [!WARNING]
>
> Nothing exports automatically and nothing reminds anyone. InfluxDB is cleared when the day is stopped, so an export not done by hand before then means restoring that day's backup archive to recover it.

## What It Talks To Directly

The dashboard is not purely a client of the exporter API. It also calls the **TalentID API** from the browser, for events and for the sessions in an event, which is how the export screen knows what event a window belongs to.

> [!WARNING]
>
> That TalentID base URL and its API key are hard coded in the application's `environment.ts` and therefore compiled into the served bundle, where any viewer of the dashboard can read them. Treat that key as exposed, and rotate it if the dashboard is ever reachable beyond the track network.

## Regions

The region selector is populated from the API's `/regions` endpoint, which returns the machine's own region and the full list of regions it knows about. Both come from environment variables on the container, so a machine that is missing them fails that call rather than defaulting.

## Key Files

All paths are under `telemetry/telemetry-web-app/` in [can-wifi](https://github.com/Smedley-Group-Advanced-Technology/can-wifi).

| File | Role |
| - | - |
| `src/app/app.routes.ts` | The three routes |
| `src/app/components/pages/export-charging/` | The export workflow |
| `src/app/components/pages/monitor-charging/` | Live battery monitoring |
| `src/app/components/pages/connections-viewer/` | Connection health |
| `src/app/services/telemetry.service.ts` | Every call to the exporter API |
| `src/app/services/talent-id.service.ts` | The direct TalentID calls |
| `src/app/environment.ts` | API URLs and the TalentID key |
| `nginx.conf` | Static serving, the `/api/` proxy, and the caching and timeout settings |

## Related Documentation

| Page | Relevance |
| - | - |
| [Exporter API](/software/developer/estate/systems/telemetry/exporter-api) | Every endpoint the dashboard calls |
| [Charging Export](/software/developer/estate/systems/telemetry/charging-export) | What the export screen actually does to the data |
| [Internal Signals](/software/developer/estate/systems/telemetry/internal-signals) | The signals behind the connection and battery views |
| [Track Operations](/software/developer/estate/systems/telemetry/track-operations) | The machine it runs on |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.