Günstige (und bessere) alternative zur DMX Extension

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • pmayer
    kommentierte 's Antwort
    @challo: https://www.loxforum.com/forum/faqs-...100#post124100

    @hismastersvoice: Für den geneigten Selbstbauer bin ich völlig bei dir. Da würde eventuell sogar eine Platine reichen auf die man die fertigen Module (Arduino Nano, Wiz550io, RS485) aufsteckt und sich dann das Gehäuse selbst passend feilt.
    Meine Idee war ja die Platine nachher zum Verkauf fertig bestückt anzubieten und da würde ich ungerne jedes mal an dem Gehäuse rumfeilen müssen. Natürlich ist das Gehäuse nur optional, dann sollte es aber genau passend sein.
    Problem ist eben, dass ich bearbeitete Gehäuse oder speziell gefertigte Gehäuse erst ab einer gewissen Stückzahl bestellen kann. Wir haben das bei einer kompletten Eigenentwicklung auf der Arbeit durch...

    Das 2-TE Gehäuse (Bilder oben) kann ich nehmen wenn ich beide Seiten bestücke. Dann ist auf einer Seite sehr viel Platine zu sehen. Ich wollte das 3TE nehmen, weil ich damit eine Seite mit einem Blinddeckel verschließen kann und die Platine dann nur minimal zu sehen ist.

    Ich bin aber für jede Anregung und Diskussion offen.
    Zuletzt geändert von pmayer; 28.10.2017, 13:56.

  • pmayer
    kommentierte 's Antwort
    Ich finde die Diskussion gerade sehr wichtig!!

    Mein Ansatz war, dass ich keine "neue" Infrastruktur (DMX, RS485) aufbauen muss, wenn ich Netzwerk habe. In meiner Denke segmentiere ich das Netz sowieso und würde im Schaltschrank einen Schwitch mit FTP Patchkabeln nutzen, da ja keine Gigabit Bandbreiten benötigt werden.
    Dass ab einem gewissen Punkt die Kosten für Netzwerk eine Rolle spielen, ist mir klar. Dann kann es Sinn machen doch eine neue Infrastruktur aufzubauen.

    Meiner Meindung nach sollte Facility- und Bewohnernetz sowie Gastnetz in jedem Fall getrennt voneinander (VLAN) laufen. Ich gebe aber zu, dass das bei den meisten maximal mit dem Gastnetz getan wird.

    Den Netzwerkdimmer baue ich sowieso mit einem ESP8266 + W5500 um die nötige Performance zu haben. Damit hat man dann auch die Option ihn als WLAN Dimmer einzusetzen, was im Schaltschrank ja wenig Sinn macht.

    Plan ist, nicht jeden gewünschten Dimmwert per Netzwerk zu übertragen (nur als Option analog zu Robert L's UDP2DMX) sondern den Kanal, die gewünschte Helligkeit und die gewünschte Dimmzeit als einzelne Kommando, dann evtl sogar per http, zu übergeben.

    Quasi MQTT/TCP/UDP mit mehreren Eingabeoptionen und Webinterface zur Konfiguration - Version 1 mit Netzwerk. Zukünftig könnte man zum Beispiel darüber nachdenken von einem Masterdimmer mehrere Slavedimmer per z.B. RS485 oder CAN anzubinden. Ich wollte aber die Kirche fürs erste im Dorf lassen - spricht ja auch gegen meine ursprüngliche Idee keine neue Infrstruktur aufzubauen.

    Die UDP2DMX-Platine wollte ich vor allem bauen um allen hier eine fertige Platine zu ermöglichen aber auch um für mich zu lernen, was ich alles für Netzwerk mit W5500 tun muss.
    Zuletzt geändert von pmayer; 28.10.2017, 13:53.

  • challo
    kommentierte 's Antwort
    Soll über RS485 dann "nur" der neue Zielwert Übertragen werden und der Dimmer benutzt dann eine Dimmkurve um diesen Wert zu erreichen oder werden zwischenwerte über RS485 übertragen?

  • hismastersvoice
    antwortet
    Eventuell noch etwas interessantes von genau diesen Dimmern. Das könnte vor allem (wie gerade oben gelesen habe) hismastersvoice interessieren :-)
    Der China Dimmer hat den RS485 Chip so beschaltet, daß man damit bidirektional halbduplex kommunizieren kann, der Bus ist über einen Prozessorpin in der Richtung umschaltbar, RX wie auch TX wurden belegt. Somit könnte man aus diesem Dimmer rein per Software auch einen RS485 Dimmer machen.
    Das wäre der Hammer wenn man einen RS485 Dimmer bauen würde.
    Für 170€ eine RS485 Extension und dazu die Dimmer für billiges Geld.
    Ich muss mir die Dimmer mal genauer anschauen.

    Im Augenblick brauche ich ja noch nichts zu ändern da alle sehr gut funktioniert und ich mit der Lösung zufrieden bin.
    Aber wenn wir vielen anderen damit helfen können das nicht nur die "teuren" und Leistungsschwachen Loxone DMX Dimmer funktionieren richtig funktionieren würde das vielen helfen.

    Code:
    Ich habe jetzt die letzten Tage damit verbracht Klemmen zu suchen, die neben die Netzwerkbuchse in einem 2TE-Gehäuse ohne Bearbeitung passen. Alles was ich gefunden habe würde die Kosten nur unnötig erhöhen. Es wird daher das 3TE Gehäuse werden mit üblichen Schraubklemmen, zwei für die Spannungsversorgung, 3 für DMX - auch weil ich dann eine übliche Netzwerkbuchse nehmen kann und nicht die extra für das Gehäuse gefertigte von Phönix Contact.
    Das Thema ist hier zB das ich dann die DMX-Ext ausbaue und die Neue wie bei mir mit 3TE nicht mehr an der Stelle rein passt.
    Das würde nun heißen die Verdrahtung neu zu machen, machbar aber eben nicht schön.

    Ich denke das die Bearbeitung des Gehäuse kein Problem ist, wir machen ein PDF mit eine Schablone und jeder hat eine kleine Säge und einen Bohrer um das zu bearbeiten.
    In dem Fall opferst du die Kompatibilität nur wegen dem bearbeiten des Gehäuse.
    Es geht ja nur um eine Öffnung für den Ethernet-Port.

    Einen Kommentar schreiben:


  • Robert L.
    kommentierte 's Antwort
    daumen hoch

    >Stelle mir grade das Szenario vor wo eine schöner Fade von einer Farbe zur anderen durch Videostreams und zig anderen Teilnehmen auf dem Netzwerk
    >zerstückelt wird.

    DAS passiert allerdings nicht: weil man einen Switch hat,und der eben den trafic vom Miniserver zur DMX-extension "vollkommen" unabhängig vom rest macht (aber grundsätzlich hast natürlich recht..)

  • Labmaster
    antwortet
    Nochmal kurz zurück zur Auflösung von Dimmern.
    Die Auflösung auf dem Übetragungsweg sind mit 8bit eigentlich wirklich völlig ausreichend , daß Problem ist das zeitliche Verhalten beim Dimmen.
    Intern verwenden die meisten Dimmer eh eine höhere PWM Auflösung, gerade wenn Sie eine entsprechende Kurve (Anpassung an die Helligkeitswahrnehmung des menschlichen Auges) verfügbar haben.
    Hier ist es nun eben auch entscheident wie zeitlich verfahren wird, also wie oft z.B. die PWM upgedatet wird und ob somit entsprechende Zwischenschritte interpoliert werden.
    Genau das ist ja das Problem der original DMX Extension, die zeitliche Schrittweite des Updates ist wegen des Loxbuses zur groß, somit muß am Ende der Kette der einzelne Dimmer für die Interpolation sorgen. Das machen aber bisher fast nur die original Loxone DMX Dimmer. Normale "fremde" DMX Dimmer stellen immer so schnell wie möglich die per DMX gestellte Helligkeit ein,

    Das ist auch eben der Grund warum ich eine eigene Firmware für den China Dimmer machen möchte, dieser soll auch einstellbare Parameter für Interpolation, bzw. Dynamikbegrenzung sowie Dimmkurven usw. zu bekommen. ( https://www.loxforum.com/forum/hardw...chienen-dimmer )

    Eventuell noch etwas interessantes von genau diesen Dimmern. Das könnte vor allem (wie gerade oben gelesen habe) hismastersvoice interessieren :-)
    Der China Dimmer hat den RS485 Chip so beschaltet, daß man damit bidirektional halbduplex kommunizieren kann, der Bus ist über einen Prozessorpin in der Richtung umschaltbar, RX wie auch TX wurden belegt. Somit könnte man aus diesem Dimmer rein per Software auch einen RS485 Dimmer machen.

    @pmayer
    Was soll der Vorteil eines direkt netzwerkfähigen Dimmers ( UDP/MQTT ) sein ?
    Wenn man nicht gerade so "mistiges" WLlan verwenden möchte muss man für jeden Dimmer man dann einen eigenen Netzwerkport vorsehen, der Overhead auf dem Netzwerk durch noch mehr Geräte mit kleinen Paketen steigt ebenso.

    Ich denke die Lösung eine Netzwerkfähige DMX Extension zu haben ist der richtigere Weg. Aber auch hier wir dman aufpassen müssen, daß das zeitliche Verhalten intelligent behandelt wird.
    Da ein klassiche Netzwerk ja zeitlich nicht wirklich deterministisch ist, stelle ich mir diese Aufgaben nicht gerade einfach vor.
    Stelle mir grade das Szenario vor wo eine schöner Fade von einer Farbe zur anderen durch Videostreams und zig anderen Teilnehmen auf dem Netzwerk zerstückelt wird.


    Zuletzt geändert von Labmaster; 27.10.2017, 07:59.

    Einen Kommentar schreiben:


  • pmayer
    antwortet
    Ich habe jetzt die letzten Tage damit verbracht Klemmen zu suchen, die neben die Netzwerkbuchse in einem 2TE-Gehäuse ohne Barbeitung passen. Alles was ich gefunden habe würde die Kosten nur unnötig erhöhen. Es wird daher das 3TE Gehäuse werden mit üblichen Schraubklemmen, zwei für die Spannungsversorung, 3 für DMX - auch weil ich dann eine übliche Netzwerkbuchse nehmen kann und nicht die extra für das Gehäuse gefertigte von Phönix Contact.
    Zuletzt geändert von pmayer; 26.10.2017, 21:19.

    Einen Kommentar schreiben:


  • pmayer
    kommentierte 's Antwort
    WIP - Work in Progress.

    Siehe im Beitrag: "Hab mal die ersten Schritte für die Schaltung getan."

  • tyke
    kommentierte 's Antwort
    Hat es einen Grund, warum du die SPI Schnittstelle vom WS nicht am Atmega angehängt hast? So wird es ja nicht funktionieren.
    Lg

  • hismastersvoice
    kommentierte 's Antwort
    Ja, ist eine gute aber halt auch sehr teure Alternative.

  • tholle
    kommentierte 's Antwort
    Waere DALI denn eine brauchbare/bessere Alternative?

  • pmayer
    kommentierte 's Antwort
    Da gebe ich zu, kenne ich mich überhaupt nicht mit aus... ich schaue mal, dass ich am WE ein wenig stöbere. Wenn einer von euch Beispiele hat auch gerne her damit.
    Mal gucken ob ich heut Abend am Netzwerkteil weiter machen kann... Gerade noch zu viel um die Ohren.

  • Robert L.
    kommentierte 's Antwort
    >Warum nicht MQTToder UDP?
    wenn man (generell) ohen (W)LAN auskommt, wäre das grundsätzlich schon resourcenschonender und stabiler (sogesehen hat loxone extension schon einen vorteil)

    aber ja, zum PWM LED DImmen, hast du recht (da kannst auch z.b. H801 nehmen, )

    aber es gibt ja auch noch andere DMX Hardware...

  • hismastersvoice
    kommentierte 's Antwort
    Hat du sicher Recht, aber es ist halt ein Standard.
    Wenn da Mal jemand andere an die Anlage muss ist es nicht kpl. aus der Luft gegriffen.

  • pmayer
    kommentierte 's Antwort
    Ok, aber macht es dann überhaupt Sinn ein so "beschnittenes" Protokoll zu nutzen, wenn man mehr als 8-bit will? Warum nicht MQTT oder UDP?

    Wie gesagt, bei RGB Dimmen kommt man an 8-bit eh nicht vorbei weil 8bit x 8bit x 8bit (RGB) = 16Mil Farben sind.

    Deswegen ja auch die Idee über das Abbilden des Wertebereiches mit Dimmkurven, damit man im unteren Helligkeitsbereich präziser dimmen kann. Ab 60% Helligkeit kann man dann ja ungenauer dimmen...
Lädt...