ninlight-w600/docs/hardware-checklist.md

Hardware-Checkliste (EVK)

Konsole: tools/monitor.sh /dev/cu.<port> (115200 8N1). Flashen: tools/flash.sh evk <port>.

Licht (Plan 1, Task 11)

• Nach dem Boot blendet warmweiß 100 % in 0,5 s ein
• rgb 255 0 0 → nur Rot, rgb 0 255 0 → nur Grün, rgb 0 0 255 → nur Blau
• ct 2700 → nur Warmweiß, ct 6500 → nur Kaltweiß, ct 4000 → Mischung
• bri 1 sichtbar sehr dunkel, bri 100 hell; bri 1 3000 → gleichmäßig wirkender Fade
• off 2000 → blendet mit aktueller Farbe aus; on 2000 → blendet ein
• rgb 255 0 0 dann ct 3000 2000 → erst dunkel, dann weiß (Moduswechsel)
• blink 3 → 3× Blinken, danach alter Zustand; pulse on / pulse off
• Kein sichtbares Flackern bei konstanten Werten (5 kHz)

Persistenz und Boot (Plan 1, Task 12)

• pob last: Farbe setzen, 4 s warten, Strom aus/an → gleicher Zustand, mit Fade
• pob off: Strom aus/an → bleibt aus; on → letzte Farbe
• pob on bei ausgeschaltetem Licht: Strom aus/an → an
• 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)
• 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
• Getestet am 2026-09-11 mit Firmware 7502f4f am EVK (MAC 28-6D-CD-5C-68-1F)

Netzwerk & REST (Plan 2)

• Mit Build-Credentials: Boot → net zeigt mode=sta und eine IP, RSSI plausibel (−30 … −90) — 2026-09-12
• dns-sd -B _ninlight._tcp findet ninlight-<mac4>, dns-sd -L zeigt TXT type/fw/mac/name — 2026-09-12
• Bruno: alle Device-Requests wirken sichtbar, Get State spiegelt den Zustand — 2026-09-12
• Ungültiger Body ({"brightness":0}) → 400, system/settings ohne Token → 401 — 2026-09-12
• bri 30 per REST ({"brightness":30}) oder Konsole bri 30, dann sofort Reboot per REST → nach dem Boot 30 % (Flush) — 2026-09-12
• Werksreset → AP ninlight-<mac4> sichtbar, Lampe pulsiert, Beitritt mit ninlight — 2026-09-12
• Onboarding mit falschem Passwort → system/info zeigt wifi.error = "auth", AP bleibt — 2026-09-12
• 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
• Namensänderung per REST → TXT name= aktualisiert (dns-sd -L) — 2026-09-12
• auth_all an → GET device/state ohne Token 401, mit Token 200 — 2026-09-12
• Onboarding-Tests: Build ohne NINLIGHT_WIFI_SSID in config.local.cmake — 2026-09-12
• C1: curl -d '[[[[[[[[[[[[[[[[[[[[' http://<ip>:3333/api/v1/device/state → 400, Lampe läuft unverändert weiter (kein Absturz/Reboot) — 2026-09-12
• 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 — 2026-09-12 (0.3.0 → 0.3.1 → 0.3.2)
• OTA: Image eines anderen Gerätetyps wird sofort abgelehnt (last_ota_error = device_mismatch), kein Reset, Lampe läuft mit der alten Firmware weiter — 2026-09-12 (Ablehnung nach ~4,5 s, Uptime lief durch)
• OTA: Image mit verfälschtem Byte wird abgelehnt (last_ota_error = hash oder crc), kein Reset — 2026-09-12 (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) — 2026-09-12 (Name, Fade 1200/800, pob, Lichtzustand)
• Zweiter fw_update mit gültigem Image direkt nach einer Ablehnung, ohne zwischenzeitlichen Reboot → läuft durch, system/info meldet danach die neue Version — 2026-09-12 (erst nach dem SHA256-Kontext-Fix)
• Lampe bleibt während und nach einer Ablehnung über REST erreichbar: system/info und device/state antworten beide weiterhin mit 200 — 2026-09-12 (system/info und device/state je 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) — 2026-09-12
• 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

Offene Beobachtung aus der EVK-Session vom 2026-09-12

Beim Test mit dem verfälschten Image meldete lwIP einmalig Assertion "pbuf_free: p->ref > 0" failed at line 747 in pbuf.c (10:29:23). Die Lampe lief unbeeinträchtigt weiter und meldete korrekt last_ota_error=crc. Bei den Läufen mit fremdem Gerätetyp und bei den erfolgreichen Updates trat die Meldung nicht auf. Ursache noch nicht geklärt — in einem Build ohne Assertions wäre das ein doppeltes Freigeben eines Netzwerkpuffers. Vor dem Einsatz auf echten Lampen reproduzieren und aufklären.