Ankündigung

**JNK** · 04.05.2012, 19:26

So, kurz als Zwischenstand: Ich habe mir den russconnectd gepackt und angefangen den umzustricken auf einen olaconnectd.

Was er schon kann:

1) config-file lesen, hier kann man beliebige Zuordnungen KNX-GA DMX-Channel anlegen, unter Berücksichtigung von DMX-Universes, dabei geht nicht nur 1:1 sondern m:n, d.h. eine KNX-GA kann auf mehere DMX-Kanäle oder mehrereKNX-GA auf einen DMX-Kanal gepatcht werden
2) die Verbindung zum eibd funktioniert super (ok, das war nicht so schwer)
3) es kompiliert mit den benötigten OLA-Bibliotheken und legt auch die Buffer für die Universes an

Morgen versuche ich dann mal den Streaming-Client da einzubauen, aber da bin ich ganz zuversichtlich. Wenn das stabil läuft, als erstes Cues und dann Fades einzubauen. Damit sollte man dann schon eine Menge machen können.

Ich fürchte nur einen Schönheitspreis gewinnt der Code erstmal nicht, weil das Daemon-Skelett eben C und OLA C++ ist. Es hat etwas gedauert den Daemon mit dem g++ zu kompilieren ohne mit errors und warnings zugeschmissen zu werden.

Gruss,

der Jan

**makki** · 06.05.2012, 01:13

Zitat von gramels Beitrag anzeigen

leider grad sehr wenig Zeit [TM]

Das zählt nicht, wir sind alle ALGII-Empfänger und haben unendlich Zeit

Zitat von JNK Beitrag anzeigen

So, kurz als Zwischenstand: Ich habe mir den russconnectd gepackt und angefangen den umzustricken auf einen olaconnectd.

Sehr gut! Mir ist machen lieber ... aber jetzt bin ich mit dem schlechten Code des russconnectd als Basis schon wieder schuld

Zurück zum Ernst, ehrlich, ich halte solche Standalone-Dinger wenns auf ms ankommt für sinnvoller als ewig hinzustricken, wenns spruchreif ist package ich das gerne.

(An dem HSruss habe ich über Jahre soviele Stunden versch**, das man es garnicht zählen kann, der russconnectd ist zwar spezifisch - aber es funktioniert sang&klangvoll seither mit 2 WE Aufwand..)
Der Vorteil einer offenen Plattform, man kann machen was man für richtig hält, egal was der Hersteller denkt (aber das finde ich richtig&gut

)

Makki

**JNK** · 06.05.2012, 17:53

@makki:

Ich habe da ein kleines Problem: Ich habs auf einer Ubuntu 12.04 Maschine entwickelt und es kompiliert nicht auf dem WG.

Ich habe fürs Config-File boost:

roperty_tree verwendet und die apt-get install libboost-dev auf dem WG kennt das noch nicht. Kann man da was dran machen? Ansonsten würde ich mal gucken, was sonst so geht, Config-file parsen ist halt ne blöde Sache und damit gehts so einfach....

Gruss,

der Jan

Edit: Und die Header vom OLA waren auch nicht da, aber das ist ja weniger das Problem.
Edit2: Vielleicht ins Beta-Forum umziehen mit der Entwicklungs-Diskussion?

**gramels** · 06.05.2012, 18:53

Zitat von JNK Beitrag anzeigen

Edit2: Vielleicht ins Beta-Forum umziehen mit der Entwicklungs-Diskussion?

Ich würde mich ja zum testen anbieten, aber hab kein Zugriff aufs Beta-Forum.

**makki** · 07.05.2012, 00:38

@JNK: Also ich habs mal "anprobiert", ich müsste das MPI aus dem Boost rauspfriemeln, um da nen Backport von boost >= 1.42 hinzubekommen.
Ausserdem (ich "mag" boost gefühlt, aber schlank ist was anderes) stehe ich aus strategischen Überlegungen heraus drauf, wenn sowas auch auf wesentlich kleineren Plattformen eine Chance hat.. Unter OpenWRT ist boost kein Versions- sondern ein Platzproblem..

Zeig doch mal, schönen Iniparser hätt ich und für .next wäre es sowas:

Code:

- modules.conf is in JSON-format using a simple, flexible syntax:
{ "global": {
"somesetting" : "somevalue",
"someothersetting" : "someothervalue",
},
{ "modules" : [
{ 
"name" : "ow1",
"handler" : "owhandler", 
"familys" : [
{ 
"type": "DS1820",
"sensors": {
"id" : "28.DA63EC010000",
"ga": "1/2/3",
..

Das geht schön schlank mit der libjson0 (json-c), also bevor ich ewig in dem boost-backport fummle schreib ich lieber ein paar Zeilen um, wenns jetzt um nichts essentielles geht

ola-dev sollte aktuell im repo liegen und dieser Teil auch stimmen; vermutlich eher Make-frickel-zeugs, da kann ich auch ein bisschen ran..

Und solange wir hier nicht seitenweise C-Code austauschen (gehört eh ins SVN) hab ich da hier keinen Schmerz mit, soll ja kein Geheimnis sein, nur keinen verwirren

@gramels: Im Beta-Forum ist seit dem (bewussten) "Wegzug" der CV ungefähr soviel los wie in Buxtehude

Makki

**JNK** · 07.05.2012, 07:41

Ih, das ist ja C :-) Aber das kann man schon passend umstricken, wenn es mit dem g++ kompiliert,

Im AUgenblick sieht das so aus;

knxdmxd,conf:

Code:

  <fixture name="Treppe">
    <channel knx="1/7/170" dmx="1.0">oben</channel>
    <channel knx="1/7/170" dmx="1.1">mitte</channel>
    <channel knx="1/7/170" dmx="1.2">unten</channel>
    <fading knx="1/6/170">1.7</fading>
  </fixture>
  <fixture name="Kueche">
    <channel knx="1/7/141" dmx="1.10">R</channel>
    <channel knx="1/7/142" dmx="1.11">G</channel>
    <channel knx="1/7/143" dmx="1.12">B</channel>
    <fading knx="1/6/141">3.0"</fading>
  </fixture>

Und der parse-Code dazu:

Code:

void load_config() {

  bpt::ptree config;

  read_xml(conf_file, config);

  BOOST_FOREACH( bpt::ptree::value_type const& e, config) {
    if( e.first == "fixture" ) {
       string name = e.second.get<std::string>("<xmlattr>.name");
       knxdmxd::Fixture f(name);
       BOOST_FOREACH( bpt::ptree::value_type const& c, e.second) {
         if (c.first == "channel") {
           f.Patch(patchMap, c.second.data(), c.second.get<std::string>("<xmlattr>.dmx"), c.second.get<std::string>("<xmlattr>.knx"));
         }
         if (c.first == "fading") {
            float t;
            string content = c.second.data();
            sscanf((char*) content.c_str(), "%f", &t);
            f.SetFadeTime((int) (t*1.e6)); // in us
         }
       }
       fixtureList[name] = f;
    }
    
  }
 
  return;
}

Ich guck mir das JSON-Zeug heute abend mal an.

Gruss,

der Jan

**JNK** · 07.05.2012, 19:42

So. Ich lade gleich eine Version ins SVN hoch. Ich würde es mal als alpha deklarieren: Es läuft bei mir auf einem Ubuntu und es kompiliert auch auf dem Wiregate.

Eine Demo-Config liefere ich gleich ins SVN mit.

Was ihr vorher braucht: ein installiertes OLA, in dem alle Devices und Universes richtig und funktionierend gepatcht sind. Man kann das später vielleicht integrieren, im Augenblick kann der - so der vorläufige Name - knxdmxd das nicht. Ich habe nur einen DMX-Adapter, daher kann ich nur ein Universe testen, es sollte aber auch so gehen.

Jede Lampe muss im knxdmxd.conf (oder beliebiger Name, dann über Option -c beim Start angeben) angelegt werden, mindestens mit Namen und einem Channel, der Channel hat zwingen einen Namen, eine GA und eine DMX-Adresse. Für die GA am besten 'x/y/z', für die DMX-Adresse 'universe.channel'. Fading ist optional, wird in Sekunden angegeben und bezieht sich auf die Zeit 0-100%. Standard ist "sofort".

Läuft der eibd lokal, wird er automatisch gefunden, sonst über den Kommandozeilen Parameter -u mit übergeben.

Bei mir läuft er als root, sonst über -p eventuell einen Speicherort angeben, wo er sein PID-File ablegen kann.

Zum kompilieren brauchts die Pakete ola, ola-dev, libjson0, libjson0-dev. Was davon schon installiert ist, weiss ich gerade nicht. Makefile habe ich auch beigelegt, das ist aber mehr gefrickelt, das kann ich nicht. Eventuell kann das jemand in Ordnung bringen.

Meine nächsten Schritte: Cues die sich über KNX aufrufen lassen, dann Sequences. Aber: Ich sag nix zu wann das was wird.

So, das wars erstmal, viel Spass.

Gruss,

der Jan

**do13** · 07.05.2012, 21:53

Zitat von JNK Beitrag anzeigen

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

Angehängte Dateien

knxdmxd.zip (79,6 KB, 12x aufgerufen)

**makki** · 08.05.2012, 01:43

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

**makki** · 08.05.2012, 18:47

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:

Code:

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

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

Code:

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

und dann

Code:

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

**JNK** · 08.05.2012, 23:34

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

**JNK** · 11.05.2012, 19:36

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:

Code:

"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** · 13.05.2012, 16:08

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:

Code:

"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

**murelli146** · 13.05.2012, 20:38

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

Code:

{ "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)

Code:

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

Code:

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

**makki** · 13.05.2012, 23:34

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

Ankündigung

Entwicklung / OLA + knxdmxd

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar