Fehler bei abarbeiten eines DOIF

[krikan]

Anmerkungen zum Log mit DOIF:

Code Auswählen Erweitern

2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020033003ff (request APPLICATION_COMMAND_HANDLER), sending ACK
FHEM erhält Telegramm vom Dongle und verarbeitet Info vom Sensor per CC SENSOR_BINARY, dass das Fenster geöffnet wurde (->Assogroup 3). Das löst das DOIF aus.

Code Auswählen Erweitern

2016.08.16 20:34:39 5: SW: 010e00131e07600d01022501FF25e982
Das DOIF setzt den Einschaltbefehl für das Licht ab und FHEM schickt den Befehl an das Dongle

Code Auswählen Erweitern

2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020032001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
FHEM erhält Telegramm vom Dongle und verarbeitet Info vom Sensor per CC BASIC, dass das Fenster geöffnet wurde (->Assogroup 1).

Code Auswählen Erweitern

2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: CAN received
Dongle informiert FHEM, dass der letzte an das Dongle geschickte Befehl (Einschaltbefehl Licht) nicht verarbeitet werden konnte, weil das Dongle mit einer anderen Nachricht (Empfang Telegramm CC BASIC) beschäftigt war. Das ist gleichzeitig Hinweis für FHEM den Befehl noch einmal zu schicken.

Code Auswählen Erweitern

2016.08.16 20:34:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d01022501FF25e982
FHEM loggt das normale Ereignis von Kollisionen durch CAN

Code Auswählen Erweitern

2016.08.16 20:34:40 5: SW: 010e00131e07600d01022501FF25e982
FHEM schickt den Befehl noch mal und er wird korrekt verarbeitet.

Grundsätzlich passiert hier nichts ungewöhnliches oder falsches. Die Kollision (CAN) ist aber vermutlich vermeidbar, indem man die doppelte Benachrichtigung an FHEM über die FGK-Zustandsänderung beseitigt. Für die gibt es mMn keinen Grund.

Also Abhilfe:
ZWDongle_0 aus der Assoziationsgruppe 1 des Sensors entfernen (-> associationDel) und testen.
Wenn das wirklich nicht reichen sollte, dann erst mit wait/sleep-Konstrukten arbeiten.

[tomspatz]

Hallo Christian

dank für die ausführliche Erklärung. Nun beide Wege führen zum Ziel.
Ich habe es mit

Code Auswählen Erweitern

attr  LichtKammerAutomatik wait .15:.15
funktioniert einwandfrei.
Jetzt soeben das attr gelöscht und ZWDongle_0 aus der Assoziationsgruppe 1 des Sensors entfernt, das funktioniert auch.
Vielen dank.

btw.
habe ich mir Gedanken gemacht ob man die Funklast nicht reduzieren könnte, sollte.
Es ist zwar NUR ein Befehl der vermutlich nicht zigfach pro Sekunde ausgelöst wird, aber dennoch.
Könnte mann oder sollte man ggf. bevor das Licht eingeschaltet wird prüfen ob es nicht schon an ist.
Im Umkehrschluss warum ein Befehl zum ausschalten schicken wenn es gar nich leuchtet.

Ist da was dran?

[krikan]

Nun beide Wege führen zum Ziel.

Klar funktioniert auch die Verzögerung zur Vermeidung eines Logeintrages, aber die eigentliche Ursache bleibt mMn eine überflüssige Assoziierung des Controllers mit Group 1 des Sensors. 

habe ich mir Gedanken gemacht ob man die Funklast nicht reduzieren könnte, sollte.
Es ist zwar NUR ein Befehl der vermutlich nicht zigfach pro Sekunde ausgelöst wird, aber dennoch.
Könnte mann oder sollte man ggf. bevor das Licht eingeschaltet wird prüfen ob es nicht schon an ist.
Im Umkehrschluss warum ein Befehl zum ausschalten schicken wenn es gar nich leuchtet.

Ist da was dran?

Persönlich sehe ich das so. Unnötige Funknachrichten bringen manchmal -wie bei Deinem Ausgangsthema- unnötige Probleme.
Beim notify kann man für diesen Zweck alternativ zu if-Konstrukten im set-Befehl devspec verwenden, um den Schaltvorgang nur auszulösen, wenn der Schaltzustand noch nicht vorliegt.