FHEM-CVS: Unterscheidung CUL_WS-Geräte anhand des IODev? (CUL868 vs. CUL433)
Kai 'wusel' Siering
auf, um das Ding demn�chst produktiv zu nehmen, und dann das ;)
fhem> list CUL_WS_8
Internals:
CODE 8
CUL433_MSGCNT 7
CUL433_RAWMSG K7538130000F
CUL433_TIME 2010-01-07 09:51:51
DEF 8
IODev CUL433
LASTIODev CUL433
MSGCNT 7
NAME CUL_WS_8
NR 68
STATE B: 3870
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2010-01-07 09:51:51 DEVFAMILY WS7000
2010-01-07 09:51:51 DEVTYPE Brightness
2010-01-07 09:51:51 state B: 3870
Attributes:
room CUL_WS
Ich wollte dies grade umbenennen in "Keller_TH", wie in der bisherigen
Config, ...
FHZ> list Keller_TH
Internals:
CODE 8
DEF 8
IODev CUL1
NAME Keller_TH
NR 26
RAWMSG K718061380E
RSSI -67
STATE T: 18 H: 38.6
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2010-01-07 12:38:36 DEVFAMILY WS300
2010-01-07 12:38:36 DEVTYPE PS50
2010-01-07 12:38:36 state T: 18 H: 38.6
Attributes:
IODev CUL1
model S300
room Keller
... und frage mich nun, wie ich diese beiden Ger�te in der aktuellen
FHEM-Version (CVS) unterscheiden kann? Noch immer mit IODev? Denn in
meinem CVS-FHEM haben alle Ger�te offensichtlich CUL433 als IODev:
fhem> list CUL_WS_5
Internals:
CODE 5
CUL_MSGCNT 78
CUL_RAWMSG K41260253F1
CUL_RSSI -81.5
CUL_TIME 2010-01-07 12:27:00
DEF 5
IODev CUL433
LASTIODev CUL
MSGCNT 78
NAME CUL_WS_5
NR 59
STATE T: 22.6 H: 53
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2010-01-07 12:27:00 DEVFAMILY WS300
2010-01-07 12:27:00 DEVTYPE S300TH
2010-01-07 12:27:00 state T: 22.6 H: 53
Attributes:
room CUL_WS
Klar, ich habe CUL433 zuletzt definiert und auch nicht gro� nach-
gedacht, war ja nur'n Test ;) IODev-unabh�ngiger Empfang klappt also
(nur Senden d�rfte mit der Konfiguration wohl m��ig sein, daf�r wird
IODev noch genommen, oder?) -- wie nagele ich jetzt CUL_WS-Ger�te
auf einen Empf�nger fest?
kai
Kai 'wusel' Siering
f�hre mich wer aus dem perl-Dschungel ;)
[...]
> ... und frage mich nun, wie ich diese beiden Ger�te in der aktuellen
> FHEM-Version (CVS) unterscheiden kann? Noch immer mit IODev? Denn in
> meinem CVS-FHEM haben alle Ger�te offensichtlich CUL433 als IODev:
[...]
Use the Source & Mut zur L�cke:
fhem> rename CUL_WS_8 CUL433.8
root@plug-2:~# more /var/log/fhem/CUL433.8-2010.log
2010-01-05_11:23:57 CUL_WS_8 B: 4010
2010-01-05_12:32:12 CUL_WS_8 B: 2970
2010-01-05_13:48:20 CUL_WS_8 B: 3420
2010-01-05_14:27:43 CUL_WS_8 B: 4010
2010-01-05_14:40:50 CUL_WS_8 B: 4020
2010-01-06_10:45:47 CUL_WS_8 B: 3560
2010-01-06_11:01:32 CUL_WS_8 B: 4010
2010-01-06_11:19:54 CUL_WS_8 B: 4010
2010-01-06_14:10:32 CUL_WS_8 B: 4020
2010-01-06_15:08:17 CUL_WS_8 B: 3440
2010-01-06_15:13:32 CUL_WS_8 B: 3590
2010-01-06_15:50:17 CUL_WS_8 B: 113
2010-01-07_08:48:51 CUL_WS_8 B: 57
2010-01-07_09:46:36 CUL_WS_8 B: 3130
2010-01-07_09:51:51 CUL_WS_8 B: 3870
2010-01-07_15:33:07 CUL433.8 B: 51
2010-01-07_15:54:07 CUL433.8 B: 54
Sofern ich das richtig verstehe, setzt der aktuelle Code in 14_CUL_WS.pm
voraus, da� ein CUL_WS-Ger�t entweder <Name_des_CUL_Devices>.<ID_des_CUL_-
WS-Ger�tes> hei�t oder ... da� ein Device mit der ID $cde definiert ist?
# There are only 8 S300 devices. In order to enable more, we try to look up
# the name in connection with the receiver's name ("CUL868.1", "CUL433.1")
# See attr <name> IODev XX
my $def = $modules{CUL_WS}{defptr}{$hash->{NAME} . "." . $cde};
$def = $modules{CUL_WS}{defptr}{$cde} if(!$def);
if(!$def) {
Log 1, "CUL_WS UNDEFINED $type sensor detected, code $cde";
return "UNDEFINED CUL_WS_$cde CUL_WS $cde";
}
$hash ist an der Stelle noch ein Pointer auf das LastIODev, also der
CUL, �ber den's reinkam? Wenn ich aber nun zwei Ger�te mit z. B.
ID 8 definiere und ein Sensor mit dieser ID sich meldet, keine der
Definitionen aber <CULNAME>.8 lautet -- welchen Wert hat dann
$modules{CUL_WS}{defptr}{$cde} ($cde ist 8)?
Sprich, in fhem.cfg:
define S2500 CUL_WS 8
attr CUL_WS IODev CUL433
define S300TH_Keller CUL_WS 8
attr CUL_WS IODev CUL
Jetzt meldet sich der S2500 (Brightness), ID 8, via CUL433. Welcher
Definition eines CUL_WS-Ger�tes mit der ID 8 wird das zugeschlagen?
(Hmm, wenn ich das richtig im CUL_WS_Define() sehe, �berschreibt die
sp�tere ID 8 die fr�here 8.)
Nachdem IODev-unabh�ngiger Empfang nun implementiert ist, w�rde statt
des Namenshacks nicht sinnvoller eine Abfrage $hash->{NAME} (Name des
IODev, �ber den die Nachricht reinkommt?) auf den vorgesehenen IODev
Sinn machen? Allerdings werden die CUL_WS-Ger�te nur anhand ihres
Codes in den Hash gepackt ...
$modules{CUL_WS}{defptr}{$a[2]} = $hash;
... dies m��te entsprechend in CUL_WS_Define() erweitert werden. Z. B. mit
$modules{CUL_WS}{defptr}{$a[2]} = $hash;
AssignIoPort($hash);
umgeschrieben in
AssignIoPort($hash);
$modules{CUL_WS}{defptr}{$hash->{IODev}. "." . $a[2]} = $hash;
Bin ich soweit auf dem richtigen Weg oder verrenne ich mich grade? Ich
verstehe n�mlich ehrlich gesagt grade nicht mehr, wieso
my $def = $modules{CUL_WS}{defptr}{$hash->{NAME} . "." . $cde};
�berhaupt funktioniert derzeit ...
kai
Rudolf Koenig
> FHEM-Version (CVS) unterscheiden kann? Noch immer mit IODev? Denn in
> meinem CVS-FHEM haben alle Ger�te offensichtlich CUL433 als IODev:
CUL_WS.pm reagiert auf "attr IODev" zusaetzlich, und kann damit Geraete mit dem
gleichen ID auseinanderhalten. Deswegen kann man 433-er und 868-er Geraete
(theoretisch?) parallel betreiben.
Axel wollte eine zusaetzliche Unterscheidung anhand des RSSI einbauen. Ich
halte nicht soviel davon, da das RSSI alleine durch drehen der Sender /
Empfaenger stark schwanken kann, aber auch wenn ein Koerper (Mensch/Katze)
zwischen den beiden Geraeten liegt.
Kai 'wusel' Siering
>> ... und frage mich nun, wie ich diese beiden Ger�te in der aktuellen
>> FHEM-Version (CVS) unterscheiden kann? Noch immer mit IODev? Denn in
>> meinem CVS-FHEM haben alle Ger�te offensichtlich CUL433 als IODev:
>
> CUL_WS.pm reagiert auf "attr IODev" zusaetzlich, und kann damit Geraete mit dem
> gleichen ID auseinanderhalten. Deswegen kann man 433-er und 868-er Geraete
> (theoretisch?) parallel betreiben.
Soweit bin ich bei Dir, nur _*WIE*_? (sorry for kreisching ;))
.
.
.
Argl. Zu lange darin verbissen ... Suche nach "defptr" (warum komme ich da
erst jetzt drauf?) in 14_CUL_WS.pm ergibt ...
247 sub
248 CUL_WS_Attr(@)
249 {
250 my @a = @_;
251
252 # Make possible to use the same code for different logical devices when they
253 # are received through different physical devices.
254 return if($a[0] ne "set" || $a[2] ne "IODev");
255 my $hash = $defs{$a[1]};
256 my $iohash = $defs{$a[3]};
257 my $cde = $hash->{CODE};
258 delete($modules{CUL_WS}{defptr}{$cde});
259 $modules{CUL_WS}{defptr}{$iohash->{NAME} . "." . $cde} = $hash;
260 return undef;
261 }
B�ses Foul, da kann ich mir im CUL_WS_Define ja die Augen ausgucken ;)
Aber ja, klar, ist der logische Platz ... *patsch*
Done: "rename CUL433.8 Brigthness"; mal gucken, ob dann morgen da wieder
neue Werte drin stehen oder es ein neue Device gibt ;)
Im Wiki sollte dann stehen etwas in der Art, da� f�r CUL_WS-Ger�te mit
gleicher ID dringend auf das Setzen des richtige IODev-Attributes zu
achten ist, dann sollte es auch zumindest mit 433- und 868-MHz-Ger�ten
parallel klappen. (868 parallel nur, wenn ein wechselseitiger Empfang
ausgeschlossen ist!)
> Axel wollte eine zusaetzliche Unterscheidung anhand des RSSI einbauen. Ich
> halte nicht soviel davon, da das RSSI alleine durch drehen der Sender /
> Empfaenger stark schwanken kann, aber auch wenn ein Koerper (Mensch/Katze)
> zwischen den beiden Geraeten liegt.
Davon halte ich auch nix; dann m��te das schon mit weichen Ober- und Unter-
grenzen definiert werden, ich halte das f�r eine extrem-extreme Kr�cke. Sch�n
billig sind die S555TH/S300TH ja, aber wenn 8 nicht reichen, gibt es mit den,
deutlich teureren, HMS100TF doch unbegrenzte Erweiterungsm�glichkeiten ...
Was n�tzen denn Temperaturwerte von vermeintlich einem Sensor, wenn diese durch
Werte eines anderen verunreinigt werden?
(Ach ja, wenn es doch nur die 433-MHz-Vorl�ufer noch zu kaufen g�be *sigh*)
kai
Axel
# There are only 8 S300 devices. In order to enable more, we try to
look up
# the name in connection with the receiver's name ("CUL868.1",
"CUL433.1")
# See attr <name> IODev XX
CUL_WS kann nur 8 S300/S555TH....
Das hier "CUL868.1" ist reine Namensgebung...
Dann muss dein CUL/CUN CUL868 und/oder CUL433 heissen...
An Hand des IOdev kann's auch nicht unterschieden werden...
Wie soll das Modul denn unterscheiden:
CUL1 empfängt S555TH Kanal 5 => K410822421B
CUL2 empfängt S555TH Kanal 5 => K410822421B
Was heisst das nun ?
Die Meldung kommt von zwei unterschiedlichen Geräten ?
Zweimal die selbe Meldung vom selben Gerät ?
Als IODev wird nur der Name an die ParseFN übergeben.
Damit lässt sich feststelle, das die Meldung von einem CUL kommt.
Der Typ des CUL kann nicht festgestellt werden ?? (@Rudi: noch
nicht ?? ;-)) )
Wenn im IODev-hash CULType=CUL433 oder CUL868 oder CUN stehen
würden...
Dann wären 24 S300TH möglich...
8 * CUL868 + 8 * CUL433 + 8*CUN ;-))
Ich habe für einen Bekannten eine CUL_WS "gebaut", die anhand von RSSI
UND IOdev
aktuelle 16 S300TH sauber "verarbeitet".
Die räumliche Situation machts möglich...
Es gibt dort zwei CUL's, einen "ganz oben" und einen "ganz unten".
Die CUL's überlappen sich im Empfangsbereich...
Er kann aber eindeutig zuorden :
RSSI kleiner 50 = CUL1
RSSI größe 60 CUL2
(so ungefähr)....
Schöne Grüße
Axel
Rudolf Koenig
> nicht ?? ;-)) )
Doch, schon "immer". CUL_WS_Parse: $hash->{VERSION} / Oder list CUL: Version
Axel
tasächlich ;-))
VERSION' => 'V 1.35 CUL868
VERSION' => 'V 1.35 CUL433
VERSION' => 'V 1.35 CUN
Aber..
>Wie soll das Modul denn unterscheiden:
>CUL1 empfängt S555TH Kanal 5 => K410822421B
>CUL2 empfängt S555TH Kanal 5 => K410822421B
Das Problem bleibt dann leider...
Mit den 24 war ich was voreilig ;-))
Schöne Grüße
Axel
Rudolf Koenig
> >CUL2 empf�ngt S555TH Kanal 5 => K410822421B
Ich dachte das sei geklaert, und hat mit dem CUL-Typ/VERSION nichts zu tun,
sondern mit dem Namen, was man dem CUL/CUN in fhem zuweist. Damit ist der
Anzahl der von einem fhem unterscheidbaren CUL_WS "unendlich", solange man es
sicherstellen kann, dass keiner der SxxxTHs von mehr als einem CUL empfangen
werden kann.
Wenn ein gleichzeitiger Empfang doch passieren kann (Normallfall), dann kann
man diesen Feature nicht nutzen (auch Normalfall).
Kai 'wusel' Siering
>>> Wie soll das Modul denn unterscheiden:
>>> CUL1 empf�ngt S555TH Kanal 5 => K410822421B
>>> CUL2 empf�ngt S555TH Kanal 5 => K410822421B
>
> Ich dachte das sei geklaert, und hat mit dem CUL-Typ/VERSION nichts zu tun,
> sondern mit dem Namen, was man dem CUL/CUN in fhem zuweist. Damit ist der
Der Name ist unerheblich. Das Unterscheidungsmerkmal ist IODev des CUL +
Code des CUL_WS-Sensors. Anhand dieser Werte wird der Sensor einem FHEM-
Device zugeordnet ... dachte ich.
Was mir noch nicht klar ist: *wie* wird FHEM-intern das IODev automatisch
besetzt? (Also ohne explizites "attr <def> IODev <iodev>" im .cfg.) Ruft
fhem.pl daf�r die jeweilige _Attr-Routine auf oder klatscht es das intern
in den Hash?
Dies spricht eher f�r letzteres:
fhem> list Parkplatz_TH
Internals:
CODE 4
CUL_MSGCNT 119
CUL_RAWMSG KB12550871D
CUL_RSSI -59.5
CUL_TIME 2010-01-08 10:21:25
DEF 4
IODev CUL433
LASTIODev CUL
MSGCNT 119
NAME Parkplatz_TH
NR 8
STATE T: -2.5 H: 87.5
TYPE CUL_WS
(Keine explizite IODev-Zuweidung in .cfg; Definition von CUL433 folgt der von
CUL => Zuweisung machte FHEM implizit. Die CUL_WS-Magie funktioniert aber nur
bei Aufruf der CUL_WS_Attr()-Routine.)
> Anzahl der von einem fhem unterscheidbaren CUL_WS "unendlich", solange man es
> sicherstellen kann, dass keiner der SxxxTHs von mehr als einem CUL empfangen
> werden kann.
Ack. Ich h�tte also z. B. 1 Slot frei, denn der CUL im OG empf�ngt
seit >1 Woche nicht den S300TH aus dem Keller; andersherum allerdings
empf�ngt der CUL im EG durchaus h�ufiger auch den S300TH au�en vor dem
OG.
> Wenn ein gleichzeitiger Empfang doch passieren kann (Normallfall), dann kann
> man diesen Feature nicht nutzen (auch Normalfall).
Mit einer Mindest-RSSI k�nnte man diese sicher(er) unterscheiden, wie
Axel schon schrieb; wird aber dann haarig f�r autocreate (was eintragen?).
kai
Rudolf Koenig
Ich stehe immer noch zu meine Aussage: NAME der Empfaenger CUL + WS-ID,
falls das IODev Attribut gesetzt wurde. Sonst WS-ID alleine.
Normale CULs haben gar kein IODev. CUL_RFRs schon.
> Was mir noch nicht klar ist: *wie* wird FHEM-intern das IODev automatisch
> besetzt?
AssignIoPort($hash) in CUL_WS_Define. Ich dachte Du hast die 20 Zeilen
ausgiebig studiert :)
Kai 'wusel' Siering
>> Der Name ist unerheblich. Das Unterscheidungsmerkmal ist IODev des CUL +
>
> Ich stehe immer noch zu meine Aussage: NAME der Empfaenger CUL + WS-ID,
> falls das IODev Attribut gesetzt wurde. Sonst WS-ID alleine.
> Normale CULs haben gar kein IODev. CUL_RFRs schon.
H�? Ob CULs ein IODev haben oder nicht, ist doch latte hier.
F�r CUL_WS.pm geht's darum, da�/ob ein IODev f�r die fragliche ID gesetzt
wurde (und dann zeigt IODev eines CUL_WS-Ger�tes auf ein CUL-Ger�t).
>> Was mir noch nicht klar ist: *wie* wird FHEM-intern das IODev automatisch
>> besetzt?
>
> AssignIoPort($hash) in CUL_WS_Define. Ich dachte Du hast die 20 Zeilen
> ausgiebig studiert :)
Ja, CUL_WS.pm schon. Aber:
fhem> list CUL_WS_8
Internals:
CODE 8
CUL_MSGCNT 1
CUL_RAWMSG K7157523155
CUL_RSSI -31.5
CUL_TIME 2010-01-08 10:55:41
DEF 8
IODev CUL433
LASTIODev CUL
MSGCNT 1
NAME CUL_WS_8
NR 1229
STATE T: 25.7 H: 31.5
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2010-01-08 10:55:41 DEVFAMILY WS300
2010-01-08 10:55:41 DEVTYPE PS50
2010-01-08 10:55:41 state T: 25.7 H: 31.5
Attributes:
room CUL_WS
Autogeneriert, als ich ein S555TH auf ID 8 eingeschaltet habe.
CUL_WS_8 hat ein gesetztes IODev-Attribut -- CUL433, der technisch
868-MHz-Sender nicht empfangen kann ;) LASTIODev ist aber CUL.
Sofern *au�erhalb* von CUL_WS.pm keine �nderungen an der Daten-
struktur vorgenommen wurden, d�fte das nicht passieren (beim
Setzen des IODev �ber AttrFN() von CUL_WS w�re die ID "8" durch
"CUL433.8" ersetzt worden).
Mit anderen Worten: das in fhem.pl erfolgende, *implizite* Setzen
des IODev-Attributes, ruft augenscheinlich *nicht* die entsprech-
enden AttrFN() auf. Obwohl also ein IODev-Attribut vorhanden ist,
wurde es in Deinem Sinne nicht *gesetzt*. Damit ist Deine Aussage
richtig -- aber nur die halbe Miete. Denn FHEM hat es ja irgendwie
schon *intern* "gesetzt", sonst w�re es nicht da ;)
Ergo: Erkennung/Zuordnung eines CUL_WS-Ger�tes erfolgt im Regelfall
nur anhand der ID des Ger�tes (1-8). Eine Einschr�nkung des Empfanges
auf ein bestimmtes CUL setzt zwingend die *explizite* Angabe eines
IODev-Attributes voraus, z. B.:
define Brightness CUL_WS 8
attr Brightness IODev CUL433
An der Stelle zwei Punkte:
1. Sollte autocreate nicht statt des letzten definierten das tats�ch-
liche Empfangs-IODev setzen (autocreate hat ja die Info)?
2. Ist dieses Verhalten (gesetztes IODev ohne Aufruf der AttrFN()) ei-
gentlich w�nschenswert bzw. welche Auswirkungen h�tte der Aufruf
der AttrFN()? (F�r Multi-Empfang ja, imho. Ist aber verwirrend, da�
da ein IODev vorhanden ist (list), obwohl es nicht "gesetzt" wurde ...)
Ciao,
kai
Rudolf Koenig
Stimm ich zu, aber Du hast es geschrieben:
"Das Unterscheidungsmerkmal ist IODev des CUL +... "
Kann ich aber gerne ignorieren.
> CUL_WS_8 hat ein gesetztes IODev-Attribut -- CUL433, der technisch
Nope: CUL_WS_8 hat kein IODev _Attribut_, sondern einen IODev Eintrag im hash.
> nur anhand der ID des Ger�tes (1-8). Eine Einschr�nkung des Empfanges
> auf ein bestimmtes CUL setzt zwingend die *explizite* Angabe eines
> IODev-Attributes voraus, z. B.:
Korrekt.
> 1. Sollte autocreate nicht statt des letzten definierten das tats�ch-
> liche Empfangs-IODev setzen (autocreate hat ja die Info)?
Finde ich (inzwischen) nicht. Das IODev unabhaeengige Empfang wurde hier im
Forum laut gefordert, deswegen wurde das alte Verhalten (input nur vom
definierten IODev zu akzeptieren) abgeloest.
> 2. Ist dieses Verhalten (gesetztes IODev ohne Aufruf der AttrFN()) ei-
> gentlich w�nschenswert bzw. welche Auswirkungen h�tte der Aufruf
> der AttrFN()?
IODev ist generell fuer Geraete die senden wollen notwendig. Frueher war das
auch fuer Empfaenger noetig. "attr xxx IODev yyy" ist eigentlich ein Hack, um
den IODev hash Eintrag modifizieren zu koennen, ich wollte kein neues Kommando
dafuer einfuehren. Als Nebeneffekt kann jedes Modul auf das Aendern reagieren.
> Ist aber verwirrend, da� da ein IODev vorhanden ist (list), obwohl es nicht
> "gesetzt" wurde ...
Stimmt, eigentlich sollte man den AssignIoPort Aufruf entfernen koennen.
Kai 'wusel' Siering
>> H�? Ob CULs ein IODev haben oder nicht, ist doch latte hier.
>
> Stimm ich zu, aber Du hast es geschrieben:
> "Das Unterscheidungsmerkmal ist IODev des CUL +... "
> Kann ich aber gerne ignorieren.
Ack, da habe ich mich unklar ausgedr�ckt dann, sorry.
>> CUL_WS_8 hat ein gesetztes IODev-Attribut -- CUL433, der technisch
>
> Nope: CUL_WS_8 hat kein IODev _Attribut_, sondern einen IODev Eintrag im hash.
Oh, stimmt; ich habe bis eben nicht gewu�t, da� es da Unterschiede
gibt. Wieder was �ber die Interna gelernt ;)
>> 1. Sollte autocreate nicht statt des letzten definierten das tats�ch-
>> liche Empfangs-IODev setzen (autocreate hat ja die Info)?
>
> Finde ich (inzwischen) nicht. Das IODev unabhaeengige Empfang wurde hier im
> Forum laut gefordert, deswegen wurde das alte Verhalten (input nur vom
> definierten IODev zu akzeptieren) abgeloest.
Hier sprichst Du vom Attribut, nicht dem Eintrag?
>> 2. Ist dieses Verhalten (gesetztes IODev ohne Aufruf der AttrFN()) ei-
>> gentlich w�nschenswert bzw. welche Auswirkungen h�tte der Aufruf
>> der AttrFN()?
>
> IODev ist generell fuer Geraete die senden wollen notwendig. Frueher war das
> auch fuer Empfaenger noetig. "attr xxx IODev yyy" ist eigentlich ein Hack, um
> den IODev hash Eintrag modifizieren zu koennen, ich wollte kein neues Kommando
> dafuer einfuehren. Als Nebeneffekt kann jedes Modul auf das Aendern reagieren.
Also um den IODev-Hash zu �ndern, gibt es das IODev-Attribut, welches �ber die
jeweilige AttrFN() eben den Hash-Eintrag �ndert?
Nee, das kann nicht sein, CUL_WS_Attr() fa�t nirgends ->{IODev} an. *seufz*
Aha, das macht CommandAttr() als Sonderfall! Mal' doch mal wer 'n Ablauf- und
Interaktionsplan f�r's Wiki ;)
Verstehe ich das dann richtig, da� der IODev-Hash bestimmt, welches Sendede-
vice verwendet wird (und wenn ich f�r 'nen FS20-Schalter da z. B. 'ne WS2000
eintrage, w�rde fhem.pl auch stumpf versuchen, dar�ber das Sendekommando zu
schicken)?
Ein reiner Empf�nger braucht also keinen IODev-Hash (mehr)? Fixiert das expli-
zite Setzen eines IODev-Attributes (und damit des IODev-Hashes) den Empfang
immer ausschlie�lich auf dieses IODev oder ist das modulabh�ngig (IIRC letz-
teres)?
Danke & Ciao,
kai