Files

T

Michael Sauer aa0ed770eb docs(sacn): Abnahmeprotokoll der Hardwarepruefung

Sieben Pruefpunkte an einer E27 RGB, dazu das OTA aus Home Assistant. Zwei
Befunde stehen mit drin, weil sie sonst verlorengehen: Multicast erreicht die
Lampe nicht (Unicast schon), und eine sACN-Quelle aus einem anderen Netz liefert
sichtbar ruckelige Rampen. Beim Multicast ist auch festgehalten, was NICHT
geprueft werden konnte und warum - der Beitritt wird derzeit bewusst ignoriert,
also weiss niemand, ob er scheitert.

2026-09-20 02:21:19 +02:00

4.9 KiB

Raw Blame History

Abnahme sACN/E1.31

Datum: 2026-09-20, nachts Lampe: Klyqa E27 RGB CW/WW, 192.168.2.204, MAC 28:6d:cd:5c:7f:5b, Board e27_rgb (6 Slots) Firmware vorher: 0.3.8-36-gca9bb — nachher: 0.3.8-61-g9b80a Sender: tools/sacn_send.py, ausgefuehrt vom Pi ninlight-station (192.168.2.96), also aus demselben Netz wie die Lampen.

Ergebnis

Bestanden, mit einer benannten Einschraenkung: Multicast erreicht die Lampe nicht, Unicast funktioniert vollstaendig. Siehe den eigenen Abschnitt unten.

Einzelne Schritte

#	Pruefpunkt	Wie geprueft	Ergebnis
0	OTA aus Home Assistant	`update.install` auf der Update-Entitaet, Abbild aus dem Firmware-Ordner der Produktiv-HA	bestanden; Lampe nach dem Neustart mit Uptime 12 s zurueck, WLAN unveraendert
0a	Versionsvergleich der Integration	HA meldete `0.3.8-36-gca9bb` -> `0.3.8-61-g9b80a` als Update	bestanden; HAs eingebauter Vergleich haette diese Git-Versionen falsch sortiert, der eigene greift
0b	Vorgaben nach dem Update	`GET system/settings`	bestanden: `enabled true`, Universe 1, Startslot 1, `release`, `slots 6`
1	Uebernahme, Farbe	Gruen per Unicast, 60 s	bestanden (Sichtpruefung Michael: "leuchtet gruen")
2	Dimmer-Rampe	0..255 und zurueck, 25 fps	bestanden nach Wechsel des Senders auf den Pi, siehe "Ruckeln" unten
3	Timeout, Modus `release`	30 s Blau, dann Strom beenden	bestanden: nach 2,5 s zurueck auf den HA-Zustand (rot, 21 %), Sicht + `device/state`
4	Timeout, Modus `hold`	Nullen senden, dann Strom beenden	bestanden: Lampe blieb dunkel, obwohl HA "an, rot" hielt
5	HA holt die Kontrolle zurueck	`light.turn_on` waehrend die Lampe im `hold` dunkel festhing	bestanden: sofort gelb/80 %, `sacn.active` aus
6	Abbruch-Bit	Zweimal gemessen, mit und ohne `--terminate`	bestanden: 0,1 s mit Abbruch-Bit gegen 2,5 s ueber den Timeout
7	Universe im Betrieb wechseln	auf 12 umgestellt, dann auf 1 und auf 12 gesendet	bestanden: altes Universe wirkungslos, neues uebernimmt, kein Neustart

Nicht auf Hardware geprueft: ein Board ohne RGB (3 Slots, Dimmer/CW/WW). Dafuer haette eine zweite Lampe geflasht werden muessen. Abgedeckt ist der Fall durch die Host-Tests (test_dmx.c, test_board_without_rgb_uses_three_slots) und die board-abhaengige Slotgrenze in test_api.c.

Befund: Multicast erreicht die Lampe nicht

Unicast an die Lampen-IP funktioniert durchgaengig. Multicast auf 239.255.0.1 kommt nicht an — auch nicht von einem Sender im selben Netz.

Was dagegen gesichert ist:

Die Lampen empfangen Multicast grundsaetzlich: Alle sieben im Netz antworten auf eine mDNS-Anfrage an 224.0.0.251.
Der Unterschied liegt also im Gruppenbeitritt fuer 239.255.0.1, nicht im Empfang an sich.
Das SDK programmiert beim IGMP-Beitritt einen Hardware-Multicast-Filter (ethernetif_igmp_mac_filter -> tls_hw_set_multicast_key). Die Funktion selbst liegt in einer vorkompilierten SDK-Bibliothek und ist im Quelltext nicht einsehbar.
nl_sacn.c ignoriert das Ergebnis von IP_ADD_MEMBERSHIP bewusst (ein fehlgeschlagener Beitritt soll den Unicast-Empfang nicht verhindern). Genau deshalb ist derzeit nicht feststellbar, ob der Beitritt scheitert.

Naechster Schritt zur Klaerung: das Ergebnis des Beitritts sichtbar machen (Konsolenzeile oder Feld in system/info), neu aufspielen und nachsehen. Erst dann laesst sich sagen, ob die Lampe nicht beitritt oder das WLAN die Gruppe nicht weiterreicht.

Zwei Fehlversuche auf dem Weg dorthin, damit sie niemand wiederholt:

Der erste Multicast-Test lief vom Mac (192.168.1.131) gegen eine Lampe in 192.168.2.x. Multicast wird zwischen den Netzen nicht geroutet — der Test konnte gar nicht gelingen.
Der zweite liess den Pi in die Gruppe eintreten und an sie senden. Ein Access Point schickt einem Sender seine eigenen Multicast-Frames nicht zurueck; das Ergebnis war aussagelos, nicht negativ.

Befund: Ruckeln bei der Dimmer-Rampe

Die erste Rampe kam sichtbar ruckelig an ("ruckelt sehr"). Gesendet wurde vom Mac, der in einem anderen Netz haengt als die Lampen; jedes Paket lief ueber den Router. Dieselbe Rampe vom Pi aus, im selben Netz wie die Lampe, lief deutlich glatter ("viel besser").

Fuer den Einsatz heisst das: Die sACN-Quelle gehoert in dasselbe Netz wie die Lampen.

Nicht geprueft, weil dafuer eine alte Firmware noetig waere

Der Migrationspfad aus dem kritischen Befund des Schlussreviews (ein vor sACN geschriebener 208-Byte-Datensatz darf sacn_enabled nicht ueberschreiben) wurde auf dieser Lampe nicht durchlaufen: Sie trug keinen gespeicherten Einstellungssatz, alle Werte standen auf Vorgabe. Abgedeckt ist der Fall durch den Host-Test in test_settings.c, der vor dem Fix fehlschlug und danach besteht. Wer ihn auf Hardware sehen will, nimmt eine Lampe, deren Einschaltverhalten vom Vorgabewert abweicht — die traegt einen echten alten Datensatz.

4.9 KiB Raw Blame History