[FHZ] CUN und CUL im Verbund - Empfangseinstellung

[rudolfkoenig]

Originally posted by: <email address deleted>

Hallo zusammen,

ich habe jetzt einen CUL und einen CUN im Verbund (vor allem wegen
Reichweite) im Einsatz.

Wenn ich die diversen Posts hier lese, dann sieht die Sache jetzt so
aus:

1. wenn für einen Sensor (hier S300 und HMS) kein IODev definiert ist,
nimmt fhem das Empfangsgerät, welches als letztes empfangen hat (kann
gut sein  - kann aber auch Zufall sein)
2. mit einer Zuordnung von IODev, kann ich das ganze hart
überschreiben

Wenn ich mir meine Logs so ansehe, dann ist es leider nicht so
einfach, zu entscheiden, ob der CUL oder der CUN besser empfängt.
Inbesondere im RSSI-Bereich >85 ist es eher erratisch, welcher der
beiden noch reagiert.
Leider kann man IODev für die reinen Sensoren auch kein "CUL|CUN"
definieren.

Habe ich das so richtig verstanden? Es gibt da keine sinnvolle
Einstellung, um das ganze Spektrum der CUL und CUN zu nutzen?

Danke,
Markus.

PS: Ich hoffe, ich habe jetzt die richtige Gruppe für die Frage
gewählt.
--~--~---------~--~----~------------~-------~--~----~
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,

Markus Voss wrote:
> ich habe jetzt einen CUL und einen CUN im Verbund (vor allem wegen
> Reichweite) im Einsatz.

Add me

> Wenn ich die diversen Posts hier lese, dann sieht die Sache jetzt so
> aus:
>
> 1. wenn für einen Sensor (hier S300 und HMS) kein IODev definiert ist,
> nimmt fhem das Empfangsgerät, welches als letztes empfangen hat (kann
> gut sein  - kann aber auch Zufall sein)

Nee, IIRC nimmt er das, welches zuletzt definiert wurde (fhem.cfg).

> 2. mit einer Zuordnung von IODev, kann ich das ganze hart
> überschreiben

Yepp. Aber auch ohne Festlegung, FHEM nimmt Daten nur von genau einem
CUL, vgl. 14_CUL_WS.pm:

   # It's not our device
   return "" if($def->{IODev} && $def->{IODev}{NAME} ne $hash->{NAME});

Und IODev setzt FHEM, meine ich, immer; ich habe bei mir zuletzt die
FHZ als FHZ1 und unten in der fhem.cfg noch ein paar Catch-Alls de-
finiert (bzw. Dinge, die ich keinem besonderen Raum zuordne; im Falle
der FHT_Test* sind das FHTs, die ich empfange, aber die nicht meine
sind):

setdefaultattr
define HMS_TF  HMS 1000
define HMS_T   HMS 1001
define HMS_WD  HMS 1002
define RM100   HMS 1003
define HMS_TFK HMS 1004
define HMS_MG  HMS 1006
define HMS_CO  HMS 1008
define HMS_FIT HMS 100e
define EM3 CUL_EM 7 0.01
attr EM3 model EMEM
attr EM3 IODev CUL2
define EM4 CUL_EM 8 0.01
attr EM4 model EMEM
attr EM4 IODev CUL1
define FHT_Test FHT 3315
attr FHT_Test retrycount 3
define FHT_Test2 FHT 0a55
attr FHT_Test2 retrycount 3

Die laufende Config ergibt dann:

FHZ> list HMS_TF
Internals:
    CODE       1000
    DEF        1000
    IODev      FHZ1
    NAME       HMS_TF
    NR         25
    STATE      T: 0  H: 0  Bat: ok
    TYPE       HMS
    Readings:
      2009-10-24 19:01:58   battery         ok
      2009-10-24 19:01:58   humidity        0 (%)
      2009-10-24 19:01:58   temperature     0 (Celsius)
      2009-10-24 19:01:58   type            HMS100TF
Attributes:

FHZ> list EM3
Internals:
    BasicFeePerMonth 0
    CODE       7
    CostPerUnit 0
    DEF        7 0.01
    IODev      CUL2
    NAME       EM3
    NR         33
    STATE      
    TYPE       CUL_EM
    corr1      0.01
    corr2      0.001
Attributes:
    IODev      CUL2
    model      EMEM

FHZ> list FHT_Test2
Internals:
    CODE       0a55
    DEF        0a55
    IODev      FHZ1
    NAME       FHT_Test2
    NR         36
    RAWMSG     810c04e50909a0010a550000b61d
    STATE      measured-temp
    TYPE       FHT
    Readings:
      2009-11-06 17:47:16   actuator        11%
Attributes:
    retrycount 3

> Wenn ich mir meine Logs so ansehe, dann ist es leider nicht so
> einfach, zu entscheiden, ob der CUL oder der CUN besser empfängt.
> Inbesondere im RSSI-Bereich >85 ist es eher erratisch, welcher der
> beiden noch reagiert.

Das ist bei mir ähnlich; daß ich FHZ, CUL und CUN (und CUL433) ein-
setze, hat mehrere Gründe. Anfangs war CUL noch nicht in der Lage,
FHT zu treiben, ergo habe ich mir erst eine FHZ1350 geholt (die wohl
das meiste empfangen (genauer eher: dekodieren) tut (und die damals
sofort lieferbar war). Dann kam der Wunsch nach _günstigen_ T/F-Sen-
soren auf, erschlagbar mit WS-Sensoren ohne WS, die dekodiert die FHZ
aber leider nicht direkt, ergo dafür ein CUL neben der FHZ. Hinzu kam
dann der EM-Kram (leider viel zu wenig einsetzbare Sensoren ). Und
dann erreichten die Signale aus dem OG nicht zuverlässig den CUL im EG,
ergo 2. CUL für's OG, kostet ja auch nicht (mehr) soo viel Da aber
CUL via socat doof ist (wenn man grade dabei ist, die Anzahl der Rech-
ner zu Hause zusammenzustreichen und auch deren Interaktionen zu mini-
mieren, um wegzukommen vom everything-always-on) und CUN jetzt kaufbar
war, ersetzt nun ein CUN den 2. CUL.

Und während lustigerweise der FHT80TF fast immer von beiden CULs empfan-
gen wird (teils auch von beiden gleichzeitig nicht, wenn der eigentlich
senden müßte; Rauschen?), kann ich das leider nicht von HMS, WS oder FHT
sagen

> Habe ich das so richtig verstanden? Es gibt da keine sinnvolle
> Einstellung, um das ganze Spektrum der CUL und CUN zu nutzen?

Ich denke, man sollte aus IODev eine Liste machen, sodaß mehrere
definiert werden können; allerdings müßte evtl. auch sichergestellt
werden, daß jedes Telegramm nur 1x verarbeitet wird, wenn also CUL1
das schon FHEM schickte, dann den gleichen Datensatz von CUL2 und/oder
FHZ1 verwerfen ... (Vgl. notify ... 3x Alarm wäre irgendwie doof )

Aber Rudolf wird dazu bestimt noch mal was schreiben )
         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
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

Originally posted by: <email address deleted>

Hallo Zusammen,

hatte auch solche Probleme bei meinen HMS-Devices...
Hab FHT und CUL...
FHZ und CUL haben abwechselnd empfangen....
Erst als ich 12_HMS.pm auf "Durchzug" geschaltet habe, bekam ich
regelmäßige Werte...
"Durchzug" heißt
Die Zeile "return "" if($def->{IODev} && $def->{IODev}{NAME} ne $hash->
{NAME}); " einfach auskommentieren...
Bei mir hängen da keine Notifys dran...
Und eltztens habe ich den CUL-Standort von "hinten-unten-links" auf
"vorne-oben-rechts" geändert....das hat mir meine ganzen RSSI-Werte
durcheinander gewürfelt...
S300TH keine Meldung teilweise für Stunden...

> man sollte aus IODev eine Liste machen
Ich wäre mehr für: Man sollte den Weg wie das IODev gewählt wird je
Device änderrn können...oder dynamisch gestalten z.B.:
- nach IODev-Name (wie heute),
- Alle Meldungen von Allen IODevs(wie meine HMS)
- nach Empfangsstärke (habe 'ne Beispielimplementierung für CUL_WS)
- Nach Zeit, d.h. nach zu 5sec darf auch ein anderes IODev 'ran...

Gruß

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