MSP-Referenz dokumentiert: Sensor-Status/Arming-/Box-Mode-Flags im Code, ungenutzte iNAV-Befehle in der Architektur-Doku

Auf Nutzeranfrage die Bedeutung mehrerer MSP2_INAV_*-Codes gegen den
tatsaechlichen iNAV-9.1.0-Quellcode geprueft (fc_msp.c, fc_msp_box.c,
runtime_config.h, settings.yaml):

- msp_commands.dart: Doc-Kommentar zu MSP2_INAV_STATUS (0x2000, bereits
  genutzt) um das vollstaendige Bit-Layout von sensorStatus, armingFlags
  und boxModeFlags ergaenzt. boxModeFlags ist kein festes Bit-pro-Modus-
  Mapping, sondern muss ueber MSP_BOXIDS (ID 119) korreliert werden -
  Fixed-Wing-relevante permanentIds mit aufgefuehrt. MspArmingFlags um die
  komplette armingFlag_e-Referenz (alle ARMING_DISABLED_*-Gruende)
  erweitert, als Dokumentation - nicht als neue Konstanten, da bisher nur
  das ARMED-Bit tatsaechlich gebraucht wird.
- DMC_Architektur_und_Design.md (Abschnitt 6): fuenf bisher ungenutzte
  MSP2_INAV_*-Befehle als offene Punkte aufgenommen (GEOZONE/SAFEHOME/
  BATTERY_CONFIG/AIR_SPEED/TEMPERATURES) mit Payload-Details und
  Einschaetzung zur Relevanz - GEOZONE (Geofencing) am interessantesten
  fuer die bestehende Flugpfad-Machbarkeitspruefung.

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

DMC_Architektur_und_Design.md

@@ -191,6 +191,13 @@ Enthält u. a.:
 - **Klettersteigungsprüfung gegen tatsächliche Bogenlänge statt Geradenverbindung berechnen** — aktuell bewusste Vereinfachung, könnte bei engen Kombinationen aus Höhenänderung und scharfer Kurve leicht zu optimistisch sein.
 - **iNAV-10-Änderungen an Mission-/Wegpunktsystem** — zum Recherchezeitpunkt keine bestätigten grundlegenden Änderungen gegenüber v9 gefunden; Release-Termin (evtl. Ende 2026) und Feature-Freeze noch offen, vor App-Release erneut prüfen.
 - **Experimenteller iNAV-Community-Branch für Wegpunkt-Upload im Flug (bei nicht aktivem NAV-WP-Modus)** — Status unklar, ob in einen stabilen Release gewandert; vor Release gegen aktuelle 9.x-Firmware verifizieren, nicht darauf verlassen.
+- **`MSP2_INAV_WIND` (0x2231) für geschätzte Windstärke/-richtung im Drone Status** — vom iNAV-Windschätzer (`flight/wind_estimator.c`, GPS-basiert, kein Pitot nötig) berechnet, aber bis 9.1.0 nur ins OSD gerendert, nicht per MSP abrufbar. Command wurde erst kürzlich auf dem Branch `release/9.1` hinzugefügt (Commit "feat(msp): add MSP2_INAV_WIND (0x2231) to expose wind estimator", Bugfix in PR iNavFlight/inav#11762, gemerged 2026-08-03) — bislang in **keinem** getaggten Release (weder 9.1.0 noch `master`) enthalten, T1 Ranger müsste also erst auf eine Firmware ab diesem Commit geflasht werden. Response-Payload laut `fc_msp.c`: `u16 windSpeed` (cm/s, horizontal), `u16 windAngle` (Grad, 0–359, Earth-Frame), `u8 windFlags` (1 = Schätzung gültig). Vor Umsetzung erneut prüfen, ob der Command in einem stabilen Release gelandet ist.
+- **`MSP2_INAV_GEOZONE`/`_SET_GEOZONE` + `_GEOZONE_VERTEX`/`_SET_GEOZONE_VERTEX`** (`0x2210`–`0x2213`) für Geofencing — bisher ungenutzt, aber vermutlich das interessanteste noch nicht angebundene MSP-Feature für DMC. Indexbasiert abgefragt (`mspFcGeozoneOutCommand`/`mspFcGeozoneVerteciesOutCommand` in `fc_msp.c`): pro Zone (Request-Byte = Zonenindex) `u8 type` (Inclusion/Exclusion), `u8 shape` (Kreis/Polygon), `u32 minAltitude`, `u32 maxAltitude`, `u8 isSealevelRef`, `u8 fenceAction` (`NONE`/`AVOID`/`POS_HOLD`/`RTH`, siehe `settings.yaml` Table `fence_action`), `u8 vertexCount`; Vertices einzeln per `(zoneId, vertexId)` nachladbar (`u32 lat`, `u32 lon`, bei Kreisform zusätzlich ein Radius-Vertex). Könnte analog zur bestehenden Flugpfad-Machbarkeitsprüfung (`domain/mission/mission_warnings.dart`) als Warnung genutzt werden, wenn eine geplante Route eine auf der Drohne konfigurierte No-Fly-Zone kreuzt.
+- **`MSP2_INAV_SAFEHOME`/`_SET_SAFEHOME`** (`0x2038`/`0x2039`) für alternative RTH-Landepunkte — bisher ungenutzt. Indexbasiert (ein Request pro Slot, bis `MAX_SAFE_HOMES`): `u8 enabled`, `u32 lat`, `u32 lon`. Könnte eine "Backup-Landepunkte verwalten"-Ansicht ermöglichen, eigener UI-Scope (Liste/Editor), nicht MVP-kritisch.
+- **`MSP2_INAV_BATTERY_CONFIG`** (`0x2005`, alternativ als Teilmenge von `MSPV2_INAV_MISC`/`0x2003`) für die auf dem FC hinterlegte Batteriekonfiguration — bisher ungenutzt. Liefert `u8 cells` sowie `u16 cellDetect`/`cellMin`/`cellMax`/`cellWarning` (je 0.01V/Zelle, `fc_msp.c` `case MSP2_INAV_BATTERY_CONFIG`, Felder verifiziert gegen `settings.yaml`: `vbat_cell_detect_voltage`/`vbat_max_cell_voltage`/`vbat_min_cell_voltage`/`vbat_warning_cell_voltage`). Könnte künftig `DroneProfile.batteryCellCount`/die Pro-Zelle-Schwellwerte mit der tatsächlichen FC-Konfiguration abgleichen oder daraus vorbefüllen, statt sie nur manuell im Profil-Editor zu pflegen.
+- **`MSPV2_INAV_AIR_SPEED`** (`0x2009`) für echte Fahrt durch die Luft (Pitot) — liefert `u32 getAirspeedEstimate()`, ohne `USE_PITOT`-Sensor konstant `0`. Für den T1 Ranger aktuell nicht relevant (kein Pitot-Rohr vorgesehen); bei künftigem Pitot-Ausbau erneut prüfen.
+- **`MSP2_INAV_TEMPERATURES`** (`0x201E`) für Temperatursensor-Werte — Array von bis zu `MAX_TEMP_SENSORS` `i16`-Werten (`-1000` = ungültig), braucht konfigurierte Temp-Sensoren (`USE_TEMPERATURE_SENSOR`). Im aktuellen T1-Ranger-Aufbau keine physischen Temp-Sensoren vorgesehen, daher niedrige Priorität.
+- **Bit-Layout von `sensorStatus`/`armingFlags`/`boxModeFlags`** (Teil der bereits genutzten `MSP2_INAV_STATUS`, `0x2000`) — vollständig dokumentiert direkt im Code, siehe Doc-Kommentare zu `MspCommands.inavStatus` und `MspArmingFlags` in [msp_commands.dart](app/lib/transport/msp/msp_commands.dart), um Drift zwischen Architektur-Doku und Code zu vermeiden. Insbesondere `boxModeFlags` ist dort ausführlich erklärt: die Bit-Position ist NICHT fest, sondern muss einmalig über `MSP_BOXIDS` (ID 119) mit der jeweiligen Firmware-Konfiguration korreliert werden.
 - **`dart_mavlink`-Paket vs. eigener Generator aus MAVLink-XML-Dialektdateien** — Entscheidung für die MAVLink-Anbindung (nicht MVP-kritisch, aber für spätere ArduPilot-Unterstützung relevant) noch offen.
 - **XR1-Empfänger-Kompatibilität mit mLRS** — XR4 ist vom mLRS-Team offiziell validiert, XR1 nur wahrscheinlich kompatibel (über generisches Firmware-Target), nicht bestätigt.
 - **iOS-Hintergrundverbindung** — Konzept (Background Modes / "voip"/"location"-Capability) benannt, aber nicht MVP-relevant (MVP ist Android-only) und nicht im Detail ausgearbeitet.