ninlight-w600/docs/acceptance-sacn.md

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 - Ursache liegt im WLAN

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

Geklaert am 2026-09-20 mit einer Diagnose-Firmware (0.3.8-63-gfd61f, Commit fd61f15): system/info meldet seitdem sacn.multicast, also das Ergebnis von IP_ADD_MEMBERSHIP. Die Lampe liefert multicast: true - der Beitritt zur Gruppe gelingt. Die Pakete kommen trotzdem nicht an. Damit liegt es nicht an der Firmware, sondern am Netz: das WLAN reicht die Gruppe 239.255.0.1 nicht an die Lampe weiter.

Dass mDNS funktioniert, widerspricht dem nicht: 224.0.0.251 liegt im link-lokalen Bereich 224.0.0.0/24, den Switches und Access Points per Norm von der IGMP-Filterung ausnehmen und immer fluten. 239.255.0.1 unterliegt dagegen der Filterung.

Netzseite in derselben Nacht durchprobiert - ohne Erfolg:

Zustand im UniFi	Multicast kommt an?
Snooping aus, Multicast-zu-Unicast aus, kein Blocker (Ausgangslage)	nein
Multicast-zu-Unicast an	nein
zusaetzlich IGMP-Snooping an, Querier "Aus (Drittanbieter)"	nein
zusaetzlich Querier "Primaer/Failover"	nein
dasselbe, danach frischer Beitritt der Lampe erzwungen	nein (multicast: true gemeldet)

Unicast funktionierte in jeder dieser Varianten sofort. Der Multicast- und Broadcast-Blocker war durchgehend aus, Geraete- und L3-Isolierung ebenfalls.

Damit zeigt der Verdacht auf die Lampe. Wichtig fuer den naechsten Versuch: Das Feld sacn.multicast ist NICHT so aussagekraeftig, wie es aussieht. Es meldet nur, dass IP_ADD_MEMBERSHIP erfolgreich zurueckkam. Die SDK-Funktion, die den Hardware-Filter des W600 programmiert (ethernetif_igmp_mac_filter in sdk/Src/Network/lwip2.0.3/netif/ethernetif.c), steigt jedoch ganz oben mit

if (netif != tls_get_netif())
    return ERR_OK;

aus - sie meldet also Erfolg, OHNE den Filter gesetzt zu haben, wenn die Schnittstelle nicht die vom SDK als aktuell gefuehrte ist. Dann nimmt der Chip die Frames nie an.

Was in derselben Nacht noch geprueft und AUSGESCHLOSSEN wurde

• Der Ausstieg in ethernetif_igmp_mac_filter greift nicht. tls_get_netif() (sdk/Src/Network/lwip2.0.3/netif/wm_ethernet.c:473) liefert nif, und das ist das STA-Interface - genau das, auf dem der Beitritt laeuft. netif != tls_get_netif() ist also falsch, der Hardware-Schluessel wird gesetzt. Meine erste Theorie war damit falsch.
• Die Lampe empfaengt Multicast. Sie beantwortet eine mDNS-Anfrage, die ausschliesslich als Multicast an 224.0.0.251 ging.
• Die Lampe sendet Multicast. Nach einem Neustart sah der Pi ihre mDNS-Ankuendigung auf 224.0.0.251 - Multicast von WLAN-Geraet zu WLAN-Geraet ist also sichtbar und die Messung taugt.
• Im IGMP-Mitschnitt schweigt die Lampe. Querier-Abfragen (vom Gateway) und Meldungen anderer Geraete sind zu sehen, von der Lampe kommt weder eine Beitrittsmeldung noch eine Antwort auf die Abfrage. ABER: Bei aktivem Snooping leiten Switches Meldungen nur Richtung Router weiter - das Schweigen ist damit ein Indiz, kein Beweis.
• tls_filter_mcast_mac(gruppen_mac, 1) nach dem Beitritt aendert nichts. Die zweite, im SDK-Header dokumentierte Filterebene wird aus dem Quelltext nie aufgerufen; sie ausdruecklich zu oeffnen wurde gebaut, aufgespielt und getestet - Multicast kam weiterhin nicht an. Der Versuch wurde danach zurueckgenommen, die Lampe laeuft wieder auf main.
• Stromsparen/DTIM scheidet aus: Waere das die Ursache, kaeme auch mDNS nicht an.

Naechste Schritte, wenn es weitergeht

1. Serielle Konsole an eine Lampe haengen: sieht man beim Beitritt einen Sendeversuch der IGMP-Meldung? Das ist die einzige Messung, die das verbleibende Indiz zum Beweis macht.
2. Mitschnitt im Monitor-Modus (Laptop auf demselben Kanal) - zeigt, was wirklich ueber die Luft geht, unabhaengig davon, was der AP weiterreicht.
3. IGMP-Snooping einmal ganz aus und dabei mitschneiden: dann fluten Switches auch IGMP-Meldungen, und das Schweigen der Lampe waere eindeutig zu belegen oder zu widerlegen.
4. sacn.multicast ehrlicher benennen: es meldet den Rueckgabewert von IP_ADD_MEMBERSHIP, nicht die tatsaechliche Empfangsbereitschaft.

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.