Wifilight.pm

[daniel2311]

Code Auswählen Erweitern

if (!$ledDevice->{helper}->{SOCKET} || ($ledDevice->{helper}->{SELECT}->can_read(0.0001) && !$ledDevice->{helper}->{SOCKET}->recv(my $data, 512)))

Warum !Socket || er kann lesen && nicht empfangen?

Ist der Ausdruck nicht irgendwie falsch? Warum ein und? Wie wertet Perl denn das can_read aus? Laut Doku gibt es ein array of handles aus.

can_read ( [ TIMEOUT ] )
Return an array of handles that are ready for reading. TIMEOUT is the maximum amount of time to wait before returning an empty list, in seconds, possibly fractional. If TIMEOUT is not given and any handles are registered then the call will block.

[herrmannj]

weil diese Konstruktion wahr wird wenn das UFO die Verbindung beendet.

!socket ist klar, der socket ist undef.

can_read true aber nix kommt an bedeutet es gab was (das fin), aber recv liefert eben kein fin sondern null bytes.

Dahinter müsste jetzt shutdown(2) und close vor dem neuaufbau kommen.
http://www.perlmonks.org/?node=108244

[daniel2311]

nee, das fin sollte auf OSI-Ebene 4 stattfinden. Also innerhalb des TCP-Protokolls. Der TCP-Stack wird vom Betriebssystem abgefrühstückt, wenn natürlich aber auch das Beenden der Verbindung aus einem shutdown bzw. einem close ausgelöst wird. Was du in Perl nur noch rausbekommst, sind alle Schichten darüber. Sprich das fin kannst gar nicht bekommen, weil das nicht einmal Perl mitbekommt und hat somit auch nichts mit dem can_read zu tun.

Vllt. noch mal anders erklärt, was aus meiner Sicht passiert - und vllt OS oder Kommnikationstechnisch falsch, weil ich da ein falsches Verständnis von habe:
Wenn du aus deiner Applikation eine TCP-Verbindung aufmachst, dann sagst du dem Betriebssystem mache eine Socket Verbindung zu einem Server auf - zumindest in diesem Fall. Der TCP-Stack des Betriebsystems macht zuerst ein 3-Wege-Handshake. Schickt ein Syn, bekommt hoffentlich ein Syn-Ack vom Server zurück (ebenfalls TCP-Stack des anderen Betriebsystems) und beantwortet das mit einem Ack ebenfalls vom OS.
Jetzt hast du eine Verbindung und erst jetzt schickst du deine Anwendungsdaten über die Leitung. Ebenfalls in TCP-Paketen gestückelt - wie groß die aber sind usw. entscheidest auch nicht du in der Anwendung, sondern alles okay.
Jetzt löst irgendetwas im OS, Perl, FHEM oder dem Modul (wobei ich das Modul ausschließen würde, weil dann müsstest du ein close oder shutdown machen, Betriebssystem scheidet auch aus, weil das entscheidet nicht, ob was geschlossen wird und würde dann nicht auf Closed_Wait stehen) aus, lieber Socket alles in Ordnung, ich bin fertig mit dem Schreiben. Ich brauch die Verbindung nicht mehr. Das löst im Betriebssystem dann aus, dass dieses auf TCP-Ebene das FIN,Ack sendet, worauf der Server Socket antwortet mit Ack, also super habe verstanden, dass du den Port nicht mehr benötigst. Der Server kann jetzt also nicht mehr auf diesem Kommunikationspunkt reden, weil er ja geschlossen wurde. Das Betriebssystem stellt sich in das Closed_wait, denn der Kommunikationspunkt von der Anwendung ist noch nicht geschlossen, aber die Verbindung zum Server ist schon abgebaut.
Jetzt schickst du aus der Anwendung wieder Daten an diesen Socket an den Kommunikationspunkt der Anwendung. Der schickt die Daten auch gehorsam raus, worauf der allerdings der TCP-Stack des Server sagt, netter Versuch, dass du mir hier Daten schicken möchtest, aber da ich kein Kommunikationspunkt oder Socket offen habe, kann ich die Daten an niemanden schicken, der sie liest und antwortet mit ein RST, ACK, was allerdings erstmal scheinbar ignoriert wird, bis dann auch dieses auf das RST antwortet und es bestätigt, es kann nicht mehr auf dem Port kommuniziert werden und dann leider erst im Modul mit einem schließen des Sockets und einem Neu-Öffnen gelöst wird.
Ich haue mal bei mir ein paar Debug-Ausgaben rein. Mal gucken, was wirklich zurückgeliefert wird.

Mit dem || und dem && komme ich von der Logik noch nicht ganz klar, aber das werde ich mir dann auch angucken - da habe ich manchmal ein Brett vorm Kopf - aber nicht mehr heute. Ist schon spät

[daniel2311]

Also ich konnte es doch nicht lassen. Ich habe mal die WifiLight_LowLevelCmdQueue_Send ein wenig verändert.
Ab Zeile 3935

Code Auswählen Erweitern

# TCP
  if ($ledDevice->{PROTO})
  {

my $socket = $ledDevice->{helper}->{SOCKET};
my $canRead = $ledDevice->{helper}->{SELECT}->can_read(0.0001);
my $data = "no data";
my $recvState = undef;
if ($socket) {
my $recvState = $ledDevice->{helper}->{SOCKET}->recv($data, 512);
}
if ($ledDevice->{NAME} eq "LED_FLUR") {
my $nestat = `netstat -nao | find "10.23.11.16"`;
dump("----------start----------");
dump(localtime(time));
dump("socket:");
dump($socket);
dump("canRead:");
dump($canRead);
dump("recvState:");
dump($recvState);
dump("data:");
dump($data);
dump("netstat:");
dump($nestat);
if ($socket) {
dump("socket true");
}
if ($canRead) {
dump("canRead true");
}
if ($recvState) {
dump("recvState true");
}
dump(localtime(time));
dump("----------end----------");
}
    if (!$socket || ($canRead && !$recvState))
    {
      Log3 ($ledDevice, 4, "$ledDevice->{NAME} low level cmd queue send $dbgStr, qlen ".@{$ledDevice->{helper}->{llCmdQueue}}." connection refused: trying to reconnect");


Hier das Ergebnis des Logs, welches mich mehr als verwundert.
Hier die letzte erfolgreiche Verbindung:

Code Auswählen Erweitern

"----------start----------"
(46, 55, 23, 15, 4, 117, 1, 134, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => undef,
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
undef
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:60818      10.23.11.16:5577       HERGESTELLT     5960\n"
"socket true"
(46, 55, 23, 15, 4, 117, 1, 134, 1)
"----------end----------"

Hier die erste, die fehlschlägt und man beachte, dass socket_peername gesetzt ist. Das hätte ich gedacht wird nur bei einer erfolgreichen Verbindung gemacht - oder sie wird nicht richtig wieder abgebaut und edeshalb steht er noch drin? Noch verwunderlicher canRead liefert 1 zurück und nicht mehr undef:

Code Auswählen Erweitern

"----------start----------"
(27, 2, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => "\2\0\25\xC9\n\27\13\20\0\0\0\0\0\0\0\0",
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
1
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:60818      10.23.11.16:5577       SCHLIESSEN_WARTEN    5960\n"
"socket true"
"canRead true"
(27, 2, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"

Anschließend der neue Socket - hier 2 mal. Wie man beim netstat sieht. Zwei Sockets. Einer auf "ZULETZT_ACK", was irgendwie heißt, Verbindung ist getrennt bzw. hat ein FIN aber muss noch abgeräumt werden, aber auch der neue Port 63907.

Code Auswählen Erweitern

"----------start----------"
(51, 2, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => undef,
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
undef
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:60818      10.23.11.16:5577       ZULETZT_ACK     5960\n  TCP    10.23.11.10:63907      10.23.11.16:5577       HERGESTELLT     5960\n"
"socket true"
(51, 2, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"
"----------start----------"
(52, 2, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => undef,
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
undef
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:60818      10.23.11.16:5577       ZULETZT_ACK     5960\n  TCP    10.23.11.10:63907      10.23.11.16:5577       HERGESTELLT     5960\n"
"socket true"
(52, 2, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"

Noch mal 2 min später dann, ist die vorherige Verbindung auch laut Windows wirklich geschlossen:

Code Auswählen Erweitern

"----------start----------"
(22, 4, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => undef,
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
undef
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:63907      10.23.11.16:5577       HERGESTELLT     5960\n"
"socket true"
(22, 4, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"

Würde verrücktweise heißen, wenn canRead 1 zurück gibt (bzw, wie laut Doku ein Handle?) und der Socket da ist, dann müsste man neu Verbinden? xD Seltsam würde ich das finden, aber das würde da jetzt stehen. So sagt es zumindest die Wireshark Analyse. Ich muss zugeben, dass ich immer noch nicht prüfen konnte, ob das Licht wirklich nicht an oder ausgeht.

Das wird noch mal der nächste Schritt.

[herrmannj]

Mit dem || und dem && komme ich von der Logik noch nicht ganz klar, aber das werde ich mir dann auch angucken - da habe ich manchmal ein Brett vorm Kopf - aber nicht mehr heute. Ist schon spät

anders erklärt.

Wenn der can_read meldet das es etwas zu lesen gibt und (&&) der read 0 bytes zurückgibt ist der Socket (auf der anderen Seite) geschlossen.

[daniel2311]

Jupp, ich habe es jetzt auch verstanden. Die Debugausgaben zeigen ja auch das true usw., womit ich wieder klar bin, vorallem mit der Klammer, die ich ignoriert habe.

Ich bin auf eine andere LED-Leiste gestern Nacht noch umgestiegen, die ich vom Büro aus sehen kann und habe das Verbose auf 5 gestellt.
Hier mal das Log bei beim Ausschalten.

Code Auswählen Erweitern

2017.05.16 02:51:57 3: LED_Wohnzimmer_Durchreiche RGBW LD382A set off 0
2017.05.16 02:51:57 3: LED_Wohnzimmer_Durchreiche RGBW LD382A dim 0 0
2017.05.16 02:51:57 5: LED_Wohnzimmer_Durchreiche prepare start hsv transition (is actual) hsv 180, 100, 100, 1494895917.14203
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche current HSV 180, 100, 100
2017.05.16 02:51:57 3: LED_Wohnzimmer_Durchreiche set HSV 180, 100, 0 with ramp: 0, flags:
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche hsv transition without ramp routed to direct settings, hsv 180, 100, 0
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche high level cmd queue add hsv/ctrl 180, 100, 0, ctrl , targetTime 1494895917.14203, qlen 1
2017.05.16 02:51:57 5: LED_Wohnzimmer_Durchreiche high level cmd queue exec dropper delay: -0.000456809997558594
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche high level cmd queue exec hsv 180, 100, 0, delay 100, hl qlen 1, ll qlen 0, lock 0
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche RGBW LD382A set h:180, s:100, v:0
2017.05.16 02:51:57 5: LED_Wohnzimmer_Durchreiche low level cmd queue add 3100000000000f40, qlen 1
2017.05.16 02:51:57 5: LED_Wohnzimmer_Durchreiche low level cmd queue qlen 1, send 3100000000000f40
"----------start----------"
(57, 51, 2, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => "\2\0\25\xC9\n\27\13R\0\0\0\0\0\0\0\0",
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
1
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:62331      10.23.11.82:5577       SCHLIESSEN_WARTEN    6340\n"
"socket true"
"canRead true"
(57, 51, 2, 16, 4, 117, 2, 135, 1)
"----------end----------"
"**************reconnect*******************"
2017.05.16 02:51:57 4: LED_Wohnzimmer_Durchreiche low level cmd queue send 3100000000000f40, qlen 1 connection refused: trying to reconnect
2017.05.16 02:51:58 3: LED_Wohnzimmer_Durchreiche low level cmd queue send ERROR 3100000000000f40, qlen 1 (reconnect giving up)
2017.05.16 02:51:58 5: LED_Wohnzimmer_Durchreiche low level cmd queue add 00, qlen 2
2017.05.16 02:51:58 4: LED_Wohnzimmer_Durchreiche high level cmd queue ask next 1494895918.48926
2017.05.16 02:51:58 5: LED_Wohnzimmer_Durchreiche | LED_Wohnzimmer_Durchreiche unlock queue 0

Hier dann mal ein funktionierendes Reconnect - und was auffällt, die Queue ist noch gefüllt. bzw. irgendwas sendet ein zweites mal ein "an"?

Code Auswählen Erweitern

2017.05.16 00:49:34 5: LED_Wohnzimmer_Durchreiche low level cmd queue add 71230fa3, qlen 1
2017.05.16 00:49:34 5: LED_Wohnzimmer_Durchreiche low level cmd queue qlen 1, send 71230fa3
"----------start----------"
(35, 49, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => "\2\0\25\xC9\n\27\13R\0\0\0\0\0\0\0\0",
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
1
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:59042      10.23.11.82:5577       SCHLIESSEN_WARTEN    6340\n"
"socket true"
"canRead true"
(35, 49, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"
"**************reconnect*******************"
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche low level cmd queue send 71230fa3, qlen 1 connection refused: trying to reconnect
2017.05.16 00:49:35 3: LED_Wohnzimmer_Durchreiche RGBW LD382A set on (180, 100, 100) 0
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche prepare start hsv transition (is actual) hsv 180, 100, 0, 1494888575.27866
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche current HSV 180, 100, 0
2017.05.16 00:49:35 3: LED_Wohnzimmer_Durchreiche set HSV 180, 100, 100 with ramp: 0, flags:
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche hsv transition without ramp routed to direct settings, hsv 180, 100, 100
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche high level cmd queue add hsv/ctrl 180, 100, 100, ctrl , targetTime 1494888575.27866, qlen 1
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche high level cmd queue exec dropper delay: -0.000488996505737305
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche high level cmd queue exec hsv 180, 100, 100, delay 100, hl qlen 1, ll qlen 1, lock 0
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche RGBW LD382A set h:180, s:100, v:100
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche low level cmd queue add 3100ff9500000fd4, qlen 2
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche low level cmd queue add 00, qlen 3
2017.05.16 00:49:35 4: LED_Wohnzimmer_Durchreiche high level cmd queue ask next 1494888575.38623
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche low level cmd queue qlen 2, send 3100ff9500000fd4
"----------start----------"
(35, 49, 0, 16, 4, 117, 2, 135, 1)
"socket:"
do {
  require Symbol;
  my $a = bless(Symbol::gensym(), "IO::Socket::INET");
  *{$a} = {
    io_sock_nonblocking => 1,
    io_socket_domain    => 2,
    io_socket_peername  => undef,
    io_socket_proto     => 6,
    io_socket_timeout   => 1,
    io_socket_type      => 1,
  };
  $a;
}
"canRead:"
undef
"recvState:"
undef
"data:"
""
"netstat:"
"  TCP    10.23.11.10:59042      10.23.11.82:5577       ZULETZT_ACK     6340\n  TCP    10.23.11.10:62331      10.23.11.82:5577       HERGESTELLT     6340\n"
"socket true"
(35, 49, 0, 16, 4, 117, 2, 135, 1)
"----------end----------"
2017.05.16 00:49:35 5: LED_Wohnzimmer_Durchreiche | LED_Wohnzimmer_Durchreiche unlock queue 0

[t1me2die]

Moin liebe Leute, auch ich habe ab und zu dieses Problem, dass das Ufo die Schaltung nicht ausführt und im Log ein Error erscheint:

Code Auswählen Erweitern


low level cmd queue send ERROR 3100000000000f40, qlen 1 (reconnect giving up)


Wäre es nicht möglich, dass das Modul diesen ERROR als Reading weg schreibt?
Mir ist auch aufgefallen, dass trotz des ERROR's der state von dem Device auf "on" springt.

Gruß
Mathias

[daniel2311]

Hi Mathias,

das habe ich ja gerade versucht. Ich kann allerdings nicht bestätigen, dass in den meisten Fällen der Status richtig umgesetzt wird, wenn so eine Info kommt:

Code Auswählen Erweitern

low level cmd queue send ERROR 3100000000000f40, qlen 1 (reconnect giving up)
Hier schmeißt er einfach die alte Connection weg, erzeugt eine neue und dann sollte es weiter gehen. Aber so ganz verstehen, tu ich es trotzdem nicht.
Was ich auch noch nicht geschaut habe, ob es noch eine Rückmeldung vom Gerät gibt, die etwas bestätigt und man ggf. auswerten könnte.

Ich hatte gestern allerdings noch einen anderen Fall. Den muss ich aber noch mal zusammenschreiben, wo alles anders lief. Ganz seltsame Kombiation.

[ChrisW]

da hier a einige LED Experten unterwegs sind. Für meine Mieter muss ich den LW12 gegen irgendwas einfaches austauschen
IR mit Ferbedihnung und Netzteil so günstig wie möglich. Jemand zufällig was gesehen ? Bei Ebay gibt es nur Kombis .
Wollt das auf die schnelle gegen was einfaches günstiges tauschen
Danke

[Michi1978]

Hallo, habe heute morgen bemerkt das ich das gkeiche Problem habe wie du. Würdest du mir die Zeile mit dem DOIF.zukommen lassen weil das würde ich bei mir auch gerne einbauen

Moin,

ich habe den LD382A nun seit einer Woche, weil mir die Milight Bridge so langsam den Nerv raubt wg der recht häufigen Unzuverlässigkeit.
Ich hoffte mit dem LD382A das Problem zu umgehen, komme aber offenbar vom Regen in die Traufe, denn ich habe genau das von Octopyrox angesprochene Problem nun auch :-/

blofiled

[daniel2311]

Hallo, habe heute morgen bemerkt das ich das gkeiche Problem habe wie du. Würdest du mir die Zeile mit dem DOIF.zukommen lassen weil das würde ich bei mir auch gerne einbauen

Ich habe das Doif zwar nicht, aber letztlich ist das das Problem, was ich in meinen vorherigen Theads schrieb. Ich habe es zwar noch nicht ausprobiert, aber ich denke, wenn du in den Attributen die defaultRamp auf 1 setzt oder auf 0.5... dann müsste er nämlich mehrere Befehle in die Queue hauen und damit könnte es schon gelöst sein.

[Bensen9]

Hallo alle,
Ich lese nun schon seit etwa 3 tagen hier aber kann mein Problem weder finden noch lösen. Ich habe einen LD382 controller für RGBW strips. Mit der MagicHomer App geht alles aber die Implementierung in FHEM bereite mir Schwierigkeiten.

Egal wie ich das Gerät definiere (mit oder ohne A, ich nutze nur die IP) startet mein FHEM nicht mehr. In meiner LOG finde ich das folgende:

2017.06.05 13:56:08 1: Including fhem.cfg
2017.06.05 13:56:08 1: Including fhem_fhemweb.cfg
2017.06.05 13:56:08 1: Including fhem_light.cfg
2017.06.05 13:56:08 1: PERL WARNING: Using a hash as a reference is deprecated at /Library/Perl/5.18/Net/DAAP/DMAP.pm line 340, <$fh> line 36.
2017.06.05 13:56:08 1: Including fhem_weather.cfg
2017.06.05 13:56:08 1: Including ./log/fhem.save
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /System/Library/Perl/5.18/darwin-thread-multi-2level/Socket.pm line 827.

Nach dem letzten Eintrag tut sich nichts mehr. Wenn ich das "define" wieder aus der CFG nehme started alles normal.

Ein update von FHEM has ich schon gemacht ohne Lösung. Zudem scheint es nichts mit dem Device selbst zu tun zu haben. Denn wenn ich dieses aus mache (stecken ziehe) verhält sich FHEM genauso.

Stimmt da was nicht mit meinem PERL oder FHEM?
Der server läuft auf einem OSX.

Danke für jede Hilfe. Viele Grüsse Ben

[herrmannj]

noch nie gehört. Schalte mal stacktrace ein ob man da mehr sieht.

vg
joerg

[daniel2311]

Schaut mal hier:
https://forum.fhem.de/index.php/topic,53406.15.html
Kann es am define liegen? Wie sieht das aus? Ist die IP-Adresse nicht korrekt?

[maddinthebrain]

Hallo zusammen,

bei mir funzt das mit dem ColorCast leider auch nicht. Wurde das schon behoben?

Leider bräuchte ich dann aber eine Version die den LD686 unterstützt.

Grüße Maddin