Entwicklung / OLA + knxdmxd

[Dutchy]

Hi zusammen,

ich habe aktuell genau mit der Sache ein Problem. Also 0-511 oder 1-512.

Ich habe mir ein paar LED Lampen von Kiteo zugelegt. Diese haben keine DIP Schalter zum Konfigurieren der DMX Adresse, sondern man schickt an die Adressen 501, 502. 504 und 512 bestimmte Werte. Dann ist der LED Strahler, der gerade am DMX Bus hängt mit einer bestimmten Adresse belegt.

In der knxdmx.conf habe ich folgendes drin:

"channels" : [
...
  { "name" : "hk_kiteo_konfiguration_1", "dmx" : "1.501", "statusga" : "11/0/201" },
  { "name" : "hk_kiteo_konfiguration_2", "dmx" : "1.502", "statusga" : "11/0/202" },
  { "name" : "hk_kiteo_konfiguration_3", "dmx" : "1.504", "statusga" : "11/0/204" },
  { "name" : "hk_kiteo_konfiguration_4", "dmx" : "1.512", "statusga" : "11/0/212" }
],
"dimmers": [ // all dimmer definitions, name is optional (default is _d_<number>), knx-like dimming: fading is calculated for 0-100% 
...
  { "name" : "Kiteo Konfiguration 501", "channel" : "hk_kiteo_konfiguration_1", "ga" : "12/0/201" },
  { "name" : "Kiteo Konfiguration 502", "channel" : "hk_kiteo_konfiguration_2", "ga" : "12/0/202" },
  { "name" : "Kiteo Konfiguration 504", "channel" : "hk_kiteo_konfiguration_3", "ga" : "12/0/204" },
  { "name" : "Kiteo Konfiguration 512", "channel" : "hk_kiteo_konfiguration_4", "ga" : "12/0/212" }

Wenn ich jetzt die Werte sende, dann sehe ich, dass auf den Status GA sich für 3 von 4 was tut und die 1.512 (bzw. 11/0/212) fehlt.

root@wiregate:/var/log# tail -f eib.log|grep '11/'
2013-04-30 16:34:50.866,A_GroupValue_Write,1.1.253,11/0/201,02,,,,0,low,7,T_DATA_XXX_REQ,0
2013-04-30 16:34:52.896,A_GroupValue_Write,1.1.253,11/0/202,29,,,,0,low,7,T_DATA_XXX_REQ,0
2013-04-30 16:34:53.890,A_GroupValue_Write,1.1.253,11/0/204,FF,,,,0,low,7,T_DATA_XXX_REQ,0

Wenn ich den Wert im Abschnitt status von 1.512 auf 1.511 ändere, dann wird auch für diese Adresse was zurückgemeldet.

root@wiregate:/var/log# tail -f eib.log|grep '11/'
2013-04-30 16:35:57.859,A_GroupValue_Write,1.1.253,11/0/201,02,,,,0,low,7,T_DATA_XXX_REQ,0
2013-04-30 16:35:58.851,A_GroupValue_Write,1.1.253,11/0/212,02,,,,0,low,7,T_DATA_XXX_REQ,0
2013-04-30 16:35:59.903,A_GroupValue_Write,1.1.253,11/0/202,29,,,,0,low,7,T_DATA_XXX_REQ,0
2013-04-30 16:36:00.899,A_GroupValue_Write,1.1.253,11/0/204,FF,,,,0,low,7,T_DATA_XXX_REQ,0

Wie wird denn da jetzt gezählt? Wenn ich überall minus 1 mache, also 500, 501, 503 und 511 wird die Lampe auch nicht programmiert.

Meine anderen DMX Geräte reagieren aber genau auf die in den Status hinterlegten Kanälen.

Oder wird durch einen Bug für 512 nichts gesendet?

Gruß
Dutchy

[vietgilles]

Wenn ein Dimmer einen Adressbereich von 0 bis 511 hat ist dieser nicht normkonform.
Man hat den Adressbereich von 1 bis 512 gewählt um ein DMX Gerät aus dem Bus programmieren zu können. Dipschalter alle auf aus, Gerät wird vom Bus nicht angesprochen, gleich Adresse 0. Da bis zu 32 Geräte an einem Strang hängen können ist dies vorteilhaft.
Aus Erfahrung mit der Beleuchtungstechnik/Bühnentechnik kann ich Deine Aussage aber bestätigen. Es gibt Geräten mit dem Adressbereich 0-511. Aber wozu gibt es eine Norm wenn sich alle daran halten würden.

Mfg vietgilles

[JNK]

Entwicklung / OLA + knxdmxd

Universe stimme ich Dir zu. Adresse bin ich etwas ambivalent. Richtig ist, die Kanaele heißen 1-512, auf der anderen Seite muss man an den Dimmern 0-511 einstellen....

Gruß,

der Jan

[vietgilles]

Zur allgemeinen Information über DMX

Die Spezifikation der Adressen besagt das die erste DMX-Adresse nicht 0 sein darf,
das gleiche gilt auch für ein Univers.
Es wäre hilfreich wenn im Programm dieser "Fehler" abgefangen würde

Mfg vietgilles

[JNK]

Also das hat bei mir auch nicht funktioniert. Ich habe dem Switch mitgeteilt, dass 239.255.0.1 nur an die Ports des Wiregate und der Bridge gesendet werden sollen.

Ich habe aber auch vorher keine spürbare Beeinträchtigung festgestellt.

Gruss,

der Jan

[jorues]

Ok, danke für die Antwort! Also wird alle 50ms ein refresh gesendet, unabhängig davon ob sich am eibd was getan oder nicht?

Benutzt du für E1.31 dann ein eigenes Netz oder machst du das über IGMP? Unterstützt das E1.31 IGMP überhaupt?

Warum ich so Nachfrage: Mir ist aufgefallen, dass das "ACT-Blinken" an allen Ports vom Switch und den daran angeschlossenen Teilnehmern nach starten von knxdmxd deutlich steigt. Eigentlich habe ich IGMP aktiviert, was ja bei Multicast die Pakete nur an die "angemeldeten" Ports weiterleiten soll.
Muss das noch einmal kontrollieren, vlt. ist auch ein Setting noch nicht ganz richtig.

Gruß
Johannes

[JNK]

20 pro Sekunde hört sich sehr gut an, Es gibt alle 50ms ein DMX Update und damit ein Paket.

Gruss,

der Jan

[jorues]

Hallo,

ertsmal vielen Dank für euern Einsatz. Meine DIYLEDEXPRESS - Bridges sind am Montag auch angekommen und schon fertig aufgebaut.

Soweit funktioniert auch alles Top!

Aber hat mal jemand von euch das Wireshark angeschmissen, während der knxdmxd läuft?
Wenn das reine Ola läuft sind es max 1-2 Multicast-Pakete pro Sekunde aber wenn ich den knxdmxd starte sind es zwischen so ca. 20 oder mehr Pakete pro Sekunde (habs nicht nachgezählt). Ist das so richtig? Oder ist bei mir irgendwo der Wurm drin?
Kann das mal jemand nachprüfen?
Hier mal meine Konfig:

// CAUTION : never uses names starting with _ !!! These are used internally ! 
{ 
"channels" : [
  { "name" : "kiteo_1", "dmx" : "1.1", "statusga" : "1/0/0"},
  { "name" : "kiteo_2", "dmx" : "1.2", "statusga" : "1/0/1"},
  { "name" : "kiteo_3", "dmx" : "1.3", "statusga" : "1/0/2"},
  { "name" : "kiteo_4", "dmx" : "1.4", "statusga" : "1/0/3"}
],
"dimmers": [ // all dimmer definitions, name is optional (default is _d_<number>), knx-like dimming: fading is calculated for 0-100% 
  { "name" : "Kiteo1", "channel" : "kiteo_1", "ga" : "1/1/0" },   
  { "name" : "Kiteo2", "channel" : "kiteo_2", "ga" : "1/1/1" },
  { "name" : "Kiteo3", "channel" : "kiteo_3", "ga" : "1/1/2" },
  { "name" : "Kiteo4", "channel" : "kiteo_4", "ga" : "1/1/3" }
],
"scenes": [ // all scene definitions
],
"cuelists": [ // all cuelists
]
 }

Wobei ich nicht denke, dass es daran liegt?!

Vielen Dank und beste Grüße

Johannes

Ergänzung: Betrifft natürlich nur diejenigen, die über eine E1.31 oder ArtNet mit dem DMX kommunizieren.

[JNK]

So, nochmal ein kurzer Bericht:

1) Es gibt ein neues Package seit einigen Tagen, darin ist das "autostarten" einer OLA-Instanz mit den falschen Paramatern unterbunden. Ausserdem sollte, falls es einen Neustart des knxdmxd gibt,beim stoppen des Dämons sauberer aufgeräumt werden.

2) Wie irgendwo (in diesem oder dem anderen) Thread beschrieben, habe ich mir eine E1.31->6xDMX Bridge bestellt. Das läuft inzwischen bei mir einwandfrei, Damit ist zumindest für mich auch das Problem des am USB abfliegenden NanoDMX gelöst.

3) Feature-Wünsche?

Gruss,

der Jan

[ndorf]

Es leuchtet! :-)

Der Jan hatte recht!!

War da gestern Abend wohl nicht richtig bei der Sache.

Danke für die Hilfe!!!

Gruß

Andreas

[Dutchy]

Hi.

Geh mal mit ssh als User root auf das Wiregate und dann gebe mal folgenden Befehl ein (also ab "netstat ..."):

root@wiregate:~# netstat -taupen|grep 127.0.0.1|grep -v '-'

und schaue mal nach, welcher Prozess denn auf Port 9010 schon drauf sitzt.

Sah bei mir gerade so aus:

tcp        0      0 127.0.0.1:8001          0.0.0.0:*               LISTEN      0          5246        1935/openvpn    
[B]tcp        0      0 127.0.0.1:9010          0.0.0.0:*               LISTEN      1000       13587       5599/olad[/B]       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          6696        2507/exim4      
tcp        0      0 127.0.0.1:9010          127.0.0.1:42545         VERBUNDEN   1000       14138       5599/olad       
tcp        0      0 127.0.0.1:51660         127.0.0.1:6720          VERBUNDEN   0          6440        2243/linknx     
tcp        0      0 127.0.0.1:54422         127.0.0.1:10001         VERBUNDEN   1000       13594       5599/olad       
tcp        0      0 127.0.0.1:42545         127.0.0.1:9010          VERBUNDEN   0          14137       5882/knxdmxd    
tcp        0      0 127.0.0.1:6720          127.0.0.1:51660         VERBUNDEN   0          6441        2025/eibd       
tcp        0      2 127.0.0.1:10001         127.0.0.1:54422         VERBUNDEN   0          6801        2553/socat      
tcp        1      0 127.0.0.1:42304         127.0.0.1:4304          CLOSE_WAIT  0          8080        2581/owhttpd    
udp        0      0 127.0.0.1:57547         127.0.0.1:514           VERBUNDEN   0          5432        1946/perl       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           0          6472        2170/ntpd

Gruß
Dutchy

[ndorf]

Keine Änderung

[JNK]

Entwicklung / OLA + knxdmxd

Einmal

ps ax | grep olad

Und alle ola Prozesse killen. Der startet sich gerne auch mal selbst mit

olad -f -s

Und blockiert dann alle.

Gruß.

der Jan

[ndorf]

Hallo,

ich würde auch gern mein WG mit dem NanoDMX usb nutzen. Habe es bisher jedoch nicht geschafft. :-(

Wenn ich nach der Anleitung mclb vorgehe, ist schon bei Punkt 2 Schluss.

Wenn ich die als user "olad -l 3" eingebe, kommt folgende Meldung:
"
^Cuser@wiregate470:/etc$ olad -l 3
Olad.cpp:286: OLA Daemon version 0.8.24
OlaDaemon.cpp:105: Using configs in /home/user/.ola
TCPSocket.cpp:173: bind to 127.0.0.1:9010 failed, Address already in use
OlaDaemon.cpp:117: Could not listen on the RPC port, you probably have another instance of olad running

"
Der Prozess lässt sich dann auch nicht mehr anhalten.

Ich habe die Beiträge hier im Forum schon mehrfach durchgelesen, komme aber nicht weiter.

Leider verstehe ich auch nicht alles.

Kann mir vielleicht einer einen Tipp geben.

Vielen Dank

Gruß

Andreas

[Chris M.]

Edit: Das mit der config weiss ich, liegt aber in der verwendeten JSON-lib.

Schau dir mal JSON.hpp/JSON.cpp von GrAF an. Die hab ich zwar nicht als Bibliothek geschrieben, aber durchaus mit dem Hintergedanken die universeller einsetzen zu können.
Hintergrund war, das mir alles fertige irgendwie nicht getaugt hatte (hatte extra einen halben Tag lang gesucht...). Ziel war minimaler Overhead, insb. wenn die Struktur der JSON schon vorher bekannt ist, da eigene Config-Datei - also genau so wie hier.