[GELÖST] Problem mit IODev - funktioniert nicht bzw. wird ignoriert

[Mitch]

Hallo,

habe ein Problem mit einem FS20 Wandsender (siehe hier: http://forum.fhem.de/index.php/topic,29340.0.html).

So wie es nun aussieht, ist es ein Problem mit dem Attribut IODev.

Ich habe eine FHZ für die FHTs und einen CUNO für FS20.

Seit gestern sendet ein FS20 Wandsender an beide und somit werden die notifys dahinter auch zweimal ausgeführt.
Wenn ich jetzt attr IODev FHZ vergebe, wird nur einmal empfangen.
Wenn ich attr IODev CUNO vergebe, wird einmal über den CUNO und einmal über die FHZ empfangen und somit der notify dahinter zweimal ausgeführt.

Sieht man ganz deutlich auch an den Internats:

Code Auswählen Erweitern

BTN
02
CFGFN
CUNO_MSGCNT
2
CUNO_RAWMSG
810b04xx0101a0015b09020012
CUNO_RSSI
-93
CUNO_TIME
2014-11-19 11:23:02
DEF
5b09 02
FHZ_MSGCNT
10
FHZ_RAWMSG
810b04240101a0015b0902001b
FHZ_TIME
2014-11-19 11:49:40
IODev
CUNO
LASTInputDev
FHZ
MSGCNT
12
NAME
FS21_5b092

[Zrrronggg!]

IOdev regelt eigentlich nur, worüber FHEM sendet. Der Empfang geht immer über alle Schnittstellen.
FHEM stellt fest, ob in einem bestimmten Intervall eine Befehle doppelt kommt und verwirft dann den 2ten. Daher finde ich es sowieso komisch, das 2x ausgeführt wird. Kann aber passieren, wenn die Laufzeiten zwischen Schnittstelle und FHEM Host sehr unterschiedlich sind. Das ist bei FHZ (USB) und CUNO (Ethernet) nicht unwahrscheinlich.

Den Intervall kann man daher einstellen und ich habe den auch mal leicht erhöht um eine ähnliches Problem ( mit CUL RFR) zu umgehen. Versuch mal:

Code Auswählen Erweitern

attr global dupTimeout 1.5

[Mitch]

Vielen Dank.

Mit

Code Auswählen Erweitern

attr global dupTimeout 0.9 funktioniert es jetzt wieder.

Allerdings ist mir nicht klar, wodurch das Problem entstanden ist.
Kann mir nur vorstellen, dass es durch DbLog kommt, weil die Datenbank langsamer ist?

[Zrrronggg!]

Tja , das weiss ich auch nicht.  Bei mir war's klar, weil RFR prinzipbedingt  immer "deutlich" später kommen kann. Beim CUNO könnte erhöhter Traffic im lokalen Netzt schon reichen.

Ausserdem muss der Sender natürlich in Funkreichweite beider Schnittstellen liegen um das Problem zu erzeugen.. Vielleicht hast da ein Bewegen einer der Schnittstellen oder das Umstellen dieses Garderobenschranks aus Metall was an der Funklage verändert.