Trigger über IP / Browserbasiertes Interface

  • Moin moin zusammen,


    erstmal vielen Dank für die lebhafte Diskussion! Ich denke auch, dass hier ganz neue Möglichkeiten "lauern". Von der Umsetzung her würde ich alles - auch Cue-Lists - was jenseits der basalsten Befehle ist (zunächst) in die Web-Programmierung (z.B. PHP / JS) auslagern und nur als allerelementarste implementieren.


    Als Server-Plattform für die Schnittstelle würde sich dann z.B. XAMPP anbieten.


    martin3182: Du meintest, PHP wäre hier nicht sinnvoll, mit .NET würde mann sehr viel schneller zum Ergebnis kommen. Aber wäre nicht ein - wie auch immer gearteter Aufruf (ob er jetzt "192.168.1.123/dmxc.php" oder z.B. "192.168.1.123/dmxc.asp" heißt) völlig plattformunabhängig?


    Ich denke da unter PHP an eine Verwendung von cURL ("libcurl": Folgende Protokolle werden zur Zeit unterstützt: HTTP, HTTPS, FTP, gopher, telnet, DICT, FILE und LDAP. Libcurl unterstützt außerdem SSL-Zertifikate, HTTP POST, HTTP PUT, das Hochladen von Dateien mittels FTP (zu diesem Zweck kann auch die FTP-Erweiterung benutzt werden), Formular-basierte Datei-Uploads, Proxies, Cookies und Benutzer/Passwort-Authentifikation.)




    Diese Funktionen wurden in PHP 4.0.2 hinzugefügt.

  • Hy,


    Was Martin schreibt ist zu 100% korrekt. Wir müssen 2 Dinge unterscheiden, den Client und die Serverseite.


    Der Server wäre in dem Fall DMXControl und hier muss das Plugin in C# geschrieben werden (sonst läuft es nicht). Das Reagiert dann auf die HTTP Requests.


    Der Client (welcher dann diese REST Schnittstelle verwendet) kann in einer beliebigen Sprache (auch PHP) geschrieben werden. Kann aber auch Javascript, Java, C, whatever sein.


    Hier ein paar weiterführende Links:
    http://de.wikipedia.org/wiki/Webservice
    http://de.wikipedia.org/wiki/Representational_State_Transfer


    Gruß Arne

  • Das ist entlich mal ein Ansatz in die richtige richtung !! ...wenn auch fast etwas zu schnell/weit !! da komme ich kaum mit !
    Ich melde mich dazu noch ...
    Gruß Ralf


    PS.: Warum muß eine solche "Webanwendung" ein Teil von DMXC sein ?
    Könnte man das nicht in einer Form realisieren, die einem "Nur" die Ellementaren Grundfunktionen bereitstellt ?
    Das was man auf einem Hardware Lichtmischer sieht ! nämlich Buttons und Fader !!


    Quasy eine DMX Ausgabe Oberfläche mit Basis Funktionen als DMX Fernsteuerung.


    Wobei ein Butten mit einem bestimmten DMX Kanal und einem vordefinierten Wert verknüpft werden kann.
    Ein Fader, der hoch/Runtergezogen werden kann und den entsprechenden DMX Wert ausgibt.

  • Hallo,

    Das was man auf einem Hardware Lichtmischer sieht ! nämlich Buttons und Fader !!


    Quasy eine DMX Ausgabe Oberfläche mit Basis Funktionen als DMX Fernsteuerung.


    Wobei ein Butten mit einem bestimmten DMX Kanal und einem vordefinierten Wert verknüpft werden kann.
    Ein Fader, der hoch/Runtergezogen werden kann und den entsprechenden DMX Wert ausgibt.


    dann, ganz ehrlich, verstehe ich dich nicht. Denn DMXControl 3 kann mit dem SoftDesk GENAU DAS auch schon (fast) von Haus aus. Wieso versuchst du zwanghaft DMXControl zu nutzen, aber dann doch nicht und nur so wenig wie möglich, aber dann doch wieder von allem von DMXControl 3 profitieren zu wollen. Bitte ließ dich doch erst einmal in die Funktionen vollständig ein (dazu haben wir ein entsprechendes Tutorial mit 24 Kapiteln) bevor du hier versuchst, das Rad noch einmal neu zu erfinden, was in DMXControl 3 schon integriert ist.


    Selbst DMXControl 2 kann das schon in abgewandelter Form. Dort ist es eben in der DDF-Ansicht. Aber auch dort kann man Buttons mit DMX-Werten belegen, die beim Drücken ausgegeben werden und Fader, deren Werte ebenfalls übergeben werden.


    Beide Programme, DMXControl 2 und 3 können darüber hinaus auch noch Farbwähler und Positionsboxen für die X- und Y-Koordinaten in das DDF-Fenster / den Softdesk einbinden und DMXControl 3 sogar mehrere davon. Außerdem können auch noch Drehregler eingebunden werden. Du hast also schon eigentlich fast alles für ein solches virtuelles Pult.
    Viele Grüße
    JP

  • Was wir _nicht_ brauchen, ist ein "richtiges" Web-Interface direkt von DMXC - so wie es z.B. die Frizbox oder eine IP-Cam liefern (D.h. ich wähle mich bei DMXC ein und habe dort eine Weboberfläche). Grund: zu unflexibel - zu großer Aufwand.


    Statt dessen: Wir haben - wenn wir das so realisieren möchten - eigentlich zwei (!) Server:


    1. Der eine sitzt im Kernel von DXMC und macht nichts anderes als die basalen Funktionen "getDMXValue(Channel)" und "setDMXValue(Channel, Value)" zu bearbeiten - und zwar über Befehle via seine IP-Adresse also z.B.
    - "http://192.168.1.1/getDMXValue.aps?ch=45&" gibt den aktuellen Wert des DMX-Kanals 45 zurück, z.B. "100"


    2. Der Webserver könnte z.B. ein lokal aufgesetzter XAMPP (Apache, PHP, MySQL) sein, der unter der Adresse "http://192.168.1.2" erreichbar ist. Auf dem kann jeder entwickeln, was er möchte - z.B. ein System aus PHP und JavaScript. Und auf diesem System werden dann auch die Buttons und Fader und Szenen (über die Datenbank) etc. programmiert. Der Vorteil ist, dass hier sehr viele Leute etwas auf die Beine stellen können, ohne im Kernel von DMXC herumzupfuschen.


    Herausforderungen könnten aus meiner Sicht a) die Performanz* und b) die nötigen Push-Funktionen Webserver -> Client-GUI (z.B. bei Echtzeit-Anzeige von Kanal-Werten) sein. Hier müsste aber etwas im Sinne von jQuery möglich sein.


    Ganz spannend wird es, wenn die Community hier anfängt, die XML-basierten (und damit vergleichsweise einfach in ein Websystem einzubindende) Gerätedefinitionen (DDF) in Javascript-Elemente umzusetzen.


    LG, Martin (q4e)

  • Für DMXC 2 gibt es über die "PDA-Fernsteuerung" eine geeignete TCP-Schnittstelle (allerdings kein HTTP). Für die haben Leute auch schon eine PHP-Klasse erstellt, mit der sich z.B. DMX-Werte setzen lassen.


    Bei DMXC 3 halte ich es für wenig sinnvoll, sich nur mit rohen DMX-Werten zu beschäftigen - das passt nicht recht zum Konzept der Geräteeigenschaften, mit denen sonst gearbeitet wird. Generell würde es Sinn machen, möglichst viele der schon bestehenden Funktionen auch nutzbar zu machen. Wieso sollte man eine Szenendatenbank auf z.B. MySQL bauen, wenn DMXC das selbst schon kann? Auch dürfte es deutlich performanter sein, wenn DMXC die Szenen überblendet oder Effekte ausgibt, anstatt das über sehr viele HTTP-Requests zu machen...


    Stefan

  • Hi!


    Ich denke auch, dass man hier wenn dann auch gleich ordentlich arbeiten sollte. Der einfachste Aufruf ist sicher set/get eines bestimmten DMX-Wertes. Und das wird auch der eine oder andere brauchen können. Aber wie Stefan schon sagt ist es wesentlich interessanter DMXC an sich zu "bedienen". So wie in der 2er die Befehle aufgebaut sind. Cuelist -> xy -> start/stop/next/.... etc. Oder eben auch Gerät xy -> Set Pan -> 80°. Alle Geräte in Gruppe xy -> Farbe -> rot (Meinetwegen #ff0000 oder eine 16-Bit-Version davon ;)).
    Das ist es was DMXC an sich "verstehen" muss. Wie dann die Oberfläche aufgebaut wird, das sollte jedem selbst überlassen bleiben. Ob es ein XAMPP auf dem gleichen Rechner ist oder ein Webserver eines normalen Hosters die Befehle "produziert" ist letztlich egal. Oder auch nur der Aufruf den ein Internet-der-Dinge-Lichtschalter sendet. Das bringt nämlich diesen Aspekt in ein richtig interessantes Licht.
    Stefan/Frank: Dieser kleine Chip vom Treffen dürfte dann nämlich enorm interessant werden für alle die diese "Ich will dass die Putzfrau mit einem normalen Lichtschalter das Putzlicht einschalten kann"-Fälle.
    Für alle die das noch nicht kennen: Es gibt diese wunderbaren Mikro-Systeme mit WLAN onbaord in Briefmarkengröße für fast kein Geld. Korrigiert mich, aber ich glaube 4€ standen im Raum. Die gehen locker in Unterputzdosen mit allem was man braucht.


    Hoc

    Mein Equipment:
    1x Hirn | 2x Augen (leicht defekt) |2x Ohren | 1x Mund |32x Zahn (zum Teil V1.5) | 1x Handundfuß-Interface

    *SCNR*

  • "Ich denke auch, dass man hier wenn dann auch gleich ordentlich arbeiten sollte. "


    Das wäre natürlich das allerbeste! Genau an diese Mikro-Systeme am Netz habe ich gedacht. Dann kann der Schaupieler auf der Bühne die Stehlampe anschalten und die Bühne wird zeitgleich von oben richtig ausgeleuchtet. Oder in einem Dungeon marschiert einer durch eine Lichtschranke und ein DMX-Programm wird gestartet. oder ein Performance-Künstler mit Bewegungssensoren steuert Licht via einen Arduino. Oder... Oder... Oder...


    Nachtrag: Hier noch ein Link ... http://arduino-hannover.de/201…ifi-kochbuch-mit-esp8266/

  • Ansonsten könnte ich euch auch dieses WLAN Modul empfehlen:
    http://www.seeedstudio.com/dep…2-WiFi-Module-p-2122.html


    Kostet hier in DE ~15€, hat einen Cortex M3 drauf mit deutlich mehr Rechenpower als so ein Arduino.


    @Topic:
    Meiner Meinung nach wäre es am sinnvollsten, wenn ihr Cuelists, einzelne Geräte und vielleicht noch Executoren zur Verfügung stellt, viel mehr braucht ihr eigentlich nicht.
    Einen einzelnen Kanal setzen, widerspricht dem Konzept von DMXC3.


    @anderer Martin:

    martin3182: Du meintest, PHP wäre hier nicht sinnvoll, mit .NET würde mann sehr viel schneller zum Ergebnis kommen. Aber wäre nicht ein - wie auch immer gearteter Aufruf (ob er jetzt "192.168.1.123/dmxc.php" oder z.B. "192.168.1.123/dmxc.asp" heißt) völlig plattformunabhängig?


    Ja klar, aber stell dir vor, du bist das dmxc.php/dmxc.asp Skript, dieses muss ja um die angedachte Funktion zu realisieren mit dem DMXC Kernel kommunizieren. Deshalb wäre es hier sinnvoll, das ganze als Kernelplugin zu schreiben anstatt in PHP, denn aus PHP heraus kannst du genau das eben nicht.


    Die Schicht, die dann diese API nutzt, kann meinethalben in PHP, JS mit jquery, node.js oder sonstwas gebaut werden.
    Mir ging es rein um das Backend, was eben diese Funktionalität bereitstellen muss, daher kamm die Aussage "sinnlos" von mir.


    Ansonsten ist es mit Curl sicherlich richtig, aber du kannst afaik auch direkt Requests in PHP senden (habe schon länger nichts mehr mit PHP gemacht).


    LG

  • Hallo zusammen,


    Weitere idee (mit etwas zukunftsausblick da das alles momentan in der preview ist):
    Was haltet ihr von einer einfachen Windows 10 universal app? Wenn diese sinnvoll programmiert ist könnte man sie auf pc, tablet, handy und raspberry pi nutzen.
    Ich will jetzt mal garnicht weiter darauf eingehen. Aber damit würde man mehrere fliegen mit einer klappe schlagen und könnte sich eventuell direkt als client an dem Server anmelden. (ohne mich mit allem länger beschäftigt zu haben... Gibt es eine art guideline zum verbinden mit dem Server? Evtl würd ich mich mal damit beschäftigen ;)

  • Moin moin,


    nachdem ich jetzt längere Zeit mit anderen Aspekten des Projekts beschäftigt war, bin ich jetzt wieder beim Thema DMX angekommen. Die von mir ursprünglich propagierte Idee, einen Server zu programmieren, der POST oder GET Variablen über HTTP verarbeitet hat - nach meinen jetzigen Kenntnisstand - nur eine sinnvolle Einsatzmöglichkeit in vergleichsweise groben und zeitunkritischen Steuerprozessen.


    Um eine vernünftige browserbasierte Steuerung zu realisieren braucht es ein System, das nicht mit einem riesigen Overhead ständig neue Verbindungen aufbaut und schließt. Zudem sollte es gegenüber Verbindungsabbrüchen resistent sein und auch bei langsamen Verbindungen ohne viel Traffic laufen. Da ich exakt die selben Voraussetzungen an anderer Stelle gebraucht habe, bin ich auf MQTT gestoßen.


    Eine Einführung gibt es z.B. bei Heise: http://www.heise.de/developer/…et-der-Dinge-2168152.html


    Und anders als zu Beginn würde ich heute die Schnittstelle in der Architektur höher ansetzen - parallel zum MIDI-Input. Dadurch verschenkt man nicht alle Vorteile die die DMXC3-GUI bietet und kann über einen kurzen Befehl auch komplexe Sequenzen fahren.


    Was meint ihr, würde so etwas Sinn machen?


    P.S.: Als Spielerei bin ich gerade dabei, einen MQTT-fähigen MIDI-Controller zu bauen. Wenn die Latenzen nicht in's Unendliche gehen, wäre das eine zugegebenermaßen unglaublich umständliche, aber umsetzbare und plattformunabhängige PnP-Lösung:


    BROWSERBASIERTE GUI (HTTP + jquery)
    |
    Ethernet
    |
    V
    SERVER (PHP + MySQL [Logging] -> MQTT-Client [publish] -> MQTT [Broker])
    |
    Ethernet
    |
    V
    CONTROLLER (M5100-Shield -> Arduino [MQTT [subscribe] ] -> 8u2 [USB-MIDI])


    LG, Martin (q4e)

  • Naja, Ich bin auf jedenfall sehr interessiert !!


    Hier mal ein Projekt von mir !!
    http://tamulimoba.de/M_C_S_Robo_Schach/mcs_SensorTouch.html
    Dies läuft bisher rein auf html also noch keine Spielfeld sensorik und wie du schön treffend beschreibst:
    ...vergleichsweise groben und zeitunkritischen Steuerprozessen.
    Bitte im Firefox , da Funktioniert sie "sauber"
    MCS_Roboschach:
    Es sind noch viele Fehler drin ! Namen und so... Wenn du auf Tasten mit "MIDIfiles" Drückst ? wirst du eine Fehlermeldung erhalten: Datei nicht gefunden...
    Dann gehe oben im Browser einfach einen Step zurück !! oder wähle "Beleuchtung" oder Spielfeld...
    Ich hoffe du findest dich rasch zurecht...
    das Script hat vom Fingertip bis zur ausführung der Aktion eine Latens von bis zu eine halbe secunde !
    Das Spielfeld ist eine "Sensormatrix 8 x 8 Felder ! zum auswählen der Spielfigur die gesetzt werden soll !...


    Es währe supercool, wenn man OSC so Programmieren könnte, das man in einer Bildbearbeiung selbst erstellte Grafiken
    einfügen und mir MIDI-Events verknüpfen könnte !
    Das man sich ein OSC Tranzparentes Sliderfeld nach belieben hinscalieren kann und ein Bild darunterlegen kann !?
    Sowas würde recht ununterbrochen laufen und nahezu latensfrei sein !


    Wie weit dies mit der Benutzeroberfläche von DMXC3 realisierbar ist ? !!
    Das ist noch eine herausvorderung die ich umbedingt mal voll ausreizen will !


    Gruß Ralf

  • Hy,


    Letztendlich ist das was ihr hier aber bauen wollt eine "Browserbasierte Lichtsteuerung". Ergo es hat wenig damit zu tun eine Oberfläche für DMXC zu haben, es geht um ein ganz neues Programm.


    Die Bibliotheken für alle Interfaces sind frei zugänglich, von daher lasst euch nicht aufhalten.


    Gruß


    Arne

  • Ich denke das hier mehrere verschiedene Ansatzversionen angestrebt werden.
    Ich beneide diejenigen extrem, die wirklich Programmieren können !
    ------------------------------------------
    Ich würde das für mich eher so bezeichnen das man eine Webbasierende Benutzeroberfläche hat, die unanhängig auf jede DMX Lichtsteuerung (Software und Hartware) auch Parallel zugreifen kan, b.z.w. diese Fernsteuern kann !
    OSC ist da ein anfang ! allerdings auf MIDI beschränkt. Hier sind auch Fader erstellbar die Intensität steuern ! (Midi).
    Gäbe es ein "Plugin" für Browser das auch DMX Werte (und MIDI Ivents) ausgeben kann ?
    Hätte man ein Werkzeug mit dem man unterschiedliche DMX Steuerungen Fernsteuern kann.


    Mit einer "einfachen html" Benutzeroberfläche kann ich ein "Lied" Schreiben in dem beliebig fiele Noten=Steuerbefehle drin enthalten sind !
    Da meine Martin Blades Midikanäle Verwalten können, sind den Cues, secs. BGcues. Funktionen... je verschiedene MIDI Kanäle zugeortnet !
    Mit einer "MIDI-Linie"=16 Kanäle a 128 Befehle kann ich so auf einer unabhängigen Benutzeroberfläche locker 3 Blades Fernsteuern ! Natürlich ist wegen der Latens (bis zu 1/2sekunde) ein Mastermidi Keyboart zum real Einpielen von Effekten unverzichtbar.


    Vieleicht würde so mit einem DMX Plugin eine sehr einfaches DMX Browsersteuerung entstehen !
    So etwas wird nie eine richtige DMX Software ersetzen können, aber für einschalten , aufdimmen
    und eben Fernsteuern reicht es !


    Gruß Ralf


    PS: Ich werde mich erstmal aus diesem Dialog raushalten, da ich glaube, meine Vorstellungen von einer Web basierenden... zur genüge
    Kund getan zu haben !
    Alles weitere überlasse ich dehnen, die das wirklich auch realiesieren können. :thumbup:

  • Newly created posts will remain inaccessible for others until approved by a moderator.

    The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.