Entwicklung / OLA + knxdmxd

[JNK]

Dann wird Dich die neue Version noch mehr freuen. Die kann nämlich "link". Code-Beispiel:

"cuelists": [ // all cuelists
  { "name" : "Treppe Disco",
    "trigger" : { 
      "go" : { "knx" : "1/0/172", "value" : 1 }, 
      "halt" : { "knx" : "1/0/172", "value" : 0 }
    },
    "cues" : [ // cues are like scenes, just without individual triggers
      { "name" : "allesaus",
        "channels" : [ 
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 0 }
        ],
        "waittime" : 3, // only relevant for loops
        "fading" : { "time" : 3 }        
      },      
      { "name" : "obenan",
        "channels" : [      
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 0 }
        ],
        "waittime" : 3,
        "fading" : { "time" : 3 }        
      },
      { "name" : "beidean",
        "channels" : [
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 0 }  
        ],
        "waittime" : 3, // waittime start after calling previous cue !
        "fading" : { "time" : 3 }
      },
      { "name" : "untenan",
        "channels" : [
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 0 }
        ],
        "waittime" : 3,
        "fading" : { "time" : 3 }
      },
      { "link" : "allesaus"
      }
      
    ]
  }  
]

"link" kann an der Stelle eines Cues in der Cuelist stehen. Einziger Parameter ist der Name eines Cues. Es kann mehrere Links geben, sie können vor oder zurück verweisen."link" wirkt für die Waittime genau so als ob der Cue an der entsprechenden Stelle stehen würde.

Geändert hat sich der Trigger: Ab sofort geht ausschliesslich das neue Format. Scenes haben logischerweise nur einen "go"-Trigger, was soll man in einem statischen Cue auch anhalten. In Cuelists gibt es ausserdem noch "halt", dann wird die Cuelist an der Stelle an der sie gerade steht angehalten. Ein neues "go" setzt dann da fort, wo vorher angehalten wurde.

Gruss,

der Jan

[murelli146]

Es läuft seit gestern ohne Probleme bei mir.

Habe gerade versucht den Fehler von gestern zu erzwingen ohne Erfolg.

Also folgende Prozesse liefen im Fehlerfall:

olad -c /var/etc/ -f
olad (also olad aus versehen 2x gestartet)
/usr/bin/knxdmxd -c /etc/knxdmxd.conf -u local:/tmp/eib -p /var/run/knxdmxd.pid

die Programme waren ohne Fehler am laufen > dann löste ich eine scene aus und knxdmxd brachte den Fehler Speicherzugriffsverletzung und wurde beendet.
Das passierte mehrmals. Als ich den 2. olad beendet hatte funzte es.

Aber wie gesagt es läuft und ich bekomme die Konstellation nicht mehr hin.

Ich spiel mich mal mit der knxdmxd.conf und erfreu mich an den szenen und dem fading.

Also echt geil das Teil

[JNK]

Wie stoppe ich olad wieder bzw. habe ich das Problem dass ich es mehrfach starte (ola_plugin_info, ola_dev_info, ola-patch, olad)
und es mir knxdmxd zum absturtz bringt wenn ich auf den dmx senden beginne.

Der knxdmxd stürzt genau wann ab? Und was jammert er da? Das habe ich noch nie hingekriegt, eigentlich recovert der einen fehlenden OLA-Daemon.

Gruss,

der Jan

[makki]

Das mit olad & root ist im GIT schon "behoben", ich hab mir eine "--disable-root-check" compile-time Option erbettelt (bzw. einen patch geschickt, das man nicht meint das würde alles so ganz automatisch aus dem Universum fallen..)

Init-script fürn olad gibt dann mitm nächsten Release auch, bisher hab ich das aber nur aufm Desktop und IPE verwendet..
Und monitoring mit Standard-Bormitteln (monit) wirds auch geben, ist halt alles noch WiP..

localhost geht nicht weil das keine Namensauflösung macht sondern nur die IP nimmt, das hatte ich auf der ola-Liste auch schon "angemerkt", ist glaub auch schon behoben aber ja kein Beinbruch da 127.0.0.1 reinzuschreiben..

Edit: am Ende nochmal: ich habe das gerade abgesplittet von https://knx-user-forum.de/forum/supp...wiregate/18707, ich hasse sowas ja aber es macht IMHO der Übersicht halber Sinn..


Makki

[murelli146]

So habs jetzt am laufen

Danke Jan und Makki!!

Das sieht ja schon echt supper aus, da gehen ja Welten (Universen )auf.

Ich habe noch Fragen die vieleicht noch zu früh sind oder besser gesagt wo mein Wissen aufhöhrt (Ich will euch ja nicht behindern, da ihr ja voll mit entwickeln beschäftigt seit).

Ein Startscript das ola und knxdmx startet:

knxdmxd startet beim booten
bei olad ist das Problem dass es nicht als root ausgeführt werden darf.?

derzeit starte ich olad als user so:
olad -c /var/etc/ -f

damit ich die configs in dem ordner habe und sie über ftp bearbeiten kann.
(ja .. ok .. ich freunde mich eh immer mehr mit der Konsole an, macht auch immer mehr spaß)

gepatcht habe ich es dann übers OlaWebIF http://wiregatexxx:9090


Wie stoppe ich olad wieder bzw. habe ich das Problem dass ich es mehrfach starte (ola_plugin_info, ola_dev_info, ola-patch, olad)
und es mir knxdmxd zum absturtz bringt wenn ich auf den dmx senden beginne.

Wie kann ich die knxdmxd.config nach dem Bearbeiten einfach reloaden ?
Können knxdmxd und olad überwacht werden und ggf. neu gestartet werden?

Ist es möglich den Statuswert an die knx GA zurückzugegeben?(Damit die Slider bzw. der Colorchooser in der Cometvisu beim aufruf einer Szene mitgehen?

Sorry für die vielen fragen. Das ist jetzt auch nicht so wichtig.
Ich habe jetzt ja mehr als genug zum testen.

Nochmal danke an euch für dieses tolle Projekt.

Gernot

[JNK]

Ich habe:

/dev/ttyACM0, optionen : raw,b38400,cs8,icanon=1,eol=71
und
tcp-listen, 10001

eingetragen.

und in der stageprofi.conf

device=127.0.0.1

mit localhost hab ich es auch nicht ans Laufen bekommen.

Dann natürlich mit ola_device_info und ola_patch ein Universum erzeugen.

Gruss,

der Jan

[murelli146]

Hallo Makki,

welche Einstellunge hast du bei socat und der ola-stageprofi.conf gemacht.

Ich bekomme es einfach nicht zum laufen.

Meine Einstellung:

Socat:
Socket 1 /dev/dmx
Socket 2 /tcp-connect localhost:10000

ola-stageprofi.conf :
device = localhost:10000


Bekomme immer die Meldung von olad:

NetworkUtils.cpp:69: Could not convert address localhost:10000

Gruß Gernot

[makki]

Klasse, ich schiebe das bis auf weiteres einfach kommentarlos ins repository durch!

@Gernot: olad muss laufen - statt dem socat+Plugin!
Den socat (fürs Plugin) abzudrehen reicht zwar, aber ich musste hier trotzdem mit dem socat "tricksen", dem olad den NanoDMX als Stageprofi-LAN via 10000/tcp "verkaufen", ich hielt das zwar für ein Einzelschicksal, aber..
Edit: die NanoDMX hängen hier schon immer an einem IPE via socat, deswegen ist mir das vorher nie aufgefallen..

Makki

[murelli146]

wow wow wow,

ich will mitkommen.

Ich versuche es mit einem NanoDMX ans laufen zu bekommen aber ich hänge mal wieder.

1. habe ich knxdmxd übers WG installiert > läuft
2. die /etc/knxdmx.conf angepasst damit sie die Kanäle des WG plugin ersetzt

{ "fixtures": [
 
  { "name" : "Gang",
    "channels" : [
      { "name": "R", "knx" : "11/0/0", "dmx" : "0.1"  }, 
      { "name": "G", "knx" : "11/0/1", "dmx" : "0.2"  }, 
      { "name": "B", "knx" : "11/0/2", "dmx" : "0.3"  },
   { "name": "W", "knx" : "11/0/3", "dmx" : "0.4"  }
    ],
    "fading" : {"knx" : "11/6/0", "time": "3.0" }
  }
  ],
"scenes": [
  { "name" : "Gang_Full_On",
    "trigger" : { "knx" : "11/7/0", "call" : 1 },
    "channels" : [
      {  "fixture" : "Gang", "channel" : "R", "value" : 255 },
      {  "fixture" : "Gang", "channel" : "G","value" : 255 },
   {  "fixture" : "Gang", "channel" : "B","value" : 255 },
      {  "fixture" : "Gang", "channel" : "W","value" : 255 }
    ],
  },
  {
    "name" : "Gang_Blackout",
    "trigger" : { "knx" : "11/7/0", "call" : 0 },
    "channels" : [
      {  "fixture" : "Gang", "channel" : "R", "value" : 0   },
      {  "fixture" : "Gang", "channel" : "G", "value" : 0  },
   {  "fixture" : "Gang", "channel" : "B", "value" : 0 },
      {  "fixture" : "Gang", "channel" : "W", "value" : 0  }
    ]
  } ]
}

3. In den Socketverbindungen habe ich den NanoDMX deaktiviert
4. Olad gestartet und übers WebIF eine UniverseID 1 angelegt (Open Dmx at /dev/dmx)

ola_dev_info 
Device 5: OpenDmx USB Device
port 0, OUT Open Dmx at /dev/dmx, patched to universe 1

Das Device habe ich mit

nano ~/.ola/ola-opendmx.conf

angepasst

Ich muss zugeben ich habe wild experimentiert, doch ich konnte nur die LED Leuchte übers ola WebIF steuern.

Es wäre hilfreich für den Einstieg ein kurzes step by step damit die dienste richtig laufen.

Ich weiß nicht ob olad immer laufen muss oder ist das nur zum patchen und dann läuft nur knxdmxd?
Ach ja das WG plugin habe ich nicht deaktiviert müsste reichen wenn ich die Socat deaktiviere oder?

Ich finds so spannend

Gruß Gernot

[JNK]

Wieder mal ein Update, neu sind cuelists.

Cuelists sind so etwas wie aneinandergereihte Szenen, ohne eignen Trigger. Da heisst die Cuelist hat eine "Go"-Trigger, wenn der kommt, wird einen Cue weitergesprungen. Das erfolgt immer, egal was für Zeiten für was auch immer vorgegeben sind, ein manuelles "Go" ruft immer den nächsten Cue auf. "Halt" ist im Augenblick noch nicht implementiert, damit soll die Cuelist dann mal angehalten werden können. Ausserdem kommen noch Funktionen für direktes Anspringen eines Cues und Zurücksetzen der Liste hinzu.

Die Cues werden wie Szenen definiert, allerdings gibt es zusätzlich den Parameter "waittime". Ist er angegeben (und positiv), wird der Cue der die Waittime hat diese Zeit nach dem vorhergehenden Cue aufgerufen. D.h. Cue 2 hat eine waittime von 10s, dann wird Cue 2 automatisch 10 s nach dem Aufruf von Cue 1 gestartet. Die Namen der Cues sind egal, nur fürs Logfile eventuell nett. Eine waittime in Cue 1 hat im Augenblick keine Funktion.

Am Ende der Cuelist wird angehalten, ein "Go" setzt die Cueliste zurück, ein weiteres Go ruft dann Cue 1 auf. Das wird dann demnächst durch weitere Optionen einstellbar sein, ob am Ende angehalten werden soll, ob automatisch zurückgesetzt werden soll oder ob es automatisch mit Cue 1 weitergehen soll.

Beispiel:

"cuelists": [ // all cuelists
  { "name" : "Treppe Disco",
    "trigger" : { "knx" : "1/0/172", "go" : 1, "halt" : 0 },
    "cues" : [ // cues are like scenes, just without individual triggers
      { "name" : "Cue_1",
        "channels" : [
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 128 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 128 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 128 }
        ],
        
      },
      { "name" : "Cue_2",
        "channels" : [
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 255 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 255 }  
        ],
        "waittime" : 10 // waittime starts after calling previous cue !
      },
      { "name" : "Cue_3",
        "channels" : [
          {  "fixture" : "Treppe", "channel" : "oben", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "mitte", "value" : 0 },
          {  "fixture" : "Treppe", "channel" : "unten", "value" : 0 }
        ],
        "waittime" : 10
      }
    ]
  }  
]

Wenn die Cuelists mit allen Optionen (d.h. loops, delays und alle Trigger), fertig sind, dann gibt es als nächstes Dimm-Profile und dann Fade-Profile.

Gruss,

der Jan

[JNK]

Ich habe Euch nicht vergessen :-)

Ich habe gerade eine neue Version ins SVN geschoben. Ein paar interne Änderungen, das ist nicht so interessant.

Aber es gibt jetzt "Scenes".

Definiert z.B. wie folgt:

"scenes": [
  { "name" : "Treppe_Full_On",
    "trigger" : { "knx" : "1/0/170", "call" : 1  },
    "channels" : [
      {  "fixture" : "Treppe", "channel" : "oben", "value" : 255 },
      {  "fixture" : "Treppe", "channel" : "mitte", "value" : 255 },
      {  "fixture" : "Treppe", "channel" : "unten", "value" : 255 }
    ],
  },
  { "name" : "Treppe_Blackout",
    "trigger" : {  "knx" : "1/0/170", "call" : 0  },
    "channels" : [
      {  "fixture" : "Treppe", "channel" : "oben",  "value" : 0  },
      {  "fixture" : "Treppe", "channel" : "mitte",  "value" : 0  },
      {  "fixture" : "Treppe", "channel" : "unten", "value" : 0  }
    ]
  } 
]

Zur Erklärung: Das ist eine Treppe, die in den Stufen mit einfarbigen LED-Stripes beleuchtet wird. Wegen der Leistung sind drei Kanäle erforderlich.

• "name" wird im Augenblick nicht zwingend benötigt, es wird ein Name _s_<nummer> vergeben, wenn man selbst keinen angibt (ähnlich wie bei den Lampen, die heissen ja dann _f_<nummer>
• "trigger" ist erforderlich, weil Szenen die man nicht aufrufen kann sind blöd, dabei ist die GA vorgeschrieben, "call" ist optional und gibt den Wert an, den die GA haben muss. Gibt man nichts an, ist der Wert egal.
• "channel" braucht man mindestens einen, sonst ist die Szene ja leer. Zwingend ist der Name der Lampe des Channels (jeweils aus der Definiton der Lampe) und ein Wert, auf den dieser Channel gesetzt werden soll

Fading geht bei den Szenen noch nicht, ich hoffe da komme ich noch dieses Wochenende zu.


Generell: Es gilt LTP, also wer zuletzt kommt gewinnt. Wenn die Lampe gerade irgendwie durch die Gegend fadet und eine Szene wird aufgerufen, ist die Szene da und das Faden hat sich erledigt.


Gruss,


der Jan

[JNK]

Vielen Dank Euch beiden. Meine C++-Kenntnisse basieren überwiegend auf ROOT, und das hat einen Interpreter, da braucht man keine Makefiles.

Mit der Config bin ich noch nicht ganz glücklich: da wird sich vermutlich nochmal was ändern (also JSON bleibt, es geht mehr um den Inhalt).

Das Konzept für Scenes, Cues und Cuelists wird ähnlich dem der Wholehog II sein, das finde ich persönlich ganz übersichtlich.

Gruß,

der Jan

[makki]

knxdmxd

Ich würde das Debian-packaging und autoconf/make von Dirk dann mal commiten, im Repo liegts schon (heisst fürs Wiregate: knxdmxd installieren, fertig)

Um das ganze am Entwicklungsrechner wieder ans rennen zu bekommen:

#aclocal
automake --add-missing
autoreconf 
./configure
make
...

Um das packerl unter Ubuntu zu bauen reicht übrigens:
Temporär in /etc/apt/sources.list:

deb-src http://repo.wiregate.de/wiregate wiregate-0.1 main

und dann

sudo apt-get update
apt-get source knxdmxd
apt-get build-dep knxdmxd
cd knxdmxd*
dpkg-buildpackage
sudo dpkg -i ../knxdmxd*.deb

Makki

P.S.: Ich glaub ich schieb das glaub ich dann beizeiten mal in nen neuen Thread

[makki]

Klasse, das wird doch

Mit auto(conf|make) [ich weiss da zwar auch nicht wirklich,was ich tue aber solangs auf meinen Lieblings-Plattformen funktioniert seis drum ]
+ Debian-package werd mich mit einklinken! Das sollte gebongt sein, soll heissen @JNK: halt dich damit nicht auf..
Ich schätze das flutscht die nächsten 48h ins SVN..

Makki

[do13]

Makefile habe ich auch beigelegt, das ist aber mehr gefrickelt, das kann ich nicht. Eventuell kann das jemand in Ordnung bringen.

Ich bin zwar auch nicht der automake König, aber hier mal ein Anfang. Man könnte noch ein paar checks für headerfiles einbauen, aber das habe ich auf die Schnelle nicht mehr geschafft.
Sollte zumindest so unter Ubuntu 12.04 compilieren.
Kopiere einfach deine knxdmx.c nach src/knxdmx.cpp dann kannst du configure aufrufen.

Dirk