nilsandClaude Opus 5.5
e52d7f01fc
Each check writes down the networks Android sees, the server's name lookup, how a failure happened and how many reports wait, and on a failure whether the internet answers at all, to tell a SIM without data from a server that is down. The report goes to a USB stick and, once online, the server. No address or token is written. Tried on the emulator. Not tried on the car. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LhzAVaUyqcw5PkGjz4mWW6
4.9 KiB
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'sLOGS_TOKENin~/.config/nilsmg4/logs-token(and ink8s/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_TOKENon the server) or the server is older than 2.9.0. The owner applies manifests and Secrets; never runkubectlagainst 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:
- Header: captures, start time, app version.
- Steering-wheel keys and notes. The first note says whether listening worked:
listening to N assistance properties (M refused), ornot possible (<reason>). - Assistance properties heard (
EVHardware.listenToPropertiesonAssistBlock, the0x21x0A1xxblock): change events, properties whose value changed first. This is where a value shows up that the head unit fills only while someone listens. - 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.
Sound checks
fetch-logs also brings sound-probe-YYYYMMDD-HHMMSS.txt (Logs tab, "Check sound",
SoundProbe, 2.43.3 on): permissions, which session plays, then one line a second of the audio
analyser's peak, bass, mid, treble and rms, and a result line. Levels only, no sound. The peak has
to move for music to count as heard. Ask what was playing when the check ran, and whether the
music kept playing and any prompt came up.
Update checks
fetch-logs also brings update-check-YYYYMMDD-HHMMSS.txt (each Settings → Check for updates,
UpdateHook, 2.43.5 on): the networks Android sees, whether the server's name resolves, the
result and, on a failure, whether www.gstatic.com/generate_204 answers (204: the internet
works, so look at the server). A report written offline arrives once the car is back online, or
is on a USB stick that was plugged in.
Rules
- Recordings and checks are the car's data:
logs/,/signal-recording-*.txtand/media-probe-*.txt,/sound-probe-*.txt,/update-check-*.txtare gitignored. Never commit, publish or upload them anywhere. - Findings that change what the project knows go into a
SPECS.mddone-log entry, as usual.