Doku: AP-Name in system/settings (gewuenscht) und system/info (laufend) unterschieden, Abnahmepunkt fuer wifi.ssid im AP-Betrieb

README.md

@@ -136,11 +136,19 @@ Ausschalten braucht kein Passwort: `{"type":"standalone","enabled":false}`. Hat
 WLAN-Daten, wählt sie sich damit wieder ins WLAN ein; ohne solche öffnet sie den unkonfigurierten
 Onboarding-AP `ninlight-<mac4>`.
 
-`GET system/settings` zeigt einen `standalone`-Block mit `enabled`, dem **wirksamen** AP-Namen
+`GET system/settings` zeigt einen `standalone`-Block mit `enabled`, dem **gewünschten** AP-Namen
-(`ssid`), `channel` und `pulse` — das Passwort steht nie darin. `GET system/info` meldet
+(`ssid`: der gespeicherte Name, ohne eigenen Namen der Hostname), `channel` und `pulse` — das
-`wifi.standalone` und im AP-Betrieb (`mode: "ap"`, also eigener AP oder Onboarding-AP) unter
+Passwort steht nie darin. `GET system/info` meldet `wifi.standalone` und im AP-Betrieb (`mode: "ap"`,
-`wifi.ssid` den **wirksamen AP-Namen** statt der gespeicherten Stations-SSID — der Name des
+also eigener AP oder Onboarding-AP) unter `wifi.ssid` den **laufenden AP-Namen** statt der
-Heimnetzes steht damit nicht in einer tokenfrei lesbaren Antwort.
+gespeicherten Stations-SSID — der Name des Heimnetzes steht damit nicht in einer tokenfrei lesbaren
+Antwort.
+
+Die beiden Namen können auseinanderlaufen, und das ist Absicht. Scheitert der AP-Aufbau mehrfach,
+fällt der Treiber auf die zuletzt funktionierenden Daten zurück, und gibt es die nicht, auf Name und
+Kanal der Vorgaben (das Nutzerpasswort bleibt); die gespeicherte Einstellung behält dabei den
+Wunschnamen. Nach `{"enabled":false}` behält sie `ap_ssid` ebenfalls, der laufende AP heißt dann
+wieder `ninlight-<mac4>`. Genau diese Abweichung zwischen `system/settings` (gewünscht) und
+`system/info` (läuft) ist das Erkennungsmerkmal für einen Rückfall.
 
 Der Startpuls übermalt als Überlagerung die sACN-Ausgabe: solange er läuft, ist von sACN nichts
 zu sehen. Beim Ausprobieren von sACN über den eigenen AP den Puls mit `pulse: false` abschalten oder

docs/hardware-checklist.md

@@ -79,6 +79,7 @@ Für den echten Flottenbau `NINLIGHT_RECOVERY_PASSWORD` und `NINLIGHT_TOKEN` in
 - [ ] Standalone-Daten ändern, während der Aufrufer **über den AP** verbunden ist → die 202 kommt beim Aufrufer an, bevor der AP abreißt. Im Code steht dafür seit I6 eine Pause von rund 250 ms vor dem Wechsel; **gemessen ist der Fall nicht** — beim Wechsel aus dem WLAN ging es auch ohne Pause gut, weil `tls_wifi_disconnect()` asynchron arbeitet, `tls_wifi_softap_destroy()` ist der härtere Abriss
 - [ ] WLAN eingeben, falsches Passwort → Gerät bleibt im eigenen AP mit eigenen Daten
 - [ ] WLAN eingeben, richtiges Passwort → Gerät im Heimnetz, nach einem Neustart **nicht** wieder im AP
+- [ ] Im Standalone-Betrieb meldet `GET system/info` unter `wifi.ssid` den **AP-Namen**, nicht die gespeicherte Stations-SSID — *am aussagekräftigsten an einer Lampe, die noch Heimnetz-Zugangsdaten gespeichert hat: vorher stand dort der Name des Heim-WLANs, und zwar in einer tokenfrei lesbaren Antwort. Weder automatisiert noch hostprüfbar: `nl_wifi_status()` liegt in `nl_wifi_w600.c`, und die steht nicht im Hostbau. Am Gerät hat noch niemand hingesehen.*
 - [ ] Werksreset über 5× ein/aus → wieder unkonfigurierter Onboarding-AP
 - [ ] sACN über den Standalone-AP, **sichtbar an der Lampe** (nicht nur `active: true`), unicast an die AP-IP und multicast — *Fallen: Ein Sender ohne gesetztes `IP_MULTICAST_IF` misst bei zwei Default-Routen das eigene LAN statt den AP (am 2026-10-01 genau so schiefgegangen). Ein laufender Startpuls übermalt die sACN-Ausgabe, weil `nl_engine_pulse()` eine Überlagerung ist: für die Prüfung `pulse: false` setzen oder den Puls abwarten.*