wifilight für DMX

Begonnen von ujaudio, 22 Januar 2016, 23:44:31

Vorheriges Thema - Nächstes Thema

holzwurm83

Hier war schon jemand fleißig:
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
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

ujaudio

#16
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?
Einen lieben Gruß
Jürgen

herrmannj

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

ujaudio

#18
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.
Einen lieben Gruß
Jürgen

ujaudio

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?
Einen lieben Gruß
Jürgen

herrmannj


ujaudio

#21
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.
Einen lieben Gruß
Jürgen

ujaudio

#22
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).
Einen lieben Gruß
Jürgen

herrmannj

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

herrmannj

würdest Du mir das zukommen lassen ? dann baue ich das ein.

vg
joerg

ujaudio

#25
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  ;)
Einen lieben Gruß
Jürgen

ext23

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/ 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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Markus Bloch

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ext23

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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Markus Bloch

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)