[FHZ] FHEM-CVS: Unterscheidung CUL_WS-Gerte anhand des IODev? (CUL868 vs. CUL433)

[Guest]

Originally posted by: <email address deleted>

Oops. Da räume ich grade meine autocreate-Config des Test-FHEM
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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Salve,

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 .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 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 .8 lautet -- welchen Wert hat dann
$modules{CUL_WS}{defptr}{$cde} ($cde ist ?

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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> ... 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.

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.

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> ... 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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Hallo Zusammen,

# 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 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


--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> Der Typ des CUL kann nicht festgestellt werden ?? (@Rudi: noch
> nicht ?? ) )

Doch, schon "immer". CUL_WS_Parse: $hash->{VERSION} / Oder list CUL: Version

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Hi Rudi,

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



--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> >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
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).

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>>> 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 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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> 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.

> 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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> 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


--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[rudolfkoenig]

                                                   

> 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.


> 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.

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> 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

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.