MDT LED Controller vs. MDT DALI Gateway

[gbglace]

Du brauchst die Leitungen an der Stelle wo Licht hin soll.

Stabiler wird die Planung, wenn die Leitung da endet wo das Licht herkommen soll.

[gbglace]

in den letzten Jahren DMX im Heimsektor gewaltig überholt

Bei DMX hapert es immer nur an einer ausreichend schnellen Logik die die Dimmstufen rechnen und schicken kann. Auf Basis ist das eben alles viel zu langsam wenn man das alles über den Bus schicken will. Die verkauften Stückzahlen an KNX_DMX GW sind da auch nicht förderlich als das sich das ein Hersteller antut da viel zu bieten. Weinzierl hat da ein kleine DMX-GW mit schon interessanten Parametern. Was man an den DMX-EVG beachten muss ist, dass es da viele günstige gibt, nur wird denen sowas wie die asynchrone Kanalschaltung die bei den leistungsstarken TW-Leuchtmitteln notwendig ist, um da nicht auf beiden Kanälen gleichzeitig im PWM-Zyklus AN zu sein. Die Begrenzung auf 50/50 ist als Einstellung in der Logik bei DMX auch noch gut vor dem GW / Busmaster umsetzbar, wenn zwischen Logik und GW nicht noch eine KNX-Busstrecke sitzt.

[derneugierige]

MDT baut leider keine DALI LED-Treiber, sonst könnten sie mögliche Probleme des optimalen Zusammenspiels inhouse lösen.

Wieso sollten die ein Interesse an einem "optimalen Zusammenspiel" haben? Verdienen die doch an den KNX-Controllern wesentlich besser als an DALI-Gateways...

... jetzt hör' ich aber lieber auf, bevor ich noch zu sehr OT werde.

Wieso OT?

Kurz noch meine Meinung zum Thema "ruckeliges dimmen".

Was genau meinst Du damit?

Ich halte hier das Zusammenspiel zwischen Gateway und Treiber für den Schuldigen.

Wenn Geräte nicht sauber zusammenspielen, dann soll es schon vorgekommen sein, dass einer der Teilnehmer das Protokoll nicht sauber implementiert.

[scw2wi]

Das ruckeln kam von Dustin weiter oben.

[Gast1961]

Wieso sollten die ein Interesse an einem "optimalen Zusammenspiel" haben? Verdienen die doch an den KNX-Controllern wesentlich besser als an DALI-Gateways...

Das ist doch Unfug. Wenn es irgendwo hakte hat MDT das bisher schnell und engagiert gelöst. Wohingegen es den einen oder anderen Hersteller von DALI-Treibern gibt, der seine Kunden mit missglückter Firmware und seltsamen Defaults beglückt.

Das ruckeln kam von Dustin weiter oben.

Rant: Da war bestimmt wieder ein Lunatone-Dimmer beteiligt.

[scw2wi]

Das dachte ich mir auch, dass ein Ruckeln eher vom Dimmer als vom Gateway kommen wird. Leider kenne ich aktuell keinen Test von verschiedenen Kombinationen.

[derneugierige]

Das ruckeln kam von Dustin weiter oben.

Ah jetzt.

Da ist zunächst die Frage, die das Gateway die Dimmung implementiert. Schickt es tatsächlich einen Befehl "in den nächsten X Sekunden Helligkeit auf Y dimmen" oder schickt es über den Zeitraum einzelne Helligkeitswerte?

[derneugierige]

Das ist doch Unfug. Wenn es irgendwo hakte hat MDT das bisher schnell und engagiert gelöst.

Kannst Du Beispiele nennen?

Vergleich doch mal den Funktionsumfang des KNX-Dimmers mit dem des DALI-Gateways. Und jetzt erzähl mir nicht, dass das technischen Notwendigkeiten geschuldet ist.

Wohingegen es den einen oder anderen Hersteller von DALI-Treibern gibt, der seine Kunden mit missglückter Firmware und seltsamen Defaults beglückt.

Oh, da kann ich von MDT aber auch Beispiele nennen.

[derneugierige]

Das dachte ich mir auch, dass ein Ruckeln eher vom Dimmer als vom Gateway kommen wird.

Kannt Du diese Vermutung irgendwie begründen?

Ich halte es für wahrscheinlicher, dass das Gateway einzelne Helligkeitswerte schickt anstatt eines Dimm-Kommandos. Wenn das so sein sollte, dann kann das EVG rein gar nichts dafür. Es führt lediglich Befehle des Gateways aus.

Leider kenne ich aktuell keinen Test von verschiedenen Kombinationen.

Klarheit kann nur ein Blick auf den Bus schaffen. Alles andere ist reine Spekulation.

[Gast1961]

Vergleich doch mal den Funktionsumfang des KNX-Dimmers mit dem des DALI-Gateways. Und jetzt erzähl mir nicht, dass das technischen Notwendigkeiten geschuldet ist.

Nein, alles böser Wille. So sind die Hersteller, die machen ihre Produkte so unattraktiv wie möglich.

Kannst Du Beispiele nennen?

Klar, z.B. haben Der Standart und ich mit dem MDT-Support seltsame Effekte mit den Dimmkurven gelöst, wo der minimale Dimmwert nicht passte. Das war tatsächlich eine Kombination aus Firmware- und Datenbankfehlern auf MDT-Seite.

Ich halte es für wahrscheinlicher, dass das Gateway einzelne Helligkeitswerte schickt anstatt eines Dimm-Kommandos. Wenn das so sein sollte, dann kann das EVG rein gar nichts dafür. Es führt lediglich Befehle des Gateways aus.

Es könnte ein Einfluß der PWM-Frequenz sein, die bei Lunatone die Dimmschritte bestimmt. Und bei 144Hz Flimmer-PWM könnte eine schnelle Folge von Dimmschritten schon zu schnell sein und sichtbare Unstetigkeiten verursachen.

[derneugierige]

Nein, alles böser Wille. So sind die Hersteller, die machen ihre Produkte so unattraktiv wie möglich.

Lege mir bitte keine Worte in den Mund die ich nie geschrieben habe.

Es ist gar nicht so unüblich, dass es Abstufungen der Produkte gibt. Wenn das preiswerte Consumer-Produkt den gleichen Funktionsumfang hat wie das Premium-Produkt, dann würde niemand das Premium-Produkt kaufen.

Manche Hersteller vermarkten die gleiche Hardware mit unterschiedlicher Firmware. Oder schalten bestimmte Funktionalitäten nur gegen Aufpreis frei.

Ich bin selbst in der Produkt-Entwicklung tätig und könnte Dir so manches aus dem Nähkästchen erzählen... Ist hier aber stark OT.

Wenn MDT im DALI-GW den gleichen Funktionsumfang implementiert wie im KNX-Controller, dann graben die sich den eigenen Umsatz ab. Ist doch klar. Aus Sicht von MDT kann ein DALI-GW ein ganzes EFH versorgen. Wird dasselbe mit KNX-Controllern realisiert, hat MDT ein Vielfaches an Umsatz. Warum sollte MDT viel Aufwand reinstecken um das GW zu verbessern? Es ist doch wesentlich sinnvoller den Aufwand in die Verbesserung des KNX-Controllers zu stecken.

Und nein: Im Gegensatz zu Deiner Vermutung kreide ich das MDT in keinster Weise an. Das ist eine vollkommen rationale Entscheidung.

Was ich ankreide ist die daraus gezogene Schlussfolgerung, dass DALI unausgereift ist.

Klar, z.B. haben Der Standart und ich mit dem MDT-Support seltsame Effekte mit den Dimmkurven gelöst, wo der minimale Dimmwert nicht passte. Das war tatsächlich eine Kombination aus Firmware- und Datenbankfehlern auf MDT-Seite.

Somit war das ein rein internes Problem bei MDT.

Es ging um "optimalen Zusammenspiel". Also um Fälle, in denen beide Seiten zur Misäre beitragen. Das Beheben eines selbst verursachten Problems zählt dabei nicht.

Es könnte ein Einfluß der PWM-Frequenz sein, die bei Lunatone die Dimmschritte bestimmt. Und bei 144Hz Flimmer-PWM könnte eine schnelle Folge von Dimmschritten schon zu schnell sein und sichtbare Unstetigkeiten verursachen.

Ich habe mir erlaubt, die wichtigen Worte hervorzuheben.

Genau das habe ich doch in #37 und #39 geschrieben. Lies diese beiden Beiträge noch einmal aufmerksam.

Wenn dem so ist, dann wäre das aber nicht ein Problem des "optimalen Zusammenspiels" sondern eine Unzulänglichkeit im Gateway...

Das dem EVG oder dem "optimalen Zusammenspiel" zuzuschreiben wäre dann schon ein wenig merkwürdig. Das EVG tut genau das was das GW sagt. Dass das GW leider nur einen sehr eingeschränkten Sprachschatz verwendet ist weder die Schuld des EVG noch die von DALI. Und wenn hier immer vorgebetet wird, dass das nicht optimal zusammenspielt, dann fördert das den Absatz an KNX-Controllern. Nenn doch mal nur einen einzigen Grund warum MDT ein Interesse haben sollte dieses Zusammenspiel zu optimieren?

Oh, und wenn die PWM nur 144Hz beträgt, so ist auch das kein prinzipielles Problem von DALI, sondern schlicht eine schlechte Implementierung des EVG. Ja, auch auf der anderen Seite kann es Unzulänglichkeiten geben.

[Gast1961]

Es ist gar nicht so unüblich, dass es Abstufungen der Produkte gibt. Wenn das preiswerte Consumer-Produkt den gleichen Funktionsumfang hat wie das Premium-Produkt, dann würde niemand das Premium-Produkt kaufen.

Auch wenn im KNXUF die 24V-Technik beliebt ist: DALI ist wichtig auch für Konstantstromtreiber, das ist ein viel größerer Markt als 24V. Das DALI-Gateway in den Funktionen zu beschneiden macht so gesehen wenig Sinn, weil es nur in einem Teilmarkt mit den Anwendungen des LED-Controllers überlappt.

Oh, und wenn die PWM nur 144Hz beträgt, so ist auch das kein prinzipielles Problem von DALI, sondern schlicht eine schlechte Implementierung des EVG. Ja, auch auf der anderen Seite kann es Unzulänglichkeiten geben.

So meinte ich es auch. Leider werden daraus so falsche Zusammenfassungen wie #25

Um nochmals auf die Dimmschritte zurückzukommen: Du unterstellst, dass man einem DALI-Treiber einen Einzelbefehl senden kann "Soft AUS mit Dimmzeit xxx Sekunden". Ich bezweifle, dass DALI sowas kennt. Vielleicht gibt es die Möglichkeit, ein Soft-Schalten mit fester Dimmzeit per DALI-Maus zu hinterlegen, aber damit könnte man diese Zeit nicht in der ETS ändern im Gateway. Oder hast du andere Erkenntnisse zum DALI Befehlsumfang?

[derneugierige]

Auch wenn im KNXUF die 24V-Technik beliebt ist: DALI ist wichtig auch für Konstantstromtreiber, das ist ein viel größerer Markt als 24V. Das DALI-Gateway in den Funktionen zu beschneiden macht so gesehen wenig Sinn, weil es nur in einem Teilmarkt mit den Anwendungen des LED-Controllers überlappt.

Ich sage ja nicht dass da Funktionen beschnitten werden. Es fehlt aber an Motivation, es genau so gut zu machen wie beim KNX-Controller.

So meinte ich es auch. Leider werden daraus so falsche Zusammenfassungen wie #44.

Hast Du eine Kristallkugel und kannst voraussehen was in #44 geschrieben werden wird? ;-)

Um nochmals auf die Dimmschritte zurückzukommen: Du unterstellst, dass man einem DALI-Treiber einen Einzelbefehl senden kann "Soft AUS mit Dimmzeit xxx Sekunden".

Naja, in meinem Jugendlichen Leichtsinn hätte ich jetzt gehofft, dass das ungefähr so gemacht wird wie in Kapitel 9.5 von EN 62386-102 beschrieben ist.

Ich bezweifle, dass DALI sowas kennt.

Ohne lange zu suchen finde ich in Kapitel 9.5 zB Befehle wie:

SET FADE TIME
SET FADE RATE
SET EXTENDED FADE TIME

und dann auch

UP
DOWN
CONTINOUS UP
CONTINOUS DOWN

Da gibt es auch mehr. Gibt möglicherweise auch noch Abhängigkeiten zu den Datentypen. Details habe ich mir jetzt nicht angeschaut, habe schliesslich auch noch einen Day-Job. Eigentlich ist es die Aufgabe der MDT-Entwickler, diese Dokumente durchzuarbeiten.

Natürlich kann man auch die einzelnen Helligkeitswerte verschicken. Dann muss man sich aber nicht wundern wenn das Ergebnis eher bescheiden ist...

Und ich sage auch nicht, dass DALI perfekt ist. Aber alle Unzulänglichkeiten eines bestimmten GW als prinzipielles Problem mit DALI (oder von mir aus auch mit Lunatone) darzustellen ist IMHO auch nicht angebracht. Man sollte Kritik da anbringen wo sie auch hingehört.

[Gast1961]

Ja, einverstanden. Danke für den Einblick, daß die Dimmwert-Rampe nicht vom Gateway erzeugt werden muss. Das klingt sehr sinnvoll.

[derneugierige]

Wer mag die Luft anhalten bis MDT dieses nicht "optimale Zusammenspiel" "schnell und engagiert" löst?

SCNR! 😉