docs: Standalone-AP, ssid/pulse-Angaben korrigiert, Begriffe geschaerft

README.md

@@ -44,7 +44,7 @@ Firmware flashen (Standard: App-Image):
 
     tools/flash.sh <device> <port>
 
-Das Skript druckt `Bitte bei "please manually reset the device" die Reset-Taste drücken.` — wenn wm_tool diese Nachricht zeigt, musst du die Reset-Taste am EVK drücken (Baud 460800). Das Skript ruft `wm_tool` mit `-rs none` auf, es löst also **keinen** Reset aus: Der Reset muss von Hand in dem Zeitfenster kommen, in dem `wm_tool` auf den Sync wartet. Ein automatischer Reset über die Steuerleitungen (`-rs rts` o. ä.) funktioniert an diesem Board nicht. Wer zu spät drückt, sieht `wm_tool` einfach weiter warten und startet den Aufruf neu. Für blank/erased Chips: `tools/flash.sh <device> <port> full` (flasht stattdessen das Vollbild mit secboot, auf Hardware noch ungetestet).
+Das Skript druckt `Bitte bei "please manually reset the device" die Reset-Taste drücken.` — wenn wm_tool diese Nachricht zeigt, musst du die Reset-Taste am EVK drücken (Baud 460800). Das Skript ruft `wm_tool` mit `-rs none` auf, es löst also **keinen** Reset aus: Der Reset muss von Hand in dem Zeitfenster kommen, in dem `wm_tool` auf den Sync wartet. Ein automatischer Reset über die Steuerleitungen (`-rs rts` o. ä.) funktioniert an diesem Board nicht. Für blank/erased Chips: `tools/flash.sh <device> <port> full` (flasht stattdessen das Vollbild mit secboot, auf Hardware noch ungetestet).
 
 Serielle Konsole (115200 8N1, lokales Echo):
 
@@ -120,18 +120,20 @@ Einschalten:
          -H 'Authorization: <token>' \
          -d '{"type":"standalone","enabled":true,"ssid":"Buehne","password":"geheim123","channel":6}'
 
-Antwort `202 {"status":"standalone"}`. Felder:
+Antwort `202 {"status":"standalone"}`. Anders als der unkonfigurierte Onboarding-AP ist der
+Standalone-AP nicht token-frei: der Tokenschutz gilt dort wie im Normalbetrieb (am Gerät noch nicht
+nachgemessen, siehe Abnahmeliste). Felder:
 
 | Feld | Pflicht | Bedeutung |
 |---|---|---|
 | `enabled` | ja | `true` schaltet den Modus ein, `false` aus |
 | `password` | beim Einschalten, solange noch keines gespeichert ist | AP-Passwort, 8..63 Zeichen |
-| `ssid` | nein | AP-Name, 1..32 Zeichen; leer bzw. weggelassen heißt `ninlight-<mac4>` |
+| `ssid` | nein | AP-Name, 1..32 Zeichen; ein leerer String wird mit 400 `invalid ssid` abgelehnt. Weggelassen bleibt der gespeicherte Name erhalten; `ninlight-<mac4>` gilt nur, solange nie ein eigener gesetzt wurde — über die API führt kein Weg zurück zum Vorgabenamen |
 | `channel` | nein | Funkkanal 1..13, Vorgabe 6 |
-| `pulse` | nein | Startpuls beim Hochfahren der Lampe an/aus (läuft rund 5 s, danach gilt das normale Einschaltverhalten) |
+| `pulse` | nein | Startpuls beim Hochfahren der Lampe an/aus, Vorgabe an (läuft rund 5 s, danach gilt das normale Einschaltverhalten) |
 
 Ausschalten braucht kein Passwort: `{"type":"standalone","enabled":false}`. Hat die Lampe gespeicherte
-WLAN-Daten, wählt sie sich damit wieder ins WLAN ein; ohne solche öffnet sie den offenen
+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

docs/hardware-checklist.md

@@ -68,7 +68,7 @@ Für den echten Flottenbau `NINLIGHT_RECOVERY_PASSWORD` und `NINLIGHT_TOKEN` in
 ## Standalone-AP-Modus (Abnahme am EVK, MAC 28:6d:cd:5c:68:1f)
 
 - [x] `type: standalone` per `PUT system/settings` einschalten → 202 `{"status":"standalone"}`, `system/info` meldet `wifi.standalone: true` — 2026-10-02
-- [x] Neustart → Lampe startet direkt im eigenen AP: Konsole `wifi: standalone AP, hostname ninlight-681f`, keine Onboarding-Zeile, kein Onboarding-Pulsen — 2026-10-02
+- [x] Neustart → Lampe startet direkt im eigenen AP: Konsole `wifi: standalone AP, hostname ninlight-681f`, keine Onboarding-Zeile, kein Onboarding-Pulsen (den gibt es nur im Zustand `AP_ONBOARDING`, aus dem Code ableitbar; der Standalone-Startpuls ist davon getrennt und unten offen) — 2026-10-02
 - [x] Geänderte AP-Daten → `wifi: AP data changed, rebuilding`, danach `wifi: AP ninlight-681f (ch 6) up` — 2026-10-02
 - [x] Standalone mit exakt den Vorgabedaten auf einem bereits stehenden Onboarding-AP (kein Neuaufbau) löst die mDNS-Bekanntmachung ebenfalls aus — 2026-10-02
 - [x] mDNS im eigenen AP: Konsole `mdns: ninlight-681f.local _ninlight._tcp up on en1 192.168.4.1`, `dns-sd -G v4 ninlight-681f.local` löst auf `192.168.4.1` auf, `ping` 0 % Verlust — 2026-10-02
@@ -77,7 +77,7 @@ Für den echten Flottenbau `NINLIGHT_RECOVERY_PASSWORD` und `NINLIGHT_TOKEN` in
 - [ ] REST über den AP verlangt das Token (`GET system/settings` ohne Token → 401)
 - [ ] 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
-- [ ] Werksreset über 5× ein/aus → wieder offener Onboarding-AP
+- [ ] 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.*
 
 ## Offene Beobachtung aus der EVK-Session vom 2026-09-12