mg4/.claude/skills/car-logs/SKILL.md

name, description

name	description
car-logs	Download the signal recordings the MG4 sent to the car server (fetch-logs) and read them. Use when the owner says a recording is on the server, asks to get, download or look at the car's logs or recordings, or after a test drive with the signal recorder.

Fetch and read the car's recordings

The app's signal recorder (Logs tab, SignalRecorder) sends each finished recording to the car server (LogOutbox, PUT /v1/logs/{name}); the server keeps the newest 200 (server/logs.go). fetch-logs in the dev shell downloads the ones not yet in logs/.

Fetch

nix develop -c fetch-logs

It prints each new file (logs/signal-recording-YYYYMMDD-HHMMSS.txt) and fetch-logs: N new. The token comes from ~/.config/nilsmg4/logs-token (the server's LOGS_TOKEN) and goes only in a header.

• Never print, cat or echo the token, and never pass it on a command line you show. Do not read the token file.
• no token: ask the owner to put the server's LOGS_TOKEN in ~/.config/nilsmg4/logs-token (and in k8s/secrets/secrets.yaml, then apply it). Do not create or fill it yourself.
• HTTP 401: the file and the server's Secret differ. HTTP 404: reading is off (no LOGS_TOKEN on the server) or the server is older than 2.9.0. The owner applies manifests and Secrets; never run kubectl against the cluster, not even read-only.
• 0 new: nothing arrived. In the car, the Logs tab says "Sent to the server." or how many wait and why (no server set up, server not reached, an HTTP status); the car retries every 2 minutes while the service runs.

Read

The files are plain text but file may call them data; search with rg -a. Newest first: ls -t logs/. If the owner said what they did and when (e.g. "ACC on at 08:50, set speed 100→90 at 08:51"), line those times up with the timeline.

A recording has four parts, in this order:

1. Header: captures, start time, app version.
2. Steering-wheel keys and notes. The first note says whether listening worked: listening to N assistance properties (M refused), or not possible (<reason>).
3. Assistance properties heard (EVHardware.listenToProperties on AssistBlock, the 0x21x0A1xx block): change events, properties whose value changed first. This is where a value shows up that the head unit fills only while someone listens.
4. Changed values (polled), rarest first, then Everything, in order: every capture (about every 5 s) with what changed since the last.

Useful cuts:

rg -a 'listening to' logs/<file>                                   # did listening work
awk '/^Assistance properties heard/,/^$/' logs/<file>              # what listening heard
rg -a 'A15B|A15A' logs/<file>                                      # one property's history
rg -a 'getLatestSpeed' logs/<file> | head                          # the car's speed over time

Known leads (SPECS.md, 2026-10-27): 0x2160A15B is AAD_EPTCCTRGTSPD, by its name the cruise control's target speed (0.0 when only polled); 0x2140A15A moved between 3 and 7; 0x2160A1A3/0x2160A1A4 counted up by 0.1. A value that tracks what the owner did at the times they name is a lead; say how sure it is, and that it is not confirmed until a second drive shows the same.

Music-sources checks

fetch-logs also brings media-probe-YYYYMMDD-HHMMSS.txt (Logs tab, "Check music sources", MediaProbe). Three parts: audio players (use, app, state), active media sessions with state and song (TITLE, ARTIST, ALBUM, ALBUM_ART as a size or ALBUM_ART_URI), and the media browser services by name (2.42.1 on; 2.42.0 also connected to them, which stopped the music). CarPlay's session is com.allgo.remoteui.mediabrowserservice, Bluetooth's com.android.bluetooth. Ask what was playing when the check ran.

Rules

• Recordings and checks are the car's data: logs/, /signal-recording-*.txt and /media-probe-*.txt are gitignored. Never commit, publish or upload them anywhere.
• Findings that change what the project knows go into a SPECS.md done-log entry, as usual.