Die README behauptete noch, das Token stehe einmalig auf der seriellen
Konsole - seit der Umstellung auf das Werks-Token wie ninlight falsch.
Dazu die Vertrauensgrenze, die bisher nur in der Firmware stand: wer im
selben WLAN ist und das oeffentliche Token kennt, kann das Geraet steuern und
Firmware aufspielen. Bewusst so, wie bei ninlight. Eine automatische
Sicherheitspruefung hatte die Vorbelegung im Dialog beanstandet - die
Begruendung gehoert deshalb auch hierher, nicht nur in die Firmware.
Auf dem Geruest von ha-ninlight aufgebaut und bewusst parallel gehalten:
gleiche Fehlerklassen in api.py, gleicher Coordinator mit Sperre und
Fehlertoleranz, gleicher Einrichtungsablauf samt Zeroconf und Reauth.
Eigenes Repo statt Erweiterung von ha-ninlight: die Geraete melden sich unter
verschiedenen mDNS-Diensten, das Datenmodell unterscheidet sich deutlich
(Segmente und Szenen gegen ein einzelnes Licht), und ha-ninlight laeuft
produktiv mit vier Lampen - Verzweigungen dort haetten beide Produkte
gefaehrdet.
Entitaeten: light (Hauptschalter und Helligkeit), select (Szene), button
(Neustart), vier Diagnosesensoren.
In ha-dev eingebunden und am echten Geraet geprueft: Aus- und Einschalten,
Helligkeit 40 Prozent, Szenenwechsel auf Regenbogen - das Geraet meldet
jeweils genau das zurueck.
ninharp