CUL RFR Problem: Kommandos werden doppelt ausgeführt.

Begonnen von Zrrronggg!, 14 Oktober 2012, 04:06:45

Vorheriges Thema - Nächstes Thema

Zrrronggg!

                                                     

Ich habe seit 2-3 Wochen ein seltsames Problem. Zunächst viel es
meiner Holden Maid auf: Wenn sie das Terassenlicht abends ausgemacht
hat, ging das aus, sofort wieder und sofort wieder aus.

Mir hingegen viel auf, das man das Einfahrtstor nicht mehr über FHEM
öffnen konnte, sondern nur mit der direkt gekoppelten Fernbedienung,
die eigentlich als Notfall gedacht ist.

Nun habe ich eben versucht raus zu bekommen woran das liegt. Dabei ist
mir aufgefallen, dass  bestimmte durch Fernbedienungen ausgelöste
Macros offenbar 2x ausgelöst werden.
In den meisten Fällen ist das egal und kaum bemerkbar. Wenn man z.b.
ein Licht anmacht, ist es ja wurst, ob das "on" 2x kommt.

Ohne euch jetzt zu sehr mit meinen Schaltungen zu langweilen gibt es
aber auch Situationen wo das nicht mehr geht.
- das Tor geht dann nicht auf, weil ich hier den Tastendruck in einen
Impuls am Aktor umwandeln muss  (Torsteuerung braucht ON/OFF und
toggelt dann zwischen aufgehen und zu gehen), wenn der 2x kommt geht
das Tor 2 zentimeter auf und sofort wieder zu.
- das Terassenlicht braucht ein bischen Logik, da hier ein HM Aktor
über eine FS20 Fernbedienung mit Toggelfunktion ein und ausgeschaltet
wird.

Ergebniss ist: wo Toggle oder Toggle-ähnliche Logik verwendet wird hat
man Trauer.

Aber WARUM wird der Befehl 2x ausgelöst?

Ich dachte zunächst an einen Fehler bei mir (obwohl ich nicht wüsse,
was ich geändert haben soll, meine Installtion ist seit ca. 8 Monaten
so gut wie unverändert), aber nach 4 Stunden rumfluch... eh...
rumsuchen hatte ich die Idee:
CUL RFR aus der Dose gezogen... alles bestens.
CUL RFR wieder reingesteckt: doppelt.

Mit anderen Worten: es stellt sich mir gerade so dar, als ob von einer
Fernbedienung kommende Kommandos, die beide CULs empfangen auch
tatsächlich 2x ausgelöst werden, und zwar innerhalb der (meistens)
selben Sekunde.

Das sieht dann im Log z.b. so aus:

2012-10-14 03:27:25 Global global DEFINED tor_sw_timer
2012-10-14 03:27:25 Global global DEFINED reset_tor_sw
2012-10-14 03:27:25 FS20 tor_sw on-for-timer 2
2012-10-14 03:27:26 FS20 Einfahrt_TAST on
2012-10-14 03:27:26 Global global DELETED tor_sw_timer
2012-10-14 03:27:26 FS20 tor_sw off
2012-10-14 03:27:26 Global global DEFINED tor_sw_timer
2012-10-14 03:27:26 FS20 tor_sw on-for-timer 2
2012-10-14 03:27:26 FS20 Einfahrt_TAST on
2012-10-14 03:27:27 Global global DELETED tor_sw_timer
2012-10-14 03:27:27 FS20 tor_sw off
2012-10-14 03:27:27 Global global DEFINED tor_sw_timer
2012-10-14 03:27:27 FS20 tor_sw on-for-timer 2
2012-10-14 03:27:28 Global global DELETED tor_sw_timer
2012-10-14 03:27:28 FS20 tor_sw off
2012-10-14 03:27:28 Global global DELETED reset_tor_sw


Verbose 5 zeigt folgendes:

2012.10.14 03:43:37 5: CUL1: F00FC2011 -89
2012.10.14 03:43:37 5: CUL1 dispatch 810b04xx0101a00100fc200011
2012.10.14 03:43:37 2: FS20 Einfahrt_TAST on
2012.10.14 03:43:37 5: Triggering Einfahrt_TAST (1 changes)

Es folgt die ganze Arie des Vergleichens mit Triggern, diverse werden
ausgelöst, alles wie es soll.
Kommandos werden abgesetzt, dadurch noch mehr trigger checken,,
define ... at... wird erzeugt, etc.


Dann kommt:

2012.10.14 03:43:37 5: CUL1: 0102UF00FC201117;
2012.10.14 03:43:37 5: CUL1 dispatch 0102UF00FC201117;
(irgendwas anderes, vielleicht die CUL2 Kommunikation) und dann:

2012.10.14 03:43:37 5: CUL2: F00FC2011 -62.5
2012.10.14 03:43:37 5: CUL2 dispatch 810b04xx0101a00100fc200011
2012.10.14 03:43:38 2: FS20 Einfahrt_TAST on
2012.10.14 03:43:38 5: Triggering Einfahrt_TAST (1 changes)
und de ganze Arie geht wieder los.

Kapier ich nicht.

Randparameter:
 5.2+SVN from 2012-02-12
Beide CULs 1.44
CUL Kommunikation klappt ansonsten einwandfrei.

Resetten der CULs und rebooten und so bringt alles nichts.
Warten aber schon: Es ist nämlich nicht immer so. Insbesondere wenn
die Funklast hoch ist, also gerade viel passiert, ist die Chance, dass
das Phänomen auftritt sehr hoch.

Daher meine Frage: Wie erkennt FHEM, das RFR Kommandos die selben
sind, die schon das CUL empfangen hat?
Sonst noch jemand eine Idee?

Ach ja: An der Fernbedienung liegts eher nicht, weil der Effekt bei
mehreren Fernbedienungen auftritt.






--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

rudolfkoenig

                                                   

> Daher meine Frage: Wie erkennt FHEM, das RFR Kommandos die selben
> sind, die schon das CUL empfangen hat?

http://fhem.de/commandref.html#dupTimeout

Da das RFR beim Senden inzwischen laenger auf Funkstille wartet, ist der
default mit 0.5 wahrscheinlich zu konservativ (== klein) eingestellt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Zrrronggg!

                                                     

Ah. THX, werde mal 1 Sekunde testen

On 14 Okt., 08:28, Rudolf Koenig wrote:
> > Daher meine Frage: Wie erkennt FHEM, das RFR Kommandos die selben
> > sind, die schon das CUL empfangen hat?
>
> http://fhem.de/commandref.html#dupTimeout
>
> Da das RFR beim Senden inzwischen laenger auf Funkstille wartet, ist der
> default mit 0.5 wahrscheinlich zu konservativ (== klein) eingestellt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL