ninharp
d0a9487805
Die Firmware kann sACN/E1.31 - jetzt auch in Home Assistant, aufgebaut wie in
ha-ninlight: Schalter fuer den Empfang, Zahlen fuer Universe und Startslot,
Auswahl fuer das Verhalten nach Stromende, zwei Diagnose-Binaersensoren.
Die Einstellungen liegen hinter system/settings, der Koordinator liest sie
deshalb mit - eine vierte Anfrage je Zyklus. Nach dem Schreiben wird
zurueckgelesen statt angenommen, wie in ha-ninlight.
Zwei Unterschiede zu ninlight:
- Kein Layout-Feld: ninstrip nutzt fest drei Kanaele je Pixel.
- Der Startslot gilt in JEDEM belegten Universe. Die Obergrenze ist deshalb
513 minus Kanaele je Pixel, also 510 - ein festes 512 boete Werte an, bei
denen kein einziges Pixel mehr ins Universe passt.
Aeltere Firmware ohne sacn-Block: die Entitaeten entstehen trotzdem und
melden sich nicht verfuegbar, bis ein Update kommt.
In ha-dev an der Stehlampe geprueft: Universe, Startslot, on_timeout und der
Schalter kommen jeweils auf dem Geraet an; der Aktiv-Sensor steht waehrend
eines Stroms auf an, danach auf aus. 511 als Startslot weist Home Assistant
selbst ab ("outside valid range 1 - 510"). Einstellungen der Lampe danach
zurueckgestellt.
4.3 KiB
ha-ninstrip
Home-Assistant-Integration für ninstrip — ESP32-C3-Firmware für IC-getriebene LED-Strips. Schwesterprojekt zu ha-ninlight.
Warum eine eigene Integration
ninlight und ninstrip teilen sich das API-Gerüst (Port 3333, /api/v1,
Authorization: <token>), beschreiben aber verschiedene Geräte: eine Lampe
mit einem Licht gegen einen Strip mit Segmenten und Szenen. Beide Modelle in
eine Integration zu zwingen hieße, in Coordinator und Entitäten dauernd zu
verzweigen — und bei jedem Fehler beide Produkte zu gefährden. Dazu kommt,
dass sich die Geräte unter verschiedenen mDNS-Diensten melden
(_ninlight._tcp gegen _ninstrip._tcp) und ohnehin getrennt gefunden
werden.
Das Gerüst ist aber bewusst eins zu eins von ninlight übernommen: gleiche Fehlerklassen, gleicher Coordinator-Aufbau, gleicher Einrichtungsablauf. Wer dort etwas korrigiert, findet es hier an derselben Stelle.
Einrichtung
Das Gerät meldet sich per mDNS und wird von Home Assistant vorgeschlagen.
Nötig ist nur das API-Token. Im Auslieferungszustand und nach jedem
Werksreset antwortet das Gerät mit dem öffentlichen Werks-Token
aabbccddeeff0011223344 — dasselbe wie bei ninlight —, und der Dialog belegt
es vor. Wer ein eigenes gesetzt hat, trägt es dort ein.
Vertrauensgrenze
Das Werks-Token steht öffentlich im Repo. Wer im selben WLAN ist und es kennt, kann das Gerät steuern, Einstellungen ändern und Firmware aufspielen. Das ist eine bewusste Entscheidung, gleich wie bei ninlight: Ziel ist, die Geräte einfach nutzbar zu halten, nicht ein gehärtetes Sicherheitsmodell.
Wer das nicht will, setzt ein eigenes Token — über die Firmware-API mit
PUT system/settings {"type": "token", "token": "..."} — und trägt es hier
ein. Für einen gehärteten Bau lässt sich das Werks-Token in der Firmware auch
ganz abschalten (NL_DEFAULT_TOKEN leer); dann würfelt das Gerät beim ersten
Start und gibt das Token einmalig seriell aus.
Ohne mDNS geht es auch von Hand über Adresse und Token.
Entitäten
| Entität | |
|---|---|
light |
Hauptschalter und Helligkeit des ganzen Strips |
select |
aufgeschaltete Szene (acht Plätze in der Firmware) |
button |
Neustart |
sensor |
WLAN-Signal, Laufzeit, freier Speicher, Leistungsbegrenzung |
switch |
sACN-Empfang an/aus |
number |
sACN-Universe und -Startslot |
select |
Verhalten nach Stromende (release / hold) |
binary_sensor |
sACN aktiv, Multicast beigetreten (letzterer standardmäßig aus) |
Die Diagnose-Sensoren sind standardmäßig abgeschaltet; die Leistungsbegrenzung ist an, weil sie verrät, ob die Strombegrenzung gerade herunterregelt (100 % heißt: tut sie nicht).
Eine Lichtentität je Gerät, nicht je Segment. device/state ist der
Hauptschalter und trägt keine Farbe — bei mehreren Segmenten gäbe es keine
eine Farbe, die stimmen würde. Die Segmente stellt man über Szenen.
Noch nicht drin
- Einzelne Segmente als eigene Entitäten
- Firmware-Aktualisierung über eine
update-Entität (die Firmware kann OTA mit Rückfallebene, die Integration nutzt es noch nicht)
sACN / E1.31
Aufbau wie ha-ninlight: die Einstellungen kommen aus system/settings, der
Zustand aus system/info, und nach jedem Schreiben wird zurückgelesen
statt angenommen — das Gerät prüft selbst, und eine Entität, die das
Gewünschte statt des Gespeicherten zeigt, lügt genau dann, wenn beides
auseinanderläuft.
Zwei Unterschiede zu ninlight:
- Kein Layout-Feld. ninstrip nutzt fest drei Kanäle je Pixel (R, G, B), so wie LedFx, xLights und Resolume senden.
- Der Startslot gilt in jedem Universe, nicht nur im ersten — ein Strip
verteilt sich über mehrere. Die Obergrenze ist deshalb
513 − 3 = 510: dahinter passt kein ganzes Pixel mehr hinein.
Jede Änderung über Home Assistant holt einem laufenden oder gehaltenen Strom die Kontrolle ab — das erledigt die Firmware.
Multicast über VLAN-Grenzen: „beigetreten" heißt nur, dass das Gerät der Gruppe beigetreten ist. Ob das Netz sie weiterreicht, steht auf einem anderen Blatt; ohne Multicast-Router kommt sie über eine VLAN-Grenze nie an. Unicast geht dann trotzdem.
Entwicklung
Die Integration wird in der gemeinsamen Dev-Instanz ha-dev per Mount
eingebunden, der Quellcode bleibt in diesem Repo.