diff --git a/README.md b/README.md index e3557c4..b006195 100644 --- a/README.md +++ b/README.md @@ -44,7 +44,7 @@ Firmware flashen (Standard: App-Image): tools/flash.sh -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 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 full` (flasht stattdessen das Vollbild mit secboot, auf Hardware noch ungetestet). Serielle Konsole (115200 8N1, lokales Echo): @@ -120,18 +120,20 @@ Einschalten: -H 'Authorization: ' \ -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-` | +| `ssid` | nein | AP-Name, 1..32 Zeichen; ein leerer String wird mit 400 `invalid ssid` abgelehnt. Weggelassen bleibt der gespeicherte Name erhalten; `ninlight-` 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-`. `GET system/settings` zeigt einen `standalone`-Block mit `enabled`, dem **wirksamen** AP-Namen diff --git a/docs/hardware-checklist.md b/docs/hardware-checklist.md index e17ed59..99701ef 100644 --- a/docs/hardware-checklist.md +++ b/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