Michael Sauer
3841a3473c
sdk/PATCHES.md, README.md und docs/hardware-checklist.md beschrieben teils einen ueberholten Stand: die Watchdog-Einschaetzung in PATCHES.md Punkt 4 stammte noch von vor dem Drei-Heartbeat-Gate in app_main.c und vor der Zeitobergrenze in nl_recovery.c; README behauptete eine harte Obergrenze ueber dem gesamten Download statt nur ueber einem echten Stillstand; der Boot-Scan ist aktiv (~3 s), nicht passiv wie an einer Stelle der Spec beschrieben (Spec bleibt unveraendert). PATCHES.md Punkt 1 ergaenzt den sys/nl_ota.h-Include in wm_fwup.c, Punkt 5 den fls_lock-printf. hardware-checklist.md: Recovery-Zeile auf "Gegenstelle sendet nichts mehr" praezisiert; die beiden Werksreset-Haken aus Plan 1 zurueckgesetzt, weil der vorgelagerte Recovery-Scan das Boot-Timing verschiebt und sie neu geprueft werden muessen; acht neue Pruefpunkte fuer Plan 3 ergaenzt (Zweitversuch nach Ablehnung, REST-Erreichbarkeit waehrend/nach Ablehnung, Lichtverhalten ueber OTA mit pob=off/on, fw_version gegen Trailer, echter Rettungsfall, Rettungsstation nach Erfolg angelassen, AP-Modus + auth_all) sowie ein Betriebshinweis zu NINLIGHT_RECOVERY_PASSWORD/NINLIGHT_TOKEN fuer den Flottenbau.
67 lines
6.5 KiB
Markdown
67 lines
6.5 KiB
Markdown
# Hardware-Checkliste (EVK)
|
||
|
||
Konsole: `tools/monitor.sh /dev/cu.<port>` (115200 8N1). Flashen: `tools/flash.sh evk <port>`.
|
||
|
||
## Licht (Plan 1, Task 11)
|
||
- [x] Nach dem Boot blendet warmweiß 100 % in 0,5 s ein
|
||
- [x] `rgb 255 0 0` → nur Rot, `rgb 0 255 0` → nur Grün, `rgb 0 0 255` → nur Blau
|
||
- [x] `ct 2700` → nur Warmweiß, `ct 6500` → nur Kaltweiß, `ct 4000` → Mischung
|
||
- [x] `bri 1` sichtbar sehr dunkel, `bri 100` hell; `bri 1 3000` → gleichmäßig wirkender Fade
|
||
- [x] `off 2000` → blendet mit aktueller Farbe aus; `on 2000` → blendet ein
|
||
- [x] `rgb 255 0 0` dann `ct 3000 2000` → erst dunkel, dann weiß (Moduswechsel)
|
||
- [x] `blink 3` → 3× Blinken, danach alter Zustand; `pulse on` / `pulse off`
|
||
- [x] Kein sichtbares Flackern bei konstanten Werten (5 kHz)
|
||
|
||
## Persistenz und Boot (Plan 1, Task 12)
|
||
- [x] `pob last`: Farbe setzen, 4 s warten, Strom aus/an → gleicher Zustand, mit Fade
|
||
- [x] `pob off`: Strom aus/an → bleibt aus; `on` → letzte Farbe
|
||
- [x] `pob on` bei ausgeschaltetem Licht: Strom aus/an → an
|
||
- [x] `fade 2000 2000` bleibt nach Reboot erhalten (`state`)
|
||
- [ ] 5× Strom an/aus mit jeweils < 5 s Laufzeit → 3× Blinken, danach Defaults (`state`) (erneut zu prüfen: der vorgelagerte Recovery-Scan aus Plan 3 verschiebt jeden Boot um bis zu ~3 s, das Timing der 5-Sekunden-Grenze ist damit nicht mehr das von Plan 1)
|
||
- [ ] Normaler Boot nach > 5 s Laufzeit → kein Werksreset (erneut zu prüfen, gleicher Grund: Recovery-Scan verschiebt die Boot-Zeitrechnung)
|
||
- [x] Watchdog: `wdtest` → Neustart nach ca. 20–40 s (erste Ablaufzeit löst IRQ aus, Reset beim zweiten Ablauf) — getestet 2026-09-11 mit e19ee98: Neustart nach 40,4 s
|
||
- [x] Getestet am 2026-09-11 mit Firmware 7502f4f am EVK (MAC 28-6D-CD-5C-68-1F)
|
||
|
||
## Netzwerk & REST (Plan 2)
|
||
- [x] Mit Build-Credentials: Boot → `net` zeigt `mode=sta` und eine IP, RSSI plausibel (−30 … −90) — 2026-09-12
|
||
- [x] `dns-sd -B _ninlight._tcp` findet `ninlight-<mac4>`, `dns-sd -L` zeigt TXT type/fw/mac/name — 2026-09-12
|
||
- [x] Bruno: alle Device-Requests wirken sichtbar, `Get State` spiegelt den Zustand — 2026-09-12
|
||
- [x] Ungültiger Body (`{"brightness":0}`) → 400, `system/settings` ohne Token → 401 — 2026-09-12
|
||
- [x] `bri 30` per REST (`{"brightness":30}`) oder Konsole `bri 30`, dann sofort `Reboot` per REST → nach dem Boot 30 % (Flush) — 2026-09-12
|
||
- [x] Werksreset → AP `ninlight-<mac4>` sichtbar, Lampe pulsiert, Beitritt mit `ninlight` — 2026-09-12
|
||
- [x] Onboarding mit falschem Passwort → `system/info` zeigt `wifi.error = "auth"`, AP bleibt — 2026-09-12
|
||
- [x] Onboarding korrekt → `202`, Lampe verbindet, Pulsieren stoppt, AP nach 60 s weg — 2026-09-12
|
||
- [ ] Router aus > 5 min → AP erscheint (`mode=apsta`); Router an → Verbindung, AP nach 10 s weg
|
||
- [x] Namensänderung per REST → TXT `name=` aktualisiert (`dns-sd -L`) — 2026-09-12
|
||
- [x] `auth_all` an → `GET device/state` ohne Token 401, mit Token 200 — 2026-09-12
|
||
- [x] Onboarding-Tests: Build ohne `NINLIGHT_WIFI_SSID` in `config.local.cmake` — 2026-09-12
|
||
- [x] C1: `curl -d '[[[[[[[[[[[[[[[[[[[[' http://<ip>:3333/api/v1/device/state` → 400, Lampe läuft unverändert weiter (kein Absturz/Reboot) — 2026-09-12
|
||
- [x] C2: Onboarding ok, 60 s warten, dann Reboot und Router-Neustart → AP `ninlight-<mac4>` darf nicht wiederkommen (Scan am Mac) — 2026-09-12 (Reboot geprüft, Router-Neustart offen)
|
||
|
||
## OTA und Recovery (Plan 3)
|
||
- [ ] OTA: Update über `fw_update` läuft durch, danach meldet `system/info` die neue Version
|
||
- [ ] OTA: Image eines anderen Gerätetyps wird sofort abgelehnt (`last_ota_error` = `device_mismatch`), kein Reset, Lampe läuft mit der alten Firmware weiter
|
||
- [ ] OTA: Image mit verfälschtem Byte wird abgelehnt (`last_ota_error` = `hash` oder `crc`), kein Reset
|
||
- [ ] OTA: HTTP-Server während des Downloads abschalten → Wiederaufnahmeversuch (Range-Resume) sichtbar in der Konsole, nach Ausschöpfen der Runden `last_ota_error` = `download`, Lampe bootet normal
|
||
- [ ] OTA: kurzer WLAN-Aussetzer während des Downloads (Verbindung kurz kappen und wiederherstellen) → Download wird fortgesetzt, kein sofortiger `download`-Fehler
|
||
- [ ] Recovery: Lampe zieht beim Booten das Image von der Station `ninlight-recovery`, Konsole zeigt Scan-, Join- und Fetch-Meldungen
|
||
- [ ] Recovery: ohne Station verlängert sich der Boot um höchstens ~3 s, Konsole loggt das Scan-Ergebnis (gefunden/nichts gefunden/Scan fehlgeschlagen)
|
||
- [ ] Recovery: Gegenstelle bleibt verbunden, sendet aber keine Daten mehr (nicht: ein langsamer, aber laufender Download) → nach Ablauf der Zeitobergrenze bedient die Firmware den Watchdog nicht mehr, Chip startet neu statt hängen zu bleiben
|
||
- [ ] Einstellungen bleiben über ein OTA hinweg erhalten (WLAN, Name, Fade-Zeiten)
|
||
- [ ] Zweiter `fw_update` mit gültigem Image direkt nach einer Ablehnung, ohne zwischenzeitlichen Reboot → läuft durch, `system/info` meldet danach die neue Version
|
||
- [ ] Lampe bleibt während und nach einer Ablehnung über REST erreichbar: `system/info` und `device/state` antworten beide weiterhin mit 200
|
||
- [ ] Lichtverhalten über ein OTA hinweg (Spec §8.2, ein Update ist kein Stromausfall): einmal mit `power_on_behaviour = off`, einmal `= on` — die Lampe ist nach dem Update jeweils in demselben Zustand (an/aus, Farbe/Helligkeit), in dem sie vor dem Update war
|
||
- [ ] `system/info.fw_version` nach einem OTA stimmt mit der Version im Trailer des geflashten Images überein (Trailer-Version z.B. mit `tools/mkimage` prüfen)
|
||
- [ ] Recovery im echten Rettungsfall: Lampe ohne gültige WLAN-Konfiguration bzw. im Onboarding-AP findet die Station, zieht das Image und startet mit der neuen Firmware
|
||
- [ ] Rettungsstation nach erfolgreicher Recovery angelassen lassen, Lampe neu booten lassen → kein erneutes Flashen (Version stimmt bereits überein) und kein Werksreset (Power-Cycle-Zähler wurde vor dem Recovery-Versuch gelöscht)
|
||
- [ ] OTA im AP-/Fallback-Modus (`mode=apsta`, kein Router erreichbar) und mit `auth_all = true` → Update läuft durch wie im normalen `sta`-Modus
|
||
|
||
Für den echten Flottenbau `NINLIGHT_RECOVERY_PASSWORD` und `NINLIGHT_TOKEN` in `config.local.cmake` setzen — die Defaults sind nur fürs EVK gedacht.
|
||
|
||
## Später (Lampen)
|
||
- [ ] SM2135EH: Standby-Bit bei allen Kanälen 0 prüfen (Spec §4; alte Firmware setzte es praktisch nie)
|
||
- [ ] E27 Color (SM2135EH): RGB und WY getrennt, Ströme plausibel (nicht zu heiß)
|
||
- [ ] E27 CW: Gegenphase CW sichtbar flackerfrei
|
||
- [ ] G95: Pinbelegung WW=PB15/CW=PB13 prüfen
|
||
- [ ] Farbtemperaturbereiche aller Varianten
|