Ich habe mir etwas gegönnt und gerade eben den LAN-to-DMX-Controller bestellt, um aus FHEM über LAN meine Terrasse mit entsprechenden Scheinwerfern zu beleuchten. Etwas Doku gibt es auch und lernen will ich auch noch etwas. Ich werde berichten und möglicherweise auch Hinweise benötigen. Jetzt erst einmal auf Lieferung warten.
Die Schnittstelle von wifilight sollte sein, damit man die set, dim, RBG und H,S,V Kommandos genauso nutzen kann - das hat Jörg so gut gemacht, da muss man ja das Rad nicht neu erfinden.
Adressiert wird das Teil über eine IP-Adresse und den Port 10001. In der Doku steht dann weiter:
The sent and received data are RAW-data packets with the DMX4ALL command data inside.
Ein einfacher RBG-Strahler hat 3 Kanäle (0, 1 und 2), so dass ich 50% Grün wie folgt bekomme:
Transmit character: C001L128
Receive character: G
Soweit die Theorie.
Um einen Scheinwefer zu definieren brauche ich also die IP-Adresse und die 3 Kanäle. Eine bestimmte Farbe entsteht durch Versenden 3er Telegramme.
ein nicht unerheblicher Teil von wifilight beschäftigt sich mit den transitions, timing, Farbkorrektur etc.
Wenn das man dem device über tcp byte sequenzen sagen kann welche Farben kann man das sogar mit überschaubarem Aufwand implementieren.
Aus dem anderen thread habe ich mitgenommen das die über ein usb device angesteuert werden ?
Hier wäre das Protokoll ? https://domotiga.nl/attachments/download/925/DMX4ALL_Commands.pdf
vg
joerg
wenn ich das richtig interpretiere kann man absolute RGB werte setzen:
CaaaLbbb
Kanal 1 ist R, 2 ist G, 3 ist B wenn ich das richtig verstehe ?
Wenn man also einen konkret #FF00FF setzen möchte dann sendet man:
C001L255
C002L000
C003L255
Ist das richtig ?
vg
joerg
Ich habe ja schon folgendes bei mir realisiert: 2 wifilight devices, wobei ich nur eines direkt mit Werten versorge und das andere einfach über ein notify die RBG-Werte weiterreiche. Insofern wäre meine erste Idee, dass ich eben auch nur die RBG-Werte an das LAN-to-DMX weitergebe und den Rest erst einmal ignoriere. Jetzt muss ich "nur" noch herausfinden mit welchen FHEM oder Perl Mitteln ich die Daten transferiere - aber nicht mehr heute Nacht! Mal sehen, was mir morgen das FHEM Wiki und die commandref sagen.
Zitat von: herrmannj am 22 Januar 2016, 23:58:22
wenn ich das richtig interpretiere kann man absolute RGB werte setzen:
CaaaLbbb
Kanal 1 ist R, 2 ist G, 3 ist B wenn ich das richtig verstehe ?
Wenn man also einen konkret #FF00FF setzen möchte dann sendet man:
C001L255
C002L000
C003L255
Ist das richtig ?
vg
joerg
ja aber es geht noch kürzer mit dem Array-Kommando:
FF 00 00 03 FF 00 FF
1. FF = Array-Transfer
2. 00 = Low Byte Startkanal
3. 00 = High Byte Startkanal
4. 03 = Anzahl Kanäle
5. FF = Wert Kanal 0
6. 00 = Wert Kanal 1
7. FF = Wert Kanal 2
perfekt. RGBW wären FF 00 00 04 FF 00 FF xx ?
Das kann man mit vertretbarem Aufwand in wifilight integrieren. LW12_setHSV als Beispiel.
Extern über notifys stimmen timing farbkorrektur etc alles nicht.
vg
joerg
btw, wofür haben die DMX eigentlich so viele Kanäle ?
liegen RGB immer auf 1,2,3 ?
vg
joerg
Zitat von: herrmannj am 23 Januar 2016, 00:37:40
perfekt. RGBW wären FF 00 00 04 FF 00 FF xx ?
Das kann man mit vertretbarem Aufwand in wifilight integrieren. LW12_setHSV als Beispiel.
Extern über notifys stimmen timing farbkorrektur etc alles nicht.
vg
joerg
Ich versuche gerade mal dein Modul zu verstehen, insbesondere wie die Kommunikation über LAN abläuft.
Zitat von: herrmannj am 23 Januar 2016, 00:38:37
btw, wofür haben die DMX eigentlich so viele Kanäle ?
liegen RGB immer auf 1,2,3 ?
vg
joerg
Es gibt ja in der Lichtszene noch mehr als nur Farbmischung, Stroboskobeffekte oder Blackout, was in der Zeit vor LEDs ganz sicher nicht das Ausschalten der Leuchtmittel war. Der DMX-Profi bin ich aber nicht, ich will nur mein Haus und meine Terrasse in buntes Licht tauchen. Die DMX-Kanäle liegen wohl immer hintereinander, aber der 1. Kanal muss nicht 0 sein, im Gegenteil: wenn ich 10 Schweinwerfer an einer Leitung habe, dann müssen die ja auf unterschiedlichen Kanälen angesprochen werden.
Aus der praktischen Erfahrung mit DMX im Veranstaltungsbereich, möchte ich darauf hinweisen, dass viele Leuchten noch einen Master-Kanal haben, der quasi die Gesamthelligkeit steuert. Wenn man nun alle 3 Kanäle für RGB aufdreht, muss man auch den Masterkanal aufdrehen, bevor die Lampe leuchtet.
Bei manchen Lampen liegt der Masterkanal ganz vorne (relativ gesehen: Kanal 0), danach 3 Kanäle für RGB und noch ein paar zusätzliche Effektkanäle (Strobe, Farblauf, ...). Bei anderen liegt der Masterkanal ganz hinten (R, G, B, Effekte ..., Master). Ander wiederrum haben keinen Master.
Daher muss man hier eine Flexibilität anbieten, die es dem Nutzer ermöglicht zu sagen, welche Lampe auf welchem Kanal relativ zum Startkanal die einzelnen Kanäle liegen. Ist besonders lustig, wenn man Lampen von verschiedenen Herstellern hat und die dann auf einem Lichtpult unterkriegen möchte, was ein solches individuelles Mapping nicht ermöglicht.
Viele Grüße
Markus
Hallo zusammen,
ich habe vor einigen Wochen auch bereits nach einer möglichen DMX Steuerung über Fhem gesucht. Dabei bin ich auch über DMX4ALL gestolpert und habe aufgrund des Preises gleich weiter gesucht. Ich finde die Preise sind absolut überzogen und DMX4ALL ist denke ich auch von einer Integration in Fhem nicht gerade begeistert, da sie schließlich auch ihre eigene Software vertreiben wollen.
Auf der Suche nach einer Preiswerten alternative bin ich auf folgende sehr günstige Hardware gestoßen.
Diese gibt es als Bausatz (ArtNet-Node-Bausatz):
http://shop.ulrichradig.de/Bausaetze/Uli-s-DMX-Kit-s/AVR-ArtNet-Node-Bausatz.html (http://shop.ulrichradig.de/Bausaetze/Uli-s-DMX-Kit-s/AVR-ArtNet-Node-Bausatz.html)
und auch schon fertig mit dem passenden Gehäuse (Art-Net-Box-Bausatz):
http://shop.ulrichradig.de/Bausaetze/Uli-s-DMX-Kit-s/Art-Net-Box-Bausatz.html?listtype=search&searchparam=Art%20Net%20Box (http://shop.ulrichradig.de/Bausaetze/Uli-s-DMX-Kit-s/Art-Net-Box-Bausatz.html?listtype=search&searchparam=Art%20Net%20Box)
Des weiteren habe ich auch noch jemanden gefunden, der sich bereits mit der Integration in Fhem auf basis der o.g. Hardware 2014 schon mal damit befasst hat.
https://github.com/fdemmer/fhem-artdmx/tree/master (https://github.com/fdemmer/fhem-artdmx/tree/master)
Ich habe den Florian mal angeschrieben und ihn gefragt ob das noch funktioniert. Er hat das leider nicht für sich selbst gemacht und benutzt seit dem auch kein Fhem mehr. Er konnte daher leider nicht mehr sagen ob es mit der aktuellen Fhementwicklung noch funktioniert. Wir dürfen allerdings seinen Code weiterverwenden.
Ich hätte mir die Hardware schon fast bestellt, war mir dann doch unsicher, da ich selbst keine Programmierkenntnisse besitze, falls doch etwas angepasst werden müsste.
Ich würde die Entwicklung auch gerne unterstützen! Könnt ihr euch die Hardware und das Fhemmodul anschauen, ob dass uns weiter helfen kann und eine bessere Alternative darstellt?
Ich habe mal meine LED-Steuerung (ab Seite 11) mit DMX-Schnittstelle angehängt. Vielleicht könnt ihr das bei der Weiterentwicklung mit berücksichtigen.
Hi Markus,
DMX Kenntnisse helfen hier sehr (ich habe keine ;) ) VIELEN DANK.
First: WifiLight ist kein DMX Spezial modul, wirds auch nicht werden weil zu DMX mehr gehört als nur farbiges Licht.
Die Frage die sich Jürgen gestellt, und zum Projekt gemacht hat, lautet ja ob sich SEIN LAN/WIFI DMX controller damit so einbinden lässt wie jede andere LED.
Nach erster evaluierung sage ich mal: geht. Mit überschaubarem Aufwand.
Zum DMX: soweit ich verstehe bekommt also jede LAMPE eine Anzahl X der vorhandenen 255 Kanäle zugeteilt. In unserem Kontext hier wäre dann nur interessant welche Kanalnummern je Lampe für R,G,B und evtl noch Weiß konfiguriert sind. Plus dem Master brightness.
Systematisch würden sich also einige Lampen den Controller teilen. Das wäre analog zu den Milights.
In der physischen Ausgabe müsste das modul also schauen wie das mapping Lampe / Channel (RGB) zu den Kanälen ist, sicherheitshalber einmal master auf 0xff und dann "Kanalnummer von R" auf XX / "Kanalnummer von G" usw.
Dazu am einfachsten den Array Befehl, je nach Kanalkonstellation evtl mehrfach. Wenn RGB = Kanal 1,2,3 in einem Rutsch - wenn R,G,B = Kanal 23,27,12 dann eben 3x array ..
So richtig ?
Wenn ja würde ich Jürgen vorschlagen im define die Kanäle zu zuordnen:
define x WifiLight RGB DMX4ALL:192.168.1.99 1,23,27,12
master = 1 und R,G,B = Kanal 23,27,12
Macht Sinn ?
vg
joerg
@Markus, ja das ist mir bekannt, aber ich gehe aktuell noch davon aus, dass wenn die Leuchte nur 3 Kanäle hat, diese RGB sind.
@Holzwurm, meine Herausforderung ist, dass ich zwar Strom auf der Terrasse habe, aber keine weiteren Leitungen durch die Hauswand bohren kann. Insofern geht es bei mir über WLAN oder Power-LAN nach draußen und dort brauche ich dann einen LAN-to-DMX. Außerdem muss das absolut stabil laufen, Bastellösung scheidet aus. Ich habe auch lange gezögert, bevor das Teil nun bestellte.
@Jörg / alle, ich will ja keinen "fully featured" DMX-Controller haben sondern nur konstant-buntes Licht auf der Terrasse und der Hauswand. Da genügt RGB, bzw. RGBW vollkommen. Und die vorhandene Wifilight-Steuerung kann jeder bedienen. Die Bedienerschnittstelle mit Helligkeit und Farbauswahl ist einfach genau richtig und hat sich in unserem Heim-Wellness voll bewährt. Nächste Woche bekomme ich den Umsetzer hoffentlich, dann kann ich auf meinem 2. Raspberry mal ein Testsystem aufbauen - und dann schauen wir mal, wie sich das in FHEM einbinden lässt.
Mangels Wissen und Erfahrung muss ich da noch durch ganz viele Themen durch, aber irgendwann muss man ja mal anfangen. Für mich bedeutet das: jetzt. Ich sehe 3 Möglichkeiten:
- über die 99_MyUtils eine Funktion bauen, die einfach dem vorhanden Wifilight folgt - da muss ich mich nur in die Kommunikation einarbeiten, was schon eine Herausforderung an sich ist, z.B. die triviale Frage, wer denn Server und wer Client ist und wie ich non-blocking genau realisiere
- Anhand von Wifilight ein komplettes eigenes Modul bauen, das sollte dann irgendwie 47_LanToDMX heißen, wobei ich noch nirgends gefunden habe, wie sich die Nummer bestimmt und welche Namensspielregeln einzuhalten sind, wenn man glaubt das der FHEM-Gemeinde anbieten zu wollen.
- In das vorhandene Wifilight integrieren, was mich aber dann von der weiteren Entwicklung abkoppeln würde, ich muss dann auch aufpassen, dass ich kein Update mache - also eher keine Alternative
- Theoretisch könnte ich auch noch Jörg zuarbeiten, so dass es Bestandteil von Wifilight wird, aber ich setze das keineswegs voraus, ich hoffe das auch nicht hintergründig. Zumal ich auch noch lernen möchte und das geht am besten an einem konkretem Projekt. Selbst wenn Jörg hier aktiv werden möchte, muss ich ja noch irgendeinen Weg finden mein Wissen zu vertiefen, ich habe nämlich noch ein paar weitere LAN-Geräte, die eingebunden werden wollen (Solaranlage, Stromspeicher, BluRayPlayer, CD-Player/Streamer und den T&A Caruso, der zum Luxus-Wecker in FHEM eingebunden mutieren soll). Das Licht scheint mir aber der einfachere Start zu sein.
Zitat von: ujaudio am 23 Januar 2016, 16:25:37
@Holzwurm, meine Herausforderung ist, dass ich zwar Strom auf der Terrasse habe, aber keine weiteren Leitungen durch die Hauswand bohren kann. Insofern geht es bei mir über WLAN oder Power-LAN nach draußen und dort brauche ich dann einen LAN-to-DMX. Außerdem muss das absolut stabil laufen, Bastellösung scheidet aus. Ich habe auch lange gezögert, bevor das Teil nun bestellte.
Hallo Jürgen,
warum soll das eine Bestelllösung sein? Der LAN-to-DMX hat doch auch keine WLAN!? Man muss sich ja nicht den Bausatz kaufen! Die Hardware ist im Grund kein bisschen besser oder schlechter, aber wesentlich günstiger!
Hast du dir das angeschaut?
http://www.ulrichradig.de/home/index.php/dmx/art-net-box (http://www.ulrichradig.de/home/index.php/dmx/art-net-box)
Ja, hatte ich kurz auf dem Schirm, aber wg. "ART NET" gleich wieder weggeklickt. Jetzt habe ich es genauer gelesen.
Und wie muss man das Teil ansteuern? Wie ist die Schnittstelle definiert, da habe ich erst einmal nichts gefunden, ich muss doch irgendwelche Daten auf die Ethernetleitung geben, damit ich z.B. meine 50% Grün bekomme.
Hier war schon jemand fleißig:
https://github.com/fdemmer/fhem-artdmx/tree/master (https://github.com/fdemmer/fhem-artdmx/tree/master)
und hat bereits eine komplette Ansteuerung über Fhem erstellt.
Hier wäre die Beschreibung der Schnittstelle:
http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf (http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf)
Zitat von: herrmannj am 23 Januar 2016, 14:36:50...
Wenn ja würde ich Jürgen vorschlagen im define die Kanäle zu zuordnen:
define x WifiLight RGB DMX4ALL:192.168.1.99 1,23,27,12
master = 1 und R,G,B = Kanal 23,27,12
Macht Sinn ?
vg
joerg
Jörg, ich hoffe du liest hier mit. Was ist denn besser?
- 3 Kanäle (RGB) oder
- 4 Kanäle (RGB + Masterhelligkeit)
immer aus Sicht von Wifilight.
Ich würde das so implementieren:
define <name> WifiLight RGB DMX4ALL:<IP> <R-Kanal> <G-Kanal> <B-Kanal> <Master-Kanal>wobei nur der R-Kanal angegeben sein muss, weil viele Geräte die Kanäle nacheinander haben und meist auch den 3-Kanal-Mode ohne Masterhelligkeit unterstützen. man muss also beid er Definition 1, 3 oder 4 Kanäle angeben. Macht das so Sinn?
Hallo Jürgen,
ja, ich lese mit.
Bzgl der def und aus Sicht WifiLight: lass mich mal drüber nachdenken damit das dann auch einfach zu parsen ist.
So aus dem Bauch herraus würde ich sowas sehen: define x WifiLight RGB DMX4ALL:192.168.1.99 /Master:0 /Red:1 /Green:2 /Blue:3 /White:4
Das liese sich relativ leicht parsen und man behält sich was offen für Warmweiss, Kaltweiss etc.
Von der Logik her ist man dann auch flexibel, Master kann man so recht einfach optional machen.
Ich habe Deinen anderen thread auch gesehen. Ich habe nichts dagegen das in Wifilight aufzunehmen und für Dich wäre das deutlich angenehmer. Wenn Du das Modul von Grund auf erstellst ist die Strecke sehr weit und es wird auch beliebig kompliziert.
Zu der reinen IP Kommunikation kommen OS spezifische Teile, das ganze darf nicht blockierend sein (ein IO Thema: non-blocking). Dazu kommen Timing Fragen, Gamma Anpassung etc.
Wenn Du schnelle erfolge haben möchtest mach folgendes:
"Mißbrauche" den LW12. Der ist von Natur aus TCP (ich gehe davon aus das der DMX TCP und nicht UDP spricht ?) und RGB.
Beim define eines LW12 kannst Du den Port angeben.
Dann musst Du nur noch innerhalb der lw12_setHSV routine die konkreten Ausgabebefehl "klöppeln". Um die Netzwerk Kommunikation und das Timing kümmert sich dann das modul. Lass Dich nicht von den zahlreichen "Dim" etc routinen ablenken. Das ist historisch so gewachsen, das verschlanke ich mal denn das ist viel reduntant. Du brauchst eigentlich nur das lw12_setHHSV anzupassen das es die richtigen Befehle für das DMX an "..addLowLevelQueue" übergibt. Du kannst Dich da auch perfekt am LW12 orientieren, nur das Du eigentlich ASCI sprechen darfst, der LW12 ist so "rein binär".
Später bau ich das dann als eigenen Controller ein.
vg
joerg
Da ich ein LW12 habe werde ich wohl das LW12HX "missbrauchen". Ich gehe mal davon aus, das ich nächste Woche alle Teile im Haus habe und in 14 Tagen das zum Laufen bekomme (optimistisch gesehen :D).
Ich habe vorhin aber mal einen längeren Spaziergang gemacht, um den Kopf wieder frei zu bekommen und bin dabei auf folgende Problematik gestoßen: Die hier angedachte Lösung passt für mich perfekt, weil ich identische Scheinwerfer habe und diese ausschließlich identisch ansteuern möchte und mit dem Funktionsumfang von Wifilight perfekt zufrieden bin.
Im etwas allgemeineren Fall kann ich mir vorstellen, dass jemand mehrere DMX-Scheinwerfer hat und diese in unterschiedlichen Farben ansteuern möchte. Das bedeutet aber: 1 IP-Adresse für alle Scheinwerfer, aber je Scheinwerfer unterschiedliche Kanäle. Damit wäre folgende Definition wünschenswert:
define x1 WifiLight RGB DMX4ALL:192.168.1.99 /Master:0 /Red:1 /Green:2 /Blue:3 /White:4
define x2 WifiLight RGB DMX4ALL:192.168.1.99 /Master:10 /Red:11 /Green:12 /Blue:13 /White:14
Mehrere Definitionen mit gleicher IP-Adresse wären zulässig, die Kanäle sollten sich unterscheiden, das muss aber nicht unbedingt von FHEM geprüft werden, wenn der Anwender hier Fehler macht, kommt aber sicherlich ein unerwartetes Lichtergebnis heraus ;).
Das wäre aber schon das Maximum an Funktion, alles weitere geht weit über Hausautomatisierung hinaus und da sollte man sich dann ein Lichtpult zulegen.
Zitat von: herrmannj am 24 Januar 2016, 14:28:45...
Dann musst Du nur noch innerhalb der lw12_setHSV routine die konkreten Ausgabebefehl "klöppeln" ... Du brauchst eigentlich nur das lw12_setHHSV anzupassen das es die richtigen Befehle für das DMX an "..addLowLevelQueue" übergibt. Du kannst Dich da auch perfekt am LW12 orientieren, nur das Du eigentlich ASCI sprechen darfst, der LW12 ist so "rein binär".
Später bau ich das dann als eigenen Controller ein.
vg
joerg
Gemeint ist sicher die Routine "WifiLight_RGBLW12_setHSV". Aber "WifiLight_RGBLW12_On" ist doch auch anzupassen, oder?
2x yepp
Na, dann habe ich ja wenigstens schon einen kleinen Teil des Codes verstanden ;)
Nachtrag: Habe das nun soweit mal vorbereitet, mal sehen, was ich in 14 Tagen berichten kann.
Erstes Erfolgserlebnis:
LW12 missbraucht und hier die Kommandos für meine 3-Kanal-DMX-Leuchte angepasst. Es funktioniert - naja, nicht ganz stabil. Das log-file sagt mir, wenn ich nacheinander rot, blau und grün ansteuer:
2016.01.29 18:03:14 5: myDMX prepare start hsv transition (is actual) hsv 120, 100, 100, 1454086994.51776
2016.01.29 18:03:14 4: myDMX current HSV 120, 100, 100
2016.01.29 18:03:14 3: myDMX set HSV 0, 100, 100 with ramp: 0, flags:
2016.01.29 18:03:14 4: myDMX hsv transition without ramp routed to direct settings, hsv 0, 100, 100
2016.01.29 18:03:14 4: myDMX high level cmd queue add hsv/ctrl 0, 100, 100, ctrl , targetTime 1454086994.51776, qlen 1
2016.01.29 18:03:14 5: myDMX high level cmd queue exec dropper delay: -0.0548758506774902
2016.01.29 18:03:14 4: myDMX high level cmd queue exec hsv 0, 100, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.29 18:03:14 4: myDMX RGB LW12 set h:0, s:100, v:100
2016.01.29 18:03:14 5: myDMX low level cmd queue add ff000003ff0000, qlen 1
2016.01.29 18:03:14 5: myDMX low level cmd queue qlen 1, send ff000003ff0000
2016.01.29 18:03:14 4: myDMX low level cmd queue send ff000003ff0000, qlen 1 connection refused: trying to reconnect
2016.01.29 18:03:14 5: myDMX low level cmd queue add 00, qlen 2
2016.01.29 18:03:14 4: myDMX high level cmd queue ask next 1454086994.83681
2016.01.29 18:03:14 5: myDMX | myDMX unlock queue 0
2016.01.29 18:03:20 3: CUL_HM set or_blind 0
2016.01.29 18:03:24 5: myDMX prepare start hsv transition (is actual) hsv 0, 100, 100, 1454087004.29593
2016.01.29 18:03:24 4: myDMX current HSV 0, 100, 100
2016.01.29 18:03:24 3: myDMX set HSV 240, 100, 100 with ramp: 0, flags:
2016.01.29 18:03:24 4: myDMX hsv transition without ramp routed to direct settings, hsv 240, 100, 100
2016.01.29 18:03:24 4: myDMX high level cmd queue add hsv/ctrl 240, 100, 100, ctrl , targetTime 1454087004.29593, qlen 1
2016.01.29 18:03:24 5: myDMX high level cmd queue exec dropper delay: -0.0522329807281494
2016.01.29 18:03:24 4: myDMX high level cmd queue exec hsv 240, 100, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.29 18:03:24 4: myDMX RGB LW12 set h:240, s:100, v:100
2016.01.29 18:03:24 5: myDMX low level cmd queue add ff0000030000ff, qlen 1
2016.01.29 18:03:24 5: myDMX low level cmd queue qlen 1, send ff0000030000ff
2016.01.29 18:03:24 4: myDMX low level cmd queue send ff0000030000ff, qlen 1 connection refused: trying to reconnect
2016.01.29 18:03:24 5: myDMX low level cmd queue add 00, qlen 2
2016.01.29 18:03:24 4: myDMX high level cmd queue ask next 1454087004.60037
2016.01.29 18:03:24 5: myDMX | myDMX unlock queue 0
2016.01.29 18:03:33 5: myDMX prepare start hsv transition (is actual) hsv 240, 100, 100, 1454087013.05812
2016.01.29 18:03:33 4: myDMX current HSV 240, 100, 100
2016.01.29 18:03:33 3: myDMX set HSV 120, 100, 100 with ramp: 0, flags:
2016.01.29 18:03:33 4: myDMX hsv transition without ramp routed to direct settings, hsv 120, 100, 100
2016.01.29 18:03:33 4: myDMX high level cmd queue add hsv/ctrl 120, 100, 100, ctrl , targetTime 1454087013.05812, qlen 1
2016.01.29 18:03:33 5: myDMX high level cmd queue exec dropper delay: -0.0502679347991943
2016.01.29 18:03:33 4: myDMX high level cmd queue exec hsv 120, 100, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.29 18:03:33 4: myDMX RGB LW12 set h:120, s:100, v:100
2016.01.29 18:03:33 5: myDMX low level cmd queue add ff00000300ff00, qlen 1
2016.01.29 18:03:33 5: myDMX low level cmd queue qlen 1, send ff00000300ff00
2016.01.29 18:03:33 4: myDMX low level cmd queue send ff00000300ff00, qlen 1 connection refused: trying to reconnect
2016.01.29 18:03:33 3: myDMX low level cmd queue send ERROR ff00000300ff00, qlen 1 (reconnect giving up)
2016.01.29 18:03:33 5: myDMX low level cmd queue add 00, qlen 2
2016.01.29 18:03:33 4: myDMX high level cmd queue ask next 1454087013.56124
2016.01.29 18:03:33 5: myDMX | myDMX unlock queue 0
2016.01.29 18:03:38 5: myDMX prepare start hsv transition (is actual) hsv 120, 100, 100, 1454087018.47974
2016.01.29 18:03:38 4: myDMX current HSV 120, 100, 100
2016.01.29 18:03:38 3: myDMX set HSV 120, 100, 100 with ramp: 0, flags:
2016.01.29 18:03:38 4: myDMX hsv transition without ramp routed to direct settings, hsv 120, 100, 100
2016.01.29 18:03:38 4: myDMX high level cmd queue add hsv/ctrl 120, 100, 100, ctrl , targetTime 1454087018.47974, qlen 1
2016.01.29 18:03:38 5: myDMX high level cmd queue exec dropper delay: -0.0459799766540527
2016.01.29 18:03:38 4: myDMX high level cmd queue exec hsv 120, 100, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.29 18:03:38 4: myDMX RGB LW12 set h:120, s:100, v:100
2016.01.29 18:03:38 5: myDMX low level cmd queue add ff00000300ff00, qlen 1
2016.01.29 18:03:38 5: myDMX low level cmd queue qlen 1, send ff00000300ff00
2016.01.29 18:03:38 4: myDMX low level cmd queue send ff00000300ff00, qlen 1 connection refused: trying to reconnect
2016.01.29 18:03:38 3: myDMX low level cmd queue send ERROR ff00000300ff00, qlen 1 (reconnect giving up)
2016.01.29 18:03:38 5: myDMX low level cmd queue add 00, qlen 2
2016.01.29 18:03:38 4: myDMX high level cmd queue ask next 1454087018.96225
2016.01.29 18:03:39 5: myDMX | myDMX unlock queue 0
Rot und Blau hat auf Anhieb funktioniert, Grün 2 Versuche, beide misslungen.
Weiß funktioniert aber:
2016.01.29 18:05:01 5: myDMX low level cmd queue add ff000003ffffff, qlen 1
2016.01.29 18:05:01 5: myDMX low level cmd queue qlen 1, send ff000003ffffff
2016.01.29 18:05:01 4: myDMX low level cmd queue send ff000003ffffff, qlen 1 connection refused: trying to reconnect
2016.01.29 18:05:01 3: myDMX RGB LW12 set on (0, 0, 100) 0
2016.01.29 18:05:01 5: myDMX prepare start hsv transition (is actual) hsv 120, 100, 100, 1454087101.75244
2016.01.29 18:05:01 4: myDMX current HSV 120, 100, 100
2016.01.29 18:05:01 3: myDMX set HSV 0, 0, 100 with ramp: 0, flags:
2016.01.29 18:05:01 4: myDMX hsv transition without ramp routed to direct settings, hsv 0, 0, 100
2016.01.29 18:05:01 4: myDMX high level cmd queue add hsv/ctrl 0, 0, 100, ctrl , targetTime 1454087101.75244, qlen 1
2016.01.29 18:05:01 5: myDMX high level cmd queue exec dropper delay: -0.0491318702697754
2016.01.29 18:05:01 4: myDMX high level cmd queue exec hsv 0, 0, 100, delay 100, hl qlen 1, ll qlen 1, lock 0
2016.01.29 18:05:01 4: myDMX RGB LW12 set h:0, s:0, v:100
2016.01.29 18:05:01 5: myDMX low level cmd queue add ff000003ffffff, qlen 2
2016.01.29 18:05:01 5: myDMX low level cmd queue add 00, qlen 3
2016.01.29 18:05:01 4: myDMX high level cmd queue ask next 1454087102.03111
2016.01.29 18:05:01 5: myDMX low level cmd queue qlen 2, send ff000003ffffff
2016.01.29 18:05:01 4: myDMX low level cmd queue send ff000003ffffff, qlen 2 connection refused: trying to reconnect
2016.01.29 18:05:02 5: myDMX | myDMX unlock queue 0
Auch grün funktioniert:
2016.01.29 18:06:22 5: myDMX prepare start hsv transition (is actual) hsv 0, 0, 100, 1454087182.48692
2016.01.29 18:06:22 4: myDMX current HSV 0, 0, 100
2016.01.29 18:06:22 3: myDMX set HSV 120, 100, 100 with ramp: 0, flags:
2016.01.29 18:06:22 4: myDMX hsv transition without ramp routed to direct settings, hsv 120, 100, 100
2016.01.29 18:06:22 4: myDMX high level cmd queue add hsv/ctrl 120, 100, 100, ctrl , targetTime 1454087182.48692, qlen 1
2016.01.29 18:06:22 5: myDMX high level cmd queue exec dropper delay: -0.053570032119751
2016.01.29 18:06:22 4: myDMX high level cmd queue exec hsv 120, 100, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.29 18:06:22 4: myDMX RGB LW12 set h:120, s:100, v:100
2016.01.29 18:06:22 5: myDMX low level cmd queue add ff00000300ff00, qlen 1
2016.01.29 18:06:22 5: myDMX low level cmd queue qlen 1, send ff00000300ff00
2016.01.29 18:06:22 4: myDMX low level cmd queue send ff00000300ff00, qlen 1 connection refused: trying to reconnect
2016.01.29 18:06:22 5: myDMX low level cmd queue add 00, qlen 2
2016.01.29 18:06:22 4: myDMX high level cmd queue ask next 1454087182.79708
2016.01.29 18:06:22 5: myDMX | myDMX unlock queue 0
Aber was bedeutet " connection refused: trying to reconnect"?
Möglicherweise muss ich am LAN-DMX noch etwas besser machen? Könnte sein, ich werde dem mal nachgehen...
Nachtrag: es liegt wohl an den Netzwerkeinstellungen und nicht an FHEM. Wenn FHEM die Farbe nicht mehr ändern kann, kennt die Fritzbox das Gerät auch nicht mehr. nach ein paar Sekunden ist dann alles wieder ok. Also irgendetwas blockiert. Wenn FHEM ein Kommando rausschickt, dann kommt auch eine Rückmeldung. Es wird ein "G" zurückgemeldet (so steht es in der Doku). Was macht FHEM damit?
Oder kann jemand die Netzwerkeinstellungen bewerten? Im angehängten Bildschirmfoto sieht man, was eingestellt ist (ich habe eine feste IP-Adresse vergeben).
Na, das sieht doch gut aus.
Btw, die Kommunikation ist eigentlich fundamental wie bei jedem anderen LED Controller.
"connection refused: trying to reconnect" bedeutet das es ein Netzwerkproblem ist. Die Controller haben oft bugs in den wifi oder ip stacks.
Kannst Du den nicht auf DHCP bringen ?
vg
joerg
würdest Du mir das zukommen lassen ? dann baue ich das ein.
vg
joerg
Zitat von: herrmannj am 29 Januar 2016, 18:38:46...
"connection refused: trying to reconnect" bedeutet das es ein Netzwerkproblem ist. Die Controller haben oft bugs in den wifi oder ip stacks.
Kannst Du den nicht auf DHCP bringen ?
vg
joerg
Das Netzwerkproblem kläre ich separat, bislang bekomme ich eine gute Unterstützung. Auch die weiteren Einstellungen werde ich klären. Gibt es einen technischen Nutzen für DHCP? Allen Geräten, die ich so an der Fritzbox dauerhaft hängen habe, bekommen von mir immer den Haken "immer die gleiche IP zuweisen", insofern ist für mich DHCP nur ein Komfort beim ersten Anschließen. Ich habe mir aber nie weitere Gedanken gemacht. Netzwerk ist bei mir bislang "anschließen - funktioniert".
Zitat von: herrmannj am 30 Januar 2016, 00:24:29
würdest Du mir das zukommen lassen ? dann baue ich das ein.
vg
joerg
Ich habe aktuell nur 2 Zeilen Code verändert und für mich ein paar Kommentare ergänzt:
sub
WifiLight_RGBLW12_On(@)
{
my ($ledDevice, $ramp) = @_;
my $delay = 50;
# my $on = sprintf("%c%c%c", 0xCC, 0x23, 0x33); # Original
my $on = sprintf("%c%c%c%c%c%c%c", 0xFF, 0x00, 0x00, 0x03, 0xFF, 0xFF, 0xFF);
# 1. FF = Block Transfer
# 2. Start channel low byte, vorerst immer 0
# 3. Start channel high byte, vorerst immer 0
# 4. number of channels, vorerst 3
# 5-7. on = weiß = alle Kanäle auf Maximum
my $msg = sprintf("%c%c%c%c%c", 0x56, 0, 0, 0, 0xAA);
my $receiver;
WifiLight_LowLevelCmdQueue_Add($ledDevice, $on, $receiver, $delay);
# WifiLight_LowLevelCmdQueue_Add($ledDevice, $msg, $receiver, $delay);
my ($h, $s, $v) = split(',', AttrVal($ledDevice->{NAME}, "defaultColor", "0,0,100"));
Log3 ($ledDevice, 3, "$ledDevice->{NAME} RGB LW12 set on ($h, $s, $v) $ramp");
return WifiLight_HSV_Transition($ledDevice, $h, $s, $v, $ramp, '', 100, undef);
}
sub
WifiLight_RGBLW12_setHSV(@)
{
my ($ledDevice, $hue, $sat, $val) = @_;
my $receiver = sockaddr_in($ledDevice->{PORT}, inet_aton($ledDevice->{IP}));
my $delay = 50;
Log3 ($ledDevice, 4, "$ledDevice->{NAME} RGB LW12 set h:$hue, s:$sat, v:$val");
WifiLight_setHSV_Readings($ledDevice, $hue, $sat, $val);
# apply gamma correction
my $gammaVal = $ledDevice->{helper}->{GAMMAMAP}[$val];
# color cast correction
my $h = $ledDevice->{helper}->{COLORMAP}[$hue];
#new style converter with white point correction
my ($rr, $rg, $rb, $white) = WifiLight_HSV2fourChannel($h, $sat, $gammaVal);
my ($wr, $wg, $wb) = split(',', AttrVal($ledDevice->{NAME}, 'whitePoint', '1, 1, 1'));
#replace the removed part of white light and apply white balance
$rr += int(($white * $wr) + 0.5);
$rg += int(($white * $wg) + 0.5);
$rb += int(($white * $wb) + 0.5);
# my $msg = sprintf("%c%c%c%c%c", 0x56, $rr, $rg, $rb, 0xAA); # Original
my $msg = sprintf("%c%c%c%c%c%c%c", 0xFF, 0x00, 0x00, 0x03, $rr, $rg, $rb);
# 1. FF = Block Transfer
# 2. Start channel low byte, vorerst immer 0
# 3. Start channel high byte, vorerst immer 0
# 4. number of channels, vorerst 3
# 5-7. individuelle RGB-Werte
# lock ll queue to prevent a bottleneck within llqueue
# in cases where the high level queue fills the low level queue (which should not be interrupted) faster then it is processed (send out)
# this lock will cause the hlexec intentionally drop frames which can safely be done because there are further frames for processing avialable
$ledDevice->{helper}->{llLock} += 1;
WifiLight_LowLevelCmdQueue_Add($ledDevice, $msg, $receiver, $delay);
# unlock ll queue
return WifiLight_LowLevelCmdQueue_Add($ledDevice, "\x00", $receiver, 0, 1);
}
Es wäre gut, wenn du zusätzlich zu RGB auch RGBW realisieren könntest, das ändert sich dann wie folgt, aus
my $msg = sprintf("%c%c%c%c%c%c%c", 0xFF, 0x00, 0x00, 0x03, $rr, $rg, $rb);wird
my $msg = sprintf("%c%c%c%c%c%c%c", 0xFF, 0x00, 0x00, 0x04, $rr, $rg, $rb, $rw);Ich habe mal diverse DMX-LED-Geräte angeschaut: mit RGB und RGBW kann man die alle im 3-, bzw. 4-Kanalbetrieb verwenden. Die Kanäle lagen auch alle hintereinander also immer RGB, bzw. RGBW.
Ich habe nicht den Anspruch, dass du das folgende auch noch machst, aber mein Maximum wäre:
In deinen Code der Bridge bin ich noch nicht eingedrungen, aber da ist es doch auch so, dass man mit 1 Bridge (und damit 1 IP-Adresse) mehrere Lampen ansteuern kann. Insofern wäre es toll, wenn man den LAN-DMX auch als Bridge ansehen könnte und bei der Definition einer "Lampe" noch den Startkanal frei angeben könnte.
define <name> WifiLight DMX4ALL RGB <IP>:<Port> <Kanal>
define <name> WifiLight DMX4ALL RGBW <IP>:<Port> <Kanal>wobei <Port> optional wäre (Standard = 10001) und
Kanal ebenfalls optional wäre (Standard =0) und den ersten der 3, bzw. 4 direkt aufeinanderfolgenden DMX-Kanäle angibt.
Sobald ich die Netzwerkproblematik im Griff habe, werde ich mir mal deinen "Bridge-Code" ansehen, vielleicht kann ich dir zuarbeiten ;)
Moin,
sehr interessanter Thread. Ich hatte damals im alten Forum schon mal angefragt ob jemand ein Modul für ein DMX4All USB Adapter geschrieben hat. Hat keiner, jetzt hatte ich mir selber was gestrickt, für meine Zwecke läuft es erst mal. Nach und nach bastel ich weiter an dem Modul wenn ich denn mal Zeit habe. Nun bin ich auch kein Freund vom Programmieren, da hatte ich nach 4 Jahren Studium die Schnautze irgendwie voll von ;-)
Ich nutze DMX für meine Beleuchtung. Finde ich persönlich noch am besten und vor allem am stabilsten. WLAN etc. mag ich persönlich nicht so. Art-Net, ja, habe ich auch (http://www.ulrichradig.de/ (http://www.ulrichradig.de/) sei da empfohlen, da gibt es günstige Art-Net Nodes zum selber Löten). Aber ohne dediziertes Netz hatte ich da so meine Probleme mit der Performance. Daher bin ich bei meiner DMX Verkabelung und dem DMX4All USB Adapter geblieben. So ganz verstehe ich den Sinn von Art-Net auch nicht. Ein Node ist ja noch zu verstehen, das ist ein Gateway von LAN auf DMX, aber das die "Endgeräte" jetzt nur noch LAN Schnittstellen haben und das dann noch als DMX verkauft wird mhhh.
Wie dem auch sei, das klingt hier alles sehr gut, vielleicht bekommt man das auch auf den USB Adapter portiert. Scheint alles ein bisschen professioneller zu sein als mein Gefrickel. Ich kann meine RGB Streifen/Strahler an und aus schalten und die Farbe wählen, reicht erst mal ;-) Ohne irgend welche Anpassungen bei den Farbmischungen. Ich hatte damals ein Modul genommen als Vorlage und das versucht zu verstehen und an zu passen, ist mir auch gelungen, so mehr oder weniger ;-)
Ein paar Anmerkungen noch:
- DMX RGB --> 3 Folgekanäle, ja das ist immer so, ABER, die Reihenfolge nicht, es kann auch GRB oder GRB sein, alles schon gesehen.
- DMX RGB WW, habe ich noch gar nicht so gesehen, aber interessant (Ich habe viele Marke Eigenbau Decoder)
- Die RGB Decoder haben aber oft auf mehr Kanäle als nur 3, damit kann man dann einprogrammierte Fadings starten etc.
- Es gibt übrigens auch Schaltmodule und normale Dimmer für DMX, Dimmer ist klar, 0-255 als Value, bei den SwitchBoards kann das variieren, oft ist es aber so pro Kanal 1 DMX Kanal, und dann 0-128 = aus, 129-255 = an. Viele Eigenbauprojekte nutzen das aber auch effektiver in Form von Binärcodierunge.
- Und Moving Heads sind auch ne feine Sache im Garten ;-)
Gruß
Daniel
Hallo Daniel,
habe mir mal deine Module durchgeschaut. Hier ein paar Anmerkungen zu deinem Code von 44_DMX.pm:
my $currenttime = TimeNow();
$hash->{CHANGED}[0] = $command_state; # Nicht verstanden was das ist
$hash->{STATE} = $command_state; # Internal State Value
$hash->{READINGS}{state}{TIME} = $currenttime;
$hash->{READINGS}{state}{VAL} = $command_state;
$hash->{READINGS}{rgb}{TIME} = $currenttime;
$hash->{READINGS}{rgb}{VAL} = $rgb;
$hash->{READINGS}{hue}{TIME} = $currenttime;
$hash->{READINGS}{hue}{VAL} = $hue;
$hash->{READINGS}{LastOnRGB}{TIME} = $currenttime;
$hash->{READINGS}{LastOnRGB}{VAL} = $last_on_rgb;
$hash->{READINGS}{LastOnHUE}{TIME} = $currenttime;
$hash->{READINGS}{LastOnHUE}{VAL} = $last_on_hue;
Das solltest du besser ersetzen durch:
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, "state", $command_state);
readingsBulkUpdate($hash, "rgb", $rgb);
readingsBulkUpdate($hash, "hue", $hue);
readingsBulkUpdate($hash, "LastOnRGB", $last_on_rgb);
readingsBulkUpdate($hash, "LastOnHUE", $last_on_hue);
readingsEndUpdate($hash, 1);
Damit kann der User event-on-change-readings, event-on-update-reading, usw. verwenden. Dazu muss in der Initialize-Funktion folgende Zeile geändert werden:
$hash->{AttrList} = "IODev ignore:1,0 do_not_notify:1,0 ".$readingFnAttributes;
Zu den beiden Zeilen:
$modules{DMX}{defptr}{$device_name} = $hash; # Das verstehe ich noch nicht ganz
...
delete($modules{DMX}{defptr}{$name}); # Das verstehe ich noch nicht ganz
Das ist ein Definition-Pointer. In deinem Fall wird der nicht benötigt, da du keine Daten vom DMX4ALLUSB verarbeitest, sondern nur rausschickst. Bei Modulen wie bspw CUL wo eingehende Funk-Telegramme an die richtige Geräte-Definition (bspw. FS20, CUL_HM, ...) dispatched werden, muss es dazu die Geräte-Adresse, welche in den empfangene Daten enthalten ist, zu der entsprechenden Gerätedefinition auflösen können. Dies geschiet über einen Eintrag in $modules{MODULNAME}{defptr}{ADRESSE} = $hash;
Da du aber keine eingehenden Telegramme an die einzelnen DMX-Definitionen zuordnen musst, ist das nicht notwendig.
my $last_on_rgb = $hash->{READINGS}{LastOnRGB}{VAL}; # Dient zum Speichern des letzten rgb on Wertes.
my $last_on_hue = $hash->{READINGS}{LastOnHUE}{VAL}; # Dient zum Speichern des letzten HSV on Wertes.
Bitte hierzu die Funktion ReadingsVal nutzen, da sonst inkonsistente Strukturen erzeugt werden können, falls das Reading noch nicht existiert. Siehe dazu: http://fhem.de/commandref.html#perl
Viele Grüße
Markus
Oh super, vielen Dank. Die Tips werde ich gleich mal umsetzen. "event-on-change-readings, event-on-update-reading" ist genau das, wo ich aufgehört hatte weil ich nicht richtig weiter wusste. Ich vermute mal das ist eventuell auch der Grund weshalb die Aktualisierung über longpoll nicht richtig funktioniert. Da habe ich auch noch so meine Nöte mit. Aber wie gesagt ich hab mich immer sehr gefreut wenn überhaupt irgend etwas funktioniert hat. Letzte Änderung war das mit dem HUE Balken, finde ich persönlich optisch ansprechender als der Colorpicker und vor allem kompatible mit Tablets wo sonst immer die Tastaur aufgeht ;-)
Gruß
Daniel
Ja, du hast die Daten quasi manuell in $hash befüllt. Da zum schluss aber ein Aufruf von DoTrigger($name, undef, 0) gefehlt hat, wurden nie Events für deine Readings erzeugt, somit auch kein longpoll.
Dafür gibt es nun die Reading-Funktionen, damit brauch man sich als Modulentwickler darum nicht mehr kümmern.
mit readingsBeginUpdate, readingsBulkUpdate, readingsEndUpdate kann man mehrere Readings mit einmal setzen. Erst wenn readingsEndUpdate aufgerufen wird, werden die Events getriggert und entsprechende notify's angestoßen. Mit readingsSingleUpdate kann man ein einzelnes Reading setzen und direkt triggern. Bei beiden Varianten werden dann die Attribute event-on-*-reading, usw. beachtet und geprüft ob ein Event tatsächlich getriggert werden muss, oder nicht.
Gruß
Markus
Danke nochmals, ich habe alles angepasst, jetzt funktioniert das Longpoll auch tadellos.
Als nächstes gehe ich die Funkiont "DMX_StateFn($)" an. Nach einem FHEM Restart muss ich nämlich die alte Werte in den Controller Laden, da dieser die aktuellen Werte nach dem Initialisieren verliert. Ich habe nur noch nicht verstanden wieso diese Funktion bei mir so häufig aufgerufen wird bei dem FHEM Start, zumindest wenn ich meiner Logmeldung trauen kann. Aber da steige ich auch noch hinter ;-)
/Daniel
Sorry, dass es von meiner Seite aus zwischendurch ruhig war. Aktueller Stand:
- Man braucht das DMX4ALL ArtNet (!!!) und schon geht alles perfekt - hier ein großer Dank an den exzellenten Service dieser Firma inkl. schnellen und problemlosen Umtauschs des von mir Kommunikationslaien bestellten LAN-Geräts. Kaum hat man das richtige Gerät klappt es wie am Schnürchen "out-of-the-box".
- Damit passt meine Terrassenbeleuchtung nahtlos an das schon vorhandene LW12 und LD382.
Ja, es gibt noch alles mögliche bei DMX, aber meiner Überzeugung nach ist es dann nichts mehr für FHEM, sondern es bedarf eines gescheiten DMX-Controller.
Da ich in Summe maximal 4 DMX-RGB-Einheiten auf der Terrasse installieren werde, kann ich mir das hinbasteln. Schöner wäre es, wenn man das DMX4ALL-Gerätchen als Bridge wie bei Milight nutzen könnte. Da brauche ich aber noch etwas Support oder viel Zeit um mich da alleine hinein zu knien. Vielleicht kann ich Jörg animieren, mir etwas Starthilfe zu geben ;) es ist gar nicht so einfach Code von anderen netten Menschen zu verinnerlichen :)
Zitat von: ext23 am 13 Februar 2016, 13:11:49
...
Ein paar Anmerkungen noch:
- DMX RGB --> 3 Folgekanäle, ja das ist immer so, ABER, die Reihenfolge nicht, es kann auch GRB oder GRB sein, alles schon gesehen.
- DMX RGB WW, habe ich noch gar nicht so gesehen, aber interessant (Ich habe viele Marke Eigenbau Decoder)
- Die RGB Decoder haben aber oft auf mehr Kanäle als nur 3, damit kann man dann einprogrammierte Fadings starten etc.
- Es gibt übrigens auch Schaltmodule und normale Dimmer für DMX, Dimmer ist klar, 0-255 als Value, bei den SwitchBoards kann das variieren, oft ist es aber so pro Kanal 1 DMX Kanal, und dann 0-128 = aus, 129-255 = an. Viele Eigenbauprojekte nutzen das aber auch effektiver in Form von Binärcodierunge.
- Und Moving Heads sind auch ne feine Sache im Garten ;-)
Gruß
Daniel
Ich habe die letzten Wochen einige Betriebsanleitungen der infrage kommenden Außen-DMX-Geräte angeschaut: alles RGB in dieser Reihenfolge. Es gibt bei Thomann wohl auch RGBW-Geräte. Alles was über die 3 Kanäle hinaus geht mache ich lieber mit FHEM-wifilight, insofern sehe ich keinen Bedarf. Wozu eine im Gerät vorprogrammierte Sequenz anwählen, wenn ich volle Freiheit in den Sequenzen mit FHEM habe? Last but not least: vielleicht kommt der Appetit mit dem Essen, aber derzeit sehe ich keinen Bedarf für moving heads - ganz zu schweigen von dem sicherlich notwendigen Überzeugungsbedarf, schließlich sitze ich ganz gerne MIT meiner Frau auf der Terrasse. ;)
"Man braucht das DMX4ALL ArtNet (!!!) und schon geht alles perfekt" Was hast du denn vorher gehabt? Das verstehe ich nicht so ganz, weil ArtNet ist ein Protokoll was eigentlich gleich sein sollte, egal ob du ein RGB Gerät hast was direkt ArtNet spricht oder du ein Gateway bzw. Node hast.
Was ist jetzt ein "DMX4ALL ArtNet"? Meinst du den STAGE-PROFI? Das wäre dann ein Node ja? Es gibt ArtNet Nodes, das sind quasi die Bindeglieder zwischen LAN und DMX und es gibt eben ArtNet Geräte, da ist das Universum direkt im ja Scheinwerfer oder was auch immer, wobei ich sowas Schwachsinn finde aber gut, da wird sich die ArtNet Gemeinde schon was bei gedacht haben, oder auch nicht oO Aber so ganz warm werd ich mit dem ArtNet Zeugs auch nicht.
"Wozu eine im Gerät vorprogrammierte Sequenz anwählen, wenn ich volle Freiheit in den Sequenzen mit FHEM habe?"
Hast du die?!?!? Also mein FHEM würde ganz schön kotzen wenn ich da vernünftige Fadings etc. mache. Da geht ja dann nichts anderes mehr bzw. ruckelt es nachher beim Faden weil gerade einer was aufm Funk macht. Funktioniert das wirklich so sauber? Muss ich dann mal ausprobieren mit meinem Node.
/Daniel
Ach ich sehe gerade im ersten Thread, du hattest den LAN-to-DMX Adapter, ja ok das ist natürlich was anderes, das hat nichts mit ArtNet zu tun.
/Daniel
DMX4 All hat 2 äußerlich gleiche Teile:
Den LAN-DMX Stage-Profi und den ArtNet-DMX STAGE-PROFI 1.1
Ich hatte den ersteren - das ist aber ein ganz spezielles Teil, welches nur unter Windows mit ganz speziellen Treibern funktioniert und am Standard-LAN, welches man so zu Hause mit der FritzBox aufspannt, eben nicht tut. Das andere heißt zwar ArtNet, ist aber einfach nur eine Brücke zwischen dem 0815-Lan zu Hause und dem DMX. Links ein RJ45 - rechts ein XLR- fertig.
Ansonsten hast du natürlich recht: Über FHEM kann man keine professionelle Lightshow fahren, das will ich aber auch gar nicht. Aber ich will auch keine Sequenzen in meinen DMX-Komponenten programmieren. Ich will einfach ganz bequem eine Farbe, eine Helligkeit und eine Sättigung anwählen. Und wenn ich eine andere will, soll es halt in mehr oder wenigen Sekunden weich wechseln. Das kann FHEM, wobei man durchaus mal ein Ruckeln feststellen kann, wenn auch sonst einiges läuft. In meiner Testumgebung ruckelt nichts, in meinem Livesystem manchmal schon. Nur ist ein Übergang bei mir die absolute Ausnahme. Es kommt darauf an, was man benötigt.
Zitat von: ujaudio am 22 Februar 2016, 21:44:36
das ist aber ein ganz spezielles Teil, welches nur unter Windows mit ganz speziellen Treibern funktioniert und am Standard-LAN, welches man so zu Hause mit der FritzBox aufspannt, eben nicht tut.
Mhh doch doch, das geht eigentlich schon. Das Teil ist doch dasselbe wie mein USB Adapter, dieser LAN Adapter arbeitet doch mit einem VCP Treiber, wenn es dasselbe Teil ist wie sie damals schon mal hatten. Ist halt immer etwas gefrickel mit diesen Virtuellen COM Ports. Aber ist eben kein ArtNet, ob es nun einfacher ist von der Ansteuerung her, mhh da kann man sich streiten ja ;-)
Das mit FHEM und Fading probiere ich mal aus, würde für mich auch reichen, eventuell, ich kenne jetzt das Modul nicht was da so geht.
Bei einem Kollegen wird das aber nichts mehr über FHEM ;-) Der hat 35 Strahler um sein Haus. Wenn da einer klingelt geht da ne Lightshow los. Er nutzt ein Pult mit welchem man die Szenen seriell (RS232) abrufen kann. Museumsreif aber tut was es soll :-) Das erinnert mich so ein bissel an die Allianz Arena, wenn der Fußball schauen weiß man gleich wem er die Daumen drückt... aber gut das wird jetzt off topic...
/Daniel
Ich habe nun für mich anhand des WifiLight ein Modul "DMX4all" gebaut. So primitiv wie möglich erst einmal, es kann nur Kanal 1-3 für R, G und B aber tut für meine Zwecke perfekt und ich kann dennoch das normale Update für FHEM inklusive WifiLight fahren. Der Code ist natürlich zu 99,9% von WifiLight.
Jetzt werde ich mich mal an weiteren Kanälen versuchen um auf über Kanal 4-6 ein weiteres DMX-Gerät unabhängig zu steuern - ist halt die gleiche IP-Adresse, muss wohl so ähnlich wie die Bridge funktionieren.