ninharp/ninlight-w600
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
6588085679656c48696613fad95b967d3d2ef522
ninlight-w600/docs/hardware-checklist.md
T
Michael Sauer 3841a3473c docs: Recovery-Zeitobergrenze, aktiven Boot-Scan und offene Pruefpunkte nachziehen 
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.
2026-09-12 03:27:33 +02:00

6.5 KiB
Raw Blame History

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
  • 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
Reference in New Issue View Git Blame Copy Permalink