Entwicklung / OLA + knxdmxd

[JNK]

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

[JNK]

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:

  <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:

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

[makki]

@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:

- 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

[gramels]

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.

[JNK]

@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?

[makki]

leider grad sehr wenig Zeit [TM]

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

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]

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

[gramels]

Hallo zusammen,

ich denke b) ist das sinnigste.

Am ehesten möchte ich vom KNX aus

1. aufgezeichnete DMX Schleifen ablaufen lassen
2. von einem RGB wert zu einem anderen faden
2.a mit einstellbarer Geschwindigkeit

leider grad sehr wenig Zeit [TM]

Grüsse

Lothar

[JNK]

Also b) würde ich mir eventuell zutrauen. a) hab ich mir angeguckt und nicht verstanden.

Gruß,

der Jan

[makki]

Das ist so noch nicht ganz raus (und ich hatte die letzte Zeit leider andere Prios..)

Aber so oder so ähnlich.. Ich hab mich jetzt erstmal nur auf das ola als sinnvolle Basis für DMX eingeschossen.

a) Seitens olad wäre ein KNX-Plugin sicher machbar und es gab dazu auch schon Diskussionen (von dritten) auf der ML; ich könnts vermutlich nicht schreiben aber sicherlich den KNX-part kräftig unterstützen.
-> Aber 1:1 finde ich eher nicht so spannend, würde eher sequenzen abspielen wollen als einzelne Kanäle anzufahren;
-> Kommt hinzu, das die meisten DMX-Dimmer keine Dimmzeit kennen, um da "holprig" zu vermeiden muss man also in SW faden.

b) Standalone in C oder so wäre auch leicht möglich, so eine Kombination aus KNX und dem ola_recorder

c) Perl-Plugin geht zwar ja schon, so mach ichs jetzt auch, aber zumindest aktuell haben wir da ein Laufzeitproblem für präzises faden im ms-Bereich usw.; mag sich zwar hoffentlich irgendwann ändern aber..

Makki

[JNK]

Ich hab mich da jetzt mal ein bisschen eingelesen. Wie soll es denn endgültig werden?`Ein OLA-KNX-Plugin, dass auf den eibd hört und dann darauf reagiert?

Oder eine eigenständige Software, die auf den eibd hört und sich der OLA-Client-Library bedient? Basierend auf dem StreamingClient stelle ich mir das nicht so wahnsinnig kompliziert vor. Da könnte man dann auch gleich passend Farbverläufe o.ö. implementieren und per GA aufrufen.

Gruss,

der Jan

[makki]

Danke! Die Blumen gehören aber Simon Newton für OLA..
Da fehlt noch ein gescheites Init-Script und so, aber ich bin guter Dinge: das wird werden
(das "root-Problem" [I dont care!] ist im GIT schon gelöst)
Aber so ists halt mit dem Eichhörnchen, immer mühsam..

Den NanoDMX-USB betreibe ich auch via socat.. Ist ja durchaus ne gangbare Lösung..

Makki

[JNK]

Fortschritt: Es läuft, allerdings nur über den Umweg mit socat. Lokal will er mir das NanoDMX nicht annehmen. Ich habe jetzt:

Socket /dev/ttyACM0 mit den Optionen raw,b38400,cs8,icanon=1,eol=71

und

tcp-listen mit Socket 10000

eingetragen, dann mag der olad starten, ich kann das Universe patchen und mit dmx_console auch Licht an und ausmachen. Vielen Dank, makki.

Gruss,

der Jan

[JNK]

P.S. Andere haben ne bessere Marketing-Abteilung - Neidlos, ich halts lieber mit ehrlich..
Das ist nicht fertig aber das wird langsam - lieber langsam und ehrlich als halbgar..

Makki, so ist mir das ehrlich lieber als das Geblubbblubb das man sonst hört. Danke.

Installiert ist es, der olas startet auch (als User), es mag nur noch nicht so richtig mit dem NanoDMX, aber das guck ich mir nochmal an.


Gruss,

der Jan

[makki]

Hast Du OLA auf dem WG laufen? Was hast Du denn da genau installiert?

Bitte, bringt mir genug Geduld mit, wenn da sch** passiert macht das mehr Arbeit
Es liegt im Repo..

Was macht das Paket :-)

Liegt da, ist aber alles andere als perfekt..
(kein init-script, geht nicht als root [das wurde im git/ML schon ausgefochten-> 0.8.19 })

Leider ist die Hälfte der Packages nicht verfügbar...

Das war mal Wenn ich was will.. (OpenWRT war anstrengender..)

protobuf

Das war der erheblich schwierigere Teil daran - ging aber.. man muss nur wollen müssen..
Hab den Java-Crap rausgeworfen, schon gibt lenny-packerl

Und leider ist das WG meine einzige immer laufende Unix-Kiste, somit muss ich wohl noch ein bisschen warten :-)

Um den Bogen mal wieder zu entspannen, selbst für so space-ige Sachen im Fokus (und das ist im Fokus , man frage da mal bei xyz ..

Makki

P.S. Andere haben ne bessere Marketing-Abteilung - Neidlos, ich halts lieber mit ehrlich..
Das ist nicht fertig aber das wird langsam - lieber langsam und ehrlich als halbgar..