Kalibrierung und Einbaulage gehören in den Sensor, nicht in die Apps

Die Kalibrier-Nullpunkte lagen schon immer im ESP und wurden dort auch
abgezogen – nur verriet die Firmware sie niemandem. Die Einbaulage lag
dagegen in jeder App einzeln, und damit stand sie bei drei Endgeräten
dreimal da, im Zweifel dreimal verschieden. Sie beschreibt aber den
Einbau und nicht das Telefon.

Zwei neue Charakteristiken:

    ...3426  Nullpunkte, zwei Floats, nur lesen
    ...3428  Einbaulage, acht Byte, lesen und schreiben

        0      Version, 1 = gültig gesetzt, 0 = nie geschrieben
        1      Längsachse: 0 = Pitch des Sensors, 1 = Roll
        2      längs umgekehrt (0/1)
        3      quer umgekehrt (0/1)
        4..7   Verdrehung um die Hochachse, float32, Grad

Das Versionsbyte löst die Umstellung: Steht dort 0, hat nie jemand
geschrieben – dann gilt weiter, was die App örtlich gespeichert hat, und
beim nächsten Bestimmen wandert sie hinauf. Mit älterer Firmware ohne die
Charakteristik passiert schlicht nichts.

Angewandt wird die Lage weiterhin in den Apps. Der Sensor verwahrt sie
nur: Meldete er die Winkel bereits umgerechnet, rechnete jede ältere App
die Korrektur ein zweites Mal ein.

Beim Verbinden liest jede App die Lage und übernimmt sie; nach dem
Einbaulage-Assistenten schreibt sie sie hinauf. Die Uhr braucht das
iPhone dafür nicht mehr – sie holt sie sich selbst. Die Android-App
bekommt dabei auch die Verdrehung, die ihrer Fassung bisher ganz fehlte:
Modell, Erkennung und Persistenz nachgezogen.

Geprüft: Firmware übersetzt, im erzeugten Code stehen beide
Charakteristiken mit den richtigen Rechten und der Schreib-Handler;
iPhone- und Watch-Ziel bauen; sieben neue Prüfungen in run-tests.sh
nageln das Byte-Format fest, samt Rundlauf und der Bedeutung von
Version 0. Nicht geprüft ist die Android-Fassung: Auf dieser Maschine
liegt nur Java 8, Gradle verlangt mindestens 11.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -188,6 +188,33 @@ um die Hochachse steckt darin nicht – eben sieht in jeder Verdrehung gleich
 aus. Dafür braucht es zwei Kippbewegungen in bekannte Richtungen, und genau die
 macht der Einbaulage-Assistent.
 
+### Beides liegt im Sensor, nicht in der App
+
+Sowohl die **Kalibrierung** als auch die **Einbaulage** speichert der ESP32
+selbst und gibt sie an jeden aus, der fragt. Das ist der Punkt, sobald mehr als
+ein Gerät im Spiel ist: iPhone, Apple Watch und Android-App zeigen dasselbe,
+und bestimmt werden muss beides nur ein einziges Mal, von welchem Gerät aus
+auch immer.
+
+| | wo |
+|---|---|
+| Nullpunkt der Kalibrierung | im ESP (`pitch_offset`, `roll_offset`), wird dort auch schon abgezogen |
+| Einbaulage samt Verdrehung | im ESP, Charakteristik `…3428`, lesbar und schreibbar |
+| Spurweite und Radstand | in der jeweiligen App, im Fahrzeugprofil |
+
+Beim Verbinden liest jede App die Einbaulage aus dem Gerät und übernimmt sie.
+Wer sie neu bestimmt, schreibt sie hinauf. Steht dort noch nichts – ältere
+Firmware oder nie bestimmt –, gilt weiter, was die App örtlich gespeichert hat;
+kaputtgehen kann dabei nichts.
+
+Angewandt wird sie trotzdem in den Apps und nicht im Sensor. Der Sensor
+verwahrt sie nur: Würde er die Winkel schon umgerechnet melden, rechnete jede
+ältere App die Korrektur ein zweites Mal ein.
+
+Die acht Byte der Charakteristik sind in `VanAlignProtocol` beschrieben und in
+`run-tests.sh` byteweise festgenagelt – daran hängen drei Apps und die
+Firmware.
+
 **Danach kalibrieren:** Fahrzeug eben stellen, dann *Auf
 aktuelle Lage kalibrieren*. Ohne das zeigt die Anzeige die Lage des Sensors,
 nicht die des Fahrzeugs – je nachdem, wie schief er eingebaut ist.