From aae7a7462dec630fa8526006e524ed608ad3240d Mon Sep 17 00:00:00 2001 From: Michael Sauer Date: Fri, 11 Sep 2026 23:52:18 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20Checkliste=20Netzwerk=20erg=C3=A4nzt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit M9: Hardware-Checkliste um Einträge für C1 (verschachteltes JSON, 400, Lampe läuft weiter), C2 (Onboarding, 60 s warten, Reboot + Router-Neustart -> AP darf nicht wiederkommen) und einen Hinweis auf den Build ohne NINLIGHT_WIFI_SSID für Onboarding-Tests ergänzt. `bri 30`-Eintrag nennt jetzt explizit den REST-Weg (`{"brightness":30}`) neben der Konsole. README: klargestellt, dass der Onboarding-Aufruf ohne Authorization-Header nur im unkonfigurierten AP funktioniert - im Fallback-AP (Zugangsdaten bereits vorhanden) ist der Token-Header wie bei jedem anderen Endpunkt erforderlich. --- README.md | 3 +++ docs/hardware-checklist.md | 5 ++++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 93f9499..1a1e698 100644 --- a/README.md +++ b/README.md @@ -61,6 +61,9 @@ Verfügbare Befehle in der Konsole: `help`. -d '{"type":"wifi","ssid":"MeinWLAN","password":"geheim123"}' curl http://192.168.4.1:3333/api/v1/system/info # wifi.sta_ip / wifi.error + Der Aufruf ohne `Authorization`-Header funktioniert nur im unkonfigurierten AP (noch keine + gespeicherten Zugangsdaten). Im Fallback-AP (Router war > 5 min weg, Lampe hat aber bereits + Zugangsdaten) ist der Token-Header wie bei jedem anderen Endpunkt erforderlich. Nach Erfolg schließt der AP nach 60 s. Ohne Verbindung für 5 min öffnet die Lampe den AP zusätzlich (Fallback). - REST auf Port 3333, Präfix `/api/v1`: `GET|POST device/state`, `GET system/info`, `GET|PUT system/settings` und `PUT system/command` (beide mit Header `Authorization: `, Default-Token `aabbccddeeff0011223344`). - Beispiel: `curl -X POST http://ninlight-681f.local:3333/api/v1/device/state -d '{"on":true,"brightness":40,"color_temp":2700}'` diff --git a/docs/hardware-checklist.md b/docs/hardware-checklist.md index c79c307..aebb849 100644 --- a/docs/hardware-checklist.md +++ b/docs/hardware-checklist.md @@ -27,13 +27,16 @@ Konsole: `tools/monitor.sh /dev/cu.` (115200 8N1). Flashen: `tools/flash.s - [ ] `dns-sd -B _ninlight._tcp` findet `ninlight-`, `dns-sd -L` zeigt TXT type/fw/mac/name - [ ] Bruno: alle Device-Requests wirken sichtbar, `Get State` spiegelt den Zustand - [ ] Ungültiger Body (`{"brightness":0}`) → 400, `system/settings` ohne Token → 401 -- [ ] `bri 30` per REST, sofort `Reboot` per REST → nach dem Boot 30 % (Flush) +- [ ] `bri 30` per REST (`{"brightness":30}`) oder Konsole `bri 30`, dann sofort `Reboot` per REST → nach dem Boot 30 % (Flush) - [ ] Werksreset → AP `ninlight-` sichtbar, Lampe pulsiert, Beitritt mit `ninlight` - [ ] Onboarding mit falschem Passwort → `system/info` zeigt `wifi.error = "auth"`, AP bleibt - [ ] Onboarding korrekt → `202`, Lampe verbindet, Pulsieren stoppt, AP nach 60 s weg - [ ] Router aus > 5 min → AP erscheint (`mode=apsta`); Router an → Verbindung, AP nach 10 s weg - [ ] Namensänderung per REST → TXT `name=` aktualisiert (`dns-sd -L`) - [ ] `auth_all` an → `GET device/state` ohne Token 401, mit Token 200 +- [ ] Onboarding-Tests: Build ohne `NINLIGHT_WIFI_SSID` in `config.local.cmake` +- [ ] C1: `curl -d '[[[[[[[[[[[[[[[[[[[[' http://:3333/api/v1/device/state` → 400, Lampe läuft unverändert weiter (kein Absturz/Reboot) +- [ ] C2: Onboarding ok, 60 s warten, dann Reboot und Router-Neustart → AP `ninlight-` darf nicht wiederkommen (Scan am Mac) ## Später (Lampen) - [ ] SM2135EH: Standby-Bit bei allen Kanälen 0 prüfen (Spec §4; alte Firmware setzte es praktisch nie)