The read-only token for Grafana needed a manual influx command and a
Secret. InfluxDB generates every token but the admin one and ignores a
chosen value (tested on 2.7.12), so it cannot be preset in a Secret.
Instead an init container in the Grafana pod creates it at every start
with the admin token, deletes the one from the previous start, and
writes only the read-only token to a memory-backed volume; the
provisioned datasource reads it with $__file{/run/influx/token}. The
Grafana process never sees the admin token. The grafana-influx Secret
is gone from the template and the README.
Tested in podman: InfluxDB 2.7.12, the script run twice as the Grafana
user (the old token is replaced, not piled up), and Grafana 13.2.3
reporting the datasource healthy with the file-based token.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
The car updates itself again, from this fork's own releases, while the
repository stays private:
- publish-car (flake) creates the pre-release car-<version> on the
forge and attaches the APK and its .sha256. It needs a forge token
that may write releases, from ~/.config/nilsmg4/forge-token or
$FORGE_TOKEN; it is sent in a header and never printed.
- The server relays releases and attachments (/v1/app/releases,
/v1/app/assets/...), read with a read-only FORGE_TOKEN from its
Secret, GitHub-shaped with download URLs back at itself. Redirects
away from the forge are not followed; off (404) without a token.
- The app asks its server with its own paired token, allows exactly
the server's host, downloads the APK itself instead of through the
DownloadManager (so the token stays in the app), verifies SHA-256 and
package name, and tries a PackageInstaller session (it may install
silently as the system user) before falling back to Downloads.
OTA.md is rewritten for this flow; the k8s and server READMEs explain
the new token.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
The car sends live data to ABRP itself, and the car and the server go
over the same mobile connection: when the car cannot reach ABRP, it
cannot reach the server either, so the server's fallback bought
nothing. The forwarder, its ABRP_* settings and abrpSentUtc are gone;
the server only stores. The app stops sending abrpSentUtc (the server
ignores unknown fields, so 2.11.0 keeps working) and its texts no longer
promise a server fallback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
ABRP keeps getting live data while the car server is down: with an ABRP
API key and user token set in the app (Live data tab, or abrp_api_key /
abrp_token in the config file), the car sends the newest sample to ABRP
itself at every upload. It tells the server the newest sample ABRP took
(abrpSentUtc), and the server forwards only newer ones, so ABRP gets
each sample once. Without credentials in the app the server forwards
everything, as before. The credentials sit in encrypted storage, go in
the request body, and neither they nor ABRP's answer are logged.
Settings are grouped by what they are for:
- Live data (was Upload): on/off, ABRP credentials, upload frequency.
- Settings (replaces the Wi-Fi tab): full screen and voice key,
usable capacity and manual SoH (were on Consumption), charging price
(was on Charging), Wi-Fi.
Charging and Live data get icons of their own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
Telemetry no longer loses queued batches. The server drops a bad value,
or a sample without a plausible time, instead of rejecting the batch,
and answers 200 with what it dropped. The app sends only values inside
the server's ranges (speed as a magnitude, so reversing is fine) and no
samples before the head unit's clock is set.
Server:
- Pairing hands out and accepts a token only after the device is saved;
a failed save leaves the request pending.
- A paired token serves only the installation id it was paired with
(403 otherwise); the shared INGEST_TOKEN still serves any.
- Wrong-password lockouts and open pairing requests are limited per
client address (last X-Forwarded-For entry), so a stranger cannot
lock the owner out; a car starting again replaces its own request.
- ABRP forwarding skips samples stamped ahead of the server's clock,
which used to stop it until a restart.
App:
- Settings written to plaintext during a keystore failure move back
into encrypted storage; the stored installation id wins.
- The installation id is derived from ANDROID_ID on first start, so a
reinstall finds its history; a stored or imported id still wins.
- The scanned config file is deleted after import (it holds the token).
- GPS stops while live telemetry is off or the server unconfigured, and
pauses while parked and idle, keeping the fix the car parked with.
- Range estimates use the monotonic clock.
- One HTTP helper (ServerHttp) for telemetry, sync and pairing.
- Last Turkish strings translated; mise logs shows the NilsMG4 tags.
Grafana reads InfluxDB with its own read-only token (new grafana-influx
Secret, created by hand as described in k8s/README.md).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
- The secrets template moves to k8s/secrets/, and the filled-in copy to
k8s/secrets/secrets.yaml (gitignored). `kubectl apply -f k8s/` does
not recurse, so neither the placeholder template nor the real secrets
can be applied by accident.
- The server image digest is pinned in server.yaml instead of through
kustomize's images override, which `-f` ignores (it would have pulled
a nonexistent :latest).
- README and kustomization.yaml say to use `-k`: plain `-f` never
creates the generated Grafana ConfigMaps.
- The IngressRoutes drop `tls: {}`, like the other routes on this
Traefik: TLS is configured on the websecure entrypoint.
Manifests validated both ways (14 resources rendered with kustomize,
11 as plain files — the difference is the Grafana ConfigMaps).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
- On a failure the pairing dialog stays open and shows the reason in
red (Cancel becomes Close); before, it closed at once and the reason
was only in the Server tab's status line.
- "Pairing is not enabled" only when the server says so. Any other 404
(a server older than 2.1.0, or a proxy's page) is reported as a
server without pairing.
- Pairing and Test connection name the problem: a server name that
does not resolve (Test connection used to say "No internet
connection"), a server that does not answer, or the HTTP status.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
nilsandClaude Opus 5.5