Document the wind auto-fetch decision in the architecture doc

2026-08-09 22:27:37 +02:00
parent eca1c647b3
commit 2581bdaaef
1 changed files with 1 additions and 0 deletions
@@ -166,6 +166,7 @@ Enthält u. a.:
 | 4.23 | **`go_router` für Navigation (Flutter-Ziel)** | Typisierte Übergänge, passend zum expliziten Mode-Wechsel-Trigger der State-Machine |
 | 4.24 | **SSID-Anzeige in den Settings aufgegeben, Verbindungspille zeigt nur generisches "Connected"** | Auf echter Hardware (Pixel-Gerät, Android 16) liefert `NetworkCapabilities.getTransportInfo()` konsequent ein redigiertes `WifiInfo` (SSID `<unknown ssid>`, BSSID maskiert) — bestätigt per natives `Log.d` in `MlrsNetworkPlugin.onAvailable()`/`onCapabilitiesChanged()`, gegengeprüft mit `adb shell dumpsys wifi` (Shell-Kontext kennt und ordnet die echte SSID korrekt der App zu, das App-API liefert sie aber nicht). Die im Code angenommene "Ausnahme für selbst angefragte `WifiNetworkSpecifier`-Netze ohne `ACCESS_FINE_LOCATION`" gilt offenbar nur für `WifiManager.getConnectionInfo()`, nicht für diesen `NetworkCapabilities`-Weg über `ConnectivityManager.NetworkCallback`. Statt `ACCESS_FINE_LOCATION` (inkl. Laufzeit-Prompt) nur für diese kosmetische Anzeige hinzuzufügen, hat der Nutzer sich bewusst dagegen entschieden — die zugrundeliegende SSID-Merk-Logik (`UdpTransport.connectedSsid`/`_rememberSsid`, `preferredSsid` für stilles Reconnect) bleibt bestehen, liefert im Regelfall aber `null`/keinen Effekt |
 | 4.25 | **Homepoint-Abfrage (`MSP_WP`/0x76, WP#0) gezielt statt kontinuierlich, nur bei Connect/GPS-Fix/Armen** | `getWaypoint()` in `navigation.c` liefert für WP#0 den Homepoint (`GPS_home.lat/lon/alt`), aber (0,0,0) statt eines Fehlers, solange `STATE(GPS_FIX_HOME)` nicht gesetzt ist — als "kein Homepoint" behandelt (`parseMspHomePoint`). Der FC selbst friert den Homepoint nicht beim ersten GPS-Fix ein, sondern lässt ihn der Drohne folgen, solange sie disarmed ist und noch nie armed war (`updateHomePosition()`), und sperrt ihn erst beim ersten Armen (iNAV-Default `reset_home_type = FIRST_ARM`, `settings.yaml`) — kontinuierliches Polling wäre also die meiste Zeit sinnlos; `home_point_provider.dart` fragt stattdessen gezielt bei genau diesen drei Momenten neu ab |
 | 4.26 | **Manuelle "Fetch wind"/"Validate"-Knöpfe entfernt, Wind pro Wegpunkt automatisch abgerufen** | Statt eines expliziten Knopfs holt `HeaderWindNotifier.ensurePerWaypointWind()` (`wind_provider.dart`) den Wind jetzt automatisch beim Öffnen der Wegpunktliste oder Aktivieren der Kopfleisten-Windanzeige — abgeglichen über eine Lat/Lon-Signatur der Wegpunktliste, damit spätere Höhen-/Geschwindigkeits-Änderungen keinen erneuten Request auslösen, wohl aber eine geänderte Wegpunktliste selbst (`ref.listen(currentMissionProvider, ...)` in derselben Notifier-Klasse). Das bislang separate Wind-Validierungspanel (`WindValidatePanel`, `WindService.fetchValidation`) hatte außer dem entfernten "Validate"-Knopf keinen weiteren Aufrufer und wurde komplett mitentfernt, statt als toter Code liegen zu bleiben. Nebenbei behoben: die Pro-Wegpunkt-Windanzeige auf der Karte (`MissionMap.windMarkers`) war nie in `fly_screen.dart` verdrahtet, nur in `plan_screen.dart` — im Fly-Modus blieb sie bislang wirkungslos, obwohl die Kopfleisten-Pille dort ebenfalls sichtbar ist. |
 ---