Michael Sauer
8f877f18d0
Die Diagnose-Firmware meldet multicast: true, die Pakete kommen trotzdem nicht an. Damit ist die Firmware raus und die Suche hat eine Richtung: IGMP Snooping ohne Querier bzw. Multicast-Sperre auf dem IoT-WLAN. Dass mDNS laeuft, ist kein Gegenbeweis - 224.0.0.0/24 ist von der Filterung per Norm ausgenommen.
5.1 KiB
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.
Anzusehen waeren im UniFi-Setup fuer das IoT-Netz:
- WLAN-Einstellungen: "Multicast and Broadcast Control" bzw. "Block LAN to WLAN Multicast and Broadcast" - ist das aktiv, faellt die Gruppe weg, solange sie nicht ausdruecklich erlaubt ist.
- Netzwerk-Einstellungen: IGMP Snooping - entweder auf diesem VLAN abschalten (dann wird geflutet) oder sicherstellen, dass ein Querier laeuft. Snooping ohne Querier ist der klassische Weg, Multicast unbemerkt verschwinden zu lassen.
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.