Entwicklung / OLA + knxdmxd

[mclb]

Hi,

jetzt hab ich das Thema wieder einige Zeit schleifen lassen, soll aber jetzt bis Halloween noch ein paar nette Licht-Spielereien mit DMX an unserem Haus bauen.

Was ist jetzt eigentlich der aktuelle Stand, immer noch NanoDMX? Ich kann mich erinnern, dass Jan mal eine (bessere?) Alternative per Mail ausgeschickt hat, hab aber das Mail leider nicht mehr.

Der Stand im Repository sollte ja funktionieren, oder?

Danke
Marcus

[JNK]

Gibt es eigentlich Überlegungen den DPT 232.600 zu benutzen anstatt getrennter Kanäle für RGB?

Kurze Antwort: Wenn da jemand ein gutes Komzept und einen Patch für hat vielleicht. Ich brauche das nicht und habe vorläufig keine Zeit dafür.

Gruss,

der Jan

[swiss]

Naja KNX existiert schon seit 25 Jahren und damals hat man schon Leuchten mit dem DPT 5.001 (damals EIS 6) gedimmt. RGB LED sind erst seit ein paar Jahren auf dem Vormarsch. Und da schon von früher her viele KNX Sensoren den DPT 5.001 unterstüzen wurde für RGB einfach 3x DPT:5.001 genommen. Somit kann man selbst mit einem alten Siemens Infodisplay die neuen RGB Dimmer ansteuern . Der DPT:232.600 ist relativ neu und wird leider noch nicht von so vielen Geräten unterstützt. Desshalb würde ich es für sinnvoll halten wenn man hier vorübergehend zweigleisig fahren würde

[ctr]

Ja sicher, wenn dann zusätzlich und nicht anstatt.
Mein Zennio Z41 kann z.B. beides.

Irgendwie ist das doch aber eher ein Workaround Werte auf 3 verschiedenen GA's zu übertragen oder kommt das nur mir (der in sich in das Thema gerade hereinliest) komisch vor?

[swiss]

Wie viele KNX Geräte/Visus unterstützen denn den DPT 232.600? Es bringt ja nix, wenn man dass auf einen exotischen DPT ändern würde und damit über 2/3 der Eingabegeräte aussperren würde. Das halte ich nicht gerade für sinnvoll. Höchstens als zusätzliche Option zur bestehenden DPT 5.001 Lösung...

[ctr]

Gibt es eigentlich Überlegungen den DPT 232.600 zu benutzen anstatt getrennter Kanäle für RGB?

[Dutchy]

Hi Jan,

ich kann gerne testen.

Gruß
Dutchy

[ndorf]

Moin,

kann ich auch das ArtNet Node von Ulrich Radig nutzen, wenn ja, was muss ich wie einstellen. Habe schon diverse Stunden probiert und bekomme es nicht ans Laufen.

Habe schon diverse Internetseiten durch und komme nicht weiter.

Ich würde auch alles testen.


Gruß

Andreas

[JNK]

So, nachdem es jetzt zwei Tage problemlos bei mir im Produktiv-Einsatz ist: Ich habe eine E1.31-only-knxdmxd Version programmiert. Mit einer passenden Bridge entfällt OLA, wenn man was anderes z.B. NanoDMX hat, kann OLA als Bridge verwendet werden.

Ich suche jetzt Freiwllige, die das ausprobieren wollen, begrenzt kann ich beim Einrichten Support leisten. Wer will?

Gruss,

der Jan

Edit: Konfig ist voll-kompatibel.

[JNK]

Entwicklung / OLA + knxdmxd

Hallo,

so ganz einfach ist das nicht. Ich empfehle den Umweg über UDP und socat, das beseitigt zumindest das Problem des stty und beseitigt auch das Flackern das beim Faden sonst manchmal auftritt.

Was die Reihenfolge des Startens von OLA und knxdmxd gibt es eine neue Version, die beim Starten des knxdmxd auf OLA wartet statt selbst eine Instanz zu starten. Ich glaube aber, die ist noch nicht in einem Package. Es reicht die Version aus dem SVN herunterzuladen und in /usr/bin abzulegen (ersetzt einfach die bisherige, Rest bleibt gleich und wird bei einem Package-Update wieder überschrieben).

Ich arbeite an einem knxdmxd v2, der kein OLA benötigt sondern direkt E1.31 spricht. OLA kann das auch, dann kann man in OLA einen E1.31 Port als Input für ein Universe und z.B. das NanoDMX als Output für dieses Universe patchen. Vorteil ist dabei, dass die Reihenfolge völlig egal ist und Leute wie ich, die eine E1.31-DMX-Bridge haben, kein OLA benötigen. Zeitplan gibts dafür aber erstmal keinen, das Grundgerüst läuft, aber ich habe wenig Zeit.

Gruss,

der Jan

[ndorf]

OLA + knxdmxd automatisiert starten.

Tach,

ist es möglich, dass OLA + knxdmxd nach einem Neustart des Wiregate automatisch funktionsfähig läuft?!

Hintergrund ist, dass mein Wiregate regelmäßig in unregelmäßigen Abständen (ca. 1 Woche) neu startet. (Leider weiß ich noch nicht warum). Nach dem Neustart muss ich dann immer OLA killen, "d stty -F /dev/dmx eol G" ausführen, OLA und knxdmxd neu starten. Dann funktioniert es wieder bis zum nächsten Neustart.


Danke

Gruß

Andreas

[JNK]

Ich hab dann mal ein gestripptes Binary und den Codechange ins SVN eingecheckt, Package kann ich nicht, vielleicht kann sich das jemand von Elabnet angucken.

Gruss,

der Jan

Edit: Ich hätte jetzt auch ein fertiges Package. Nur ins Repository krieg ich das natürlich nicht.

[Dutchy]

Hi Jan,

funktioniert prima. Vielen vielen Dank für die schnelle Umsetzung.

Gruß
Dutchy

[JNK]

Genau so ist es. Das Problem war die Umrechnung interner Adressen. Ich speichere

internerdmx = universe*512+channel

damit wird 1.1 zu 513, 1.2 zu 514 usw. bis 1.512 zu 1024

zum Senden mache ich daraus dann

universe = (int) internerdmx / 512
channel= internerdmx%512

Das geht natürlich bei 512 schief, weil 1024/512 = 2 und 1024%512=0

jetzt wird

universe = (int) (internerdmx-1) / 512
channel = internerdmx - 512*universe

gerechnet, das sollte passen. Ich habe das jetzt geändert und einen neuen knxdmxd kompiliert. Bitte einmal ausprobieren.

/etc/init.d/knxdmxd stop
die angehängte Datei als knxdmxd nach /usr/bin legen entpacken
/etc/init.d/knxdmxd start

Gruss,

der Jan

[Dutchy]

Ich habe noch was getestet. Die Kiteo Lampe ist werksseitig auf Kanal 1-4 eingestellt. Wenn ich jetzt auf Kanal 1-4 was sende, dann kommt auch das erwartete Ergebnis raus.
Also scheint der Kanal 512 nicht geschrieben zu werden, sondern nur 1-511.

Gruß
Dutchy