CUL, CUNO mehre Befehle empfangen ...

[yvl]

Hallo,

ich benütze FHEM 5.0, sowie 2 x CUL und einmal CUNO. An einer
Hausseite befindet sich ein Dämmerungsschalter (FS20SD). Dieser soll
die Rolläden (FS20RSU) zu schalten.

Jetzt bekomme ich im Logfile mehere Schaltvorgänge geloggt:

>>>>>>>
2011.02.20 17:46:25 2: FS20 DS01.00.Haus on
2011.02.20 17:46:26 2: FS20 set RL03.Vorhaus off
...
2011.02.20 17:46:26 2: FS20 DS01.00.Haus on
2011.02.20 17:46:26 2: FS20 set RL03.Vorhaus off
...
2011.02.20 17:46:28 2: FS20 RL03.Vorhaus off
<<<<<<<

Das ist etwas ungünstig, da der Rolladen nur kurz an ist und dann
anhält :-(.

Die letste Meldung ist von heute Morgen:
>>>>>>>>>>>
BTN 00
CUL1_MSGCNT 6
CUL1_RAWMSG F07A10000E7
CUL1_RSSI -86.5
CUL1_TIME 2011-02-21 07:02:39
CUL3_MSGCNT 5
CUL3_RAWMSG F07A100000B
CUL3_RSSI -68.5
CUL3_TIME 2011-02-21 07:02:39
DEF
07a1 00
07a1 00
LASTIODev CUL1
MSGCNT 8
NAME DS01.00.Haus
NR 34
STATE off
TYPE FS20
XMIT 07a1
<<<<<<<<<<

kann es sein das durch das Netzwerk CUNO (CUL3) die Meldung verspätet
ankommt und FHEM nicht erkennt das es die gleiche ist wie von CUL1
empfangen ?

Oder ist da ein snderes Problem im gange ?

Wirkt IODev auch auf den Empfang, das ist auf CUL3 gesetzt, hmmm
grübel ?

Gruß
Yves.

[Yves Lange]

Hallo,

>>>
Ja. Kannst Du bitte "attr global mseclog" setzen, den Vorgang nochmal
protokollieren, und bei Bedarf die 0.5 Sekunden in fhem.pl/CheckDuplicate()
erhoehen? Und danach bitte berichten :)
<<<

OK, das war jetzt zu spannend (um Tagelang die Nacht abzuwarten) und ich habe das mit einer Fernbedienung simuliert. An einem Punkt in dem alle CUL's nahezu gleichen Empfang haben.
Die Ereignisse sind tatsächlich > 0.5 Sec angekommen:

>>>
2011.02.21 14:52:20.912 2: FS20 FB01.00 toggle
2011.02.21 14:52:21.016 2: FS20 set SA01 toggle
...
2011.02.21 14:52:21.502 2: FS20 FB01.00 toggle
2011.02.21 14:52:21.510 2: FS20 set SA01 toggle
...
<<<

Nun habe ich in 2 Schritten erhöht, erst mit 0.8 Sec dann mit 1.2 Sec. Bei 1.2 sec kamen nun gar keine doppelten Ereignisse mehr an, das scheint in meiner Umgebung am besten zu passen.

Gruß
Yves.

-----Ursprüngliche Nachricht-----
Von: fhem-...@googlegroups.com [mailto:fhem-...@googlegroups.com] Im Auftrag von Rudolf Koenig
Gesendet: Montag, 21. Februar 2011 13:51
An: fhem-...@googlegroups.com
Betreff: Re: [FHEM] CUL, CUNO mehre Befehle empfangen ...

> kann es sein das durch das Netzwerk CUNO (CUL3) die Meldung verspätet
> ankommt und FHEM nicht erkennt das es die gleiche ist wie von CUL1
> empfangen ?

Ja. Kannst Du bitte "attr global mseclog" setzen, den Vorgang nochmal
protokollieren, und bei Bedarf die 0.5 Sekunden in fhem.pl/CheckDuplicate()
erhoehen? Und danach bitte berichten :)

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Rudolf Koenig]

> kann es sein das durch das Netzwerk CUNO (CUL3) die Meldung versp�tet

> ankommt und FHEM nicht erkennt das es die gleiche ist wie von CUL1
> empfangen ?

Ja. Kannst Du bitte "attr global mseclog" setzen, den Vorgang nochmal

[Thomas Böhne]

On Feb 21, 1:51 pm, Rudolf Koenig <inf...@koeniglich.de> wrote:
> Ja. Kannst Du bitte "attr global mseclog" setzen, den Vorgang nochmal
> protokollieren, und bei Bedarf die 0.5 Sekunden in fhem.pl/CheckDuplicate()
> erhoehen? Und danach bitte berichten :)

Auch ich hatte in den letzten Tagen das beschriebene Problem: Taster
zum Licht einschalten gedrückt, und dann gibt es einen ca. 0.5s langen
Lichtblitz und ich stehe im dunkeln... Die hier beschrieben Lösung
wird bestimmt funktionieren, aber da ich mit einem ganz normalen CUL
+CULRFR-Setup sicherlich nicht allein mit dem Problem bin, hätte ich
folgenden Vorschlag:

- die Zeit defaultmäßig etwas höher als 0,5s einstellen und
- diese Zeit über die fhem.cfg einstellbar machen.

Die beiden CULs sind in meinem Setup übrigens nur 4m Luftlinie
auseinander, der betreffende Taster ist genau in der Mitte dazwischen.
Seltsam, dass da schon 0.5s zusammenkommen.

Grüße
Thomas

[Rudolf Koenig]

> aber da ich mit einem ganz normalen CUL +CULRFR-Setup sicherlich nicht allein

> mit dem Problem bin, h�tte ich folgenden Vorschlag:

Ok, Vorschlag (teilweise :) angenommen und implementiert:

attr global dupTimeout XX
Define the timeout for which 2 identical events from two different
receiver are considered a duplicate. Default is 0.5 seconds.

> Seltsam, dass da schon 0.5s zusammenkommen.

Da kann thoretisch beliebig viel zusammenkommen, da das RFR erst dann sendet,
wenn fuer ca 20ms lang Funkstille ist. FS20 Geraete senden 3-mal mit 10ms Pause
dazwischen, und ich finde es nicht geschickt nach dem ersten emfangenen
Telegramm sofort "loszusenden".

[Juergen Lennefer]

Ich hatte das Problem auch bei meiner Dual-CUL-Lösung (kein RFR), aber
erst, seit ich das CUL-Device mit Angabe der Baudrate definiert hatte
(set CUL /dev/ttyACM)@38400).
Komischer Zusammenhang?!

Ich habe den Timeout auf 1.0 sec erhöht, mit Erfolg.