mehrere WakeUpNotifications -> Empfangsproblem? Routingproblem?

A.Harrenberg · 30 November 2015, 10:03:09

Hi Christian,

ok, hast Du denn jetzt eine Möglichkeit das culfw auf den nanoCul zu bekommen oder musst Du warten bis das a_culfw portiert ist? Ich habe die Antwort von Locotus so verstanden das es "out of the box" erst mal nicht möglich ist.

Gruß,
Andreas.

krikan · 30 November 2015, 10:35:54

Zitat von: A.Harrenberg am 30 November 2015, 10:03:09
ok, hast Du denn jetzt eine Möglichkeit das culfw auf den nanoCul zu bekommen oder musst Du warten bis das a_culfw portiert ist? Ich habe die Antwort von Locotus so verstanden das es "out of the box" erst mal nicht möglich ist.

Ja, muss für loctus-cul-Variante auf Portierung in a_culfw warten. Ich selbst versuche mich erst gar nicht daran. "Normaler" CUL kommt deshalb auch noch; ist ja bald Weihnachten

.

A.Harrenberg · 06 Dezember 2015, 20:48:37

Hallo Rudi,

ich habe jetzt ein wenig Zwave "gesnifft" und mir kommen langsam Zweifel daran das es sich hier um ein Problem mit den Geräten bzw. der Reichweite handelt.

Das Problem mit dem USB der virtuellen Maschine werde ich noch prüfen, habe gerade ein altes Laptop mit kaputtem Akku rausgekramt und installiert das in den nächsten Tagen mal, aber ich bekomme den Verdacht das es im ZWave-Code einen Bug gibt oder ein anderes Modul uns da in die Suppe spuckt... ;-(

Laut dem Logfile von FHEM wurde der Code vom RFID-Pad erkannt und eine entsprechende Alarmmeldung (vom Gerät) verschickt und von FHEM bestätigt. Danach hat das Gerät dann angeblich 4 mal WUN geschickt, die jedesmal bestätigt wurden.
Dies passiert allerdings SEHR schnell:
19:46:23.561 / 19:46:23.566 / 19:46:23.571 / 19:46:23.584
Also angeblich 4 Übertragungen in nur 13 milisekunden! Gesnifft ist da aber nur EINE WUN mit EINER Bestätigung...

Ich bin mir nicht ganz sicher, aber ich halte es für ausgeschlossen das man diese 4 Nachrichten überhaupt in der Zeit senden kann.

Code Auswählen

2015.12.06 19:46:20.542 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060101
2015.12.06 19:46:20.542 5: SW: 06
2015.12.06 19:46:20.544 5: ZWDongle_0 dispatch 000400090a7105000000ff06060101
2015.12.06 19:46:20.544 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060101
2015.12.06 19:46:23.561 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.561 5: SW: 06
2015.12.06 19:46:23.562 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.562 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.566 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.566 5: SW: 06
2015.12.06 19:46:23.567 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.567 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.571 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.573 5: SW: 06
2015.12.06 19:46:23.574 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.574 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.584 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.593 5: SW: 06
2015.12.06 19:46:23.594 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.594 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:24.567 5: ZWDongle_Write 00 13090284082509
2015.12.06 19:46:24.567 5: SW: 010900130902840825094e
2015.12.06 19:46:24.569 5: ACK received, WaitForAck=>2 for 010900130902840825094e
2015.12.06 19:46:24.579 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.06 19:46:24.579 5: SW: 06
2015.12.06 19:46:24.580 5: ZWDongle_0 dispatch 011301
2015.12.06 19:46:24.602 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000002
2015.12.06 19:46:24.602 5: SW: 06
2015.12.06 19:46:24.603 5: device ack reveived, removing 010900130902840825094e from dongle sendstack
2015.12.06 19:46:24.603 5: ZWDongle_0 dispatch 001309000002
2015.12.06 19:46:24.604 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.12.06 19:46:24.604 4: ZWDongle_0 transmit OK for 09

Code Auswählen

zE173B78D09410114017105000000FF0606010180
zE173B78D0103010A0957
zE173B78D0941020C01840793
zE173B78D0103020A0954
zE173B78D01410D0C09840893
zE173B78D09030D0A015B

Ebenso habe ich auch bei einen Fall gesnifft bei dem FHEM nicht auf das Gerät reagiert hat, der CUL war hier sogar weiter vom Gerät weg als der USB-Stick von FHEM. Hier wurde die Nachricht drei Mal wiederholt, und kam einwandfrei am CUL an, FHEM hatte gar nichts im Log...

Ich hätte jetzt aber keine Idee wo bzw wie ich suchen soll...
Hast Du Ideen/Meinungen dazu?

Gruß,
Andreas.

rudolfkoenig · 07 Dezember 2015, 08:20:26

Reichweite: ein CUL hat normalerweise eine "richtige" Antenne (auch wenn es ein Draht ist), die Antennen der 2 Dongles, die ich bisher gesehen habe, sind bzgl. Reichweite "schlecht" (Goodway) oder "sehr schlecht" (zme). Zusaetzlich koennte ein CC1101 auch besseren Empfang bieten, muss ja nicht zwei Frequenzen gleichzeitig ueberwachen. Das ist alles nur eine _moegliche_ Erklaerung einer besseren Reichweite.

Zeitliche Aufloesung: Ein "durchschnittliches" Paket mit 40kBaud dauert ca 4ms, mit 100kBaud 1.6ms. Deine Abstaende waren 5ms, 7ms, 20ms. Vielleicht verschwendet culfw die Zeit mit zccRX() oder sonstwo, und verpasst so Nachrichten. Bei mir funktioniert 100kBaud nicht, deswegen vermute ich, dass der 100k Empfang in culfw noch nicht korrekt ist.

USB/anderes Modul/Suppe: Ich kann mir weder USB noch ein anderes FHEM-Modul oder fhem.pl als Ursache fuer wiederholte Auslieferung von Daten vorstellen. Ein Firmware Problem eher.

Kannst du nicht dein RFID Leser auf 40k zwingen? Hat den zusaetzlichen Vorteil eines potentiell besseren Empfangs: wenn jemand doppelt so schnell spricht, kann man ihn auch schlechter verstehen

A.Harrenberg · 07 Dezember 2015, 09:59:55

Hi Rudi,

Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
Reichweite: ein CUL hat normalerweise eine "richtige" Antenne (auch wenn es ein Draht ist), die Antennen der 2 Dongles, die ich bisher gesehen habe, sind bzgl. Reichweite "schlecht" (Goodway) oder "sehr schlecht" (zme). Zusaetzlich koennte ein CC1101 auch besseren Empfang bieten, muss ja nicht zwei Frequenzen gleichzeitig ueberwachen. Das ist alles nur eine _moegliche_ Erklaerung einer besseren Reichweite.

yep, ich stimme Dir zu, aber die Entfernungen sind nun wirklich nicht groß, RFID-Pad/Dongle ca. 3m (allerdings mit einer Mauer dazwischen), RFID-Pad/CUL ist ca. 4.5 m.

Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
Zeitliche Aufloesung: Ein "durchschnittliches" Paket mit 40kBaud dauert ca 4ms, mit 100kBaud 1.6ms. Deine Abstaende waren 5ms, 7ms, 20ms. Vielleicht verschwendet culfw die Zeit mit zccRX() oder sonstwo, und verpasst so Nachrichten. Bei mir funktioniert 100kBaud nicht, deswegen vermute ich, dass der 100k Empfang in culfw noch nicht korrekt ist.
[...]
Kannst du nicht dein RFID Leser auf 40k zwingen? Hat den zusaetzlichen Vorteil eines potentiell besseren Empfangs: wenn jemand doppelt so schnell spricht, kann man ihn auch schlechter verstehen

Das Netz mit dem RFID Leser ist auf 40k, daher ja meine Vermutung das die Übertragungen gar nicht in der Geschwindigkeit stattfinden können, immerhin ist da ja angeblich auch ein ACK dabei...

Das System lief ja eigentlich stabil ohne Auffälligkeiten. Dazwischen waren halt größere Umbauten in ZWave, aber auch der Umzug meines Systems auf eine virtuelle Maschine.

Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
USB/anderes Modul/Suppe: Ich kann mir weder USB noch ein anderes FHEM-Modul oder fhem.pl als Ursache fuer wiederholte Auslieferung von Daten vorstellen. Ein Firmware Problem eher.

Hmm, falls culfw evtl. Nachrichten verpasst wäre das natürlich fatal... Wenn ich davon ausgehen das dort alle Nachrichten angezeigt werden müsste es ja ein Firmwareproblem im ZWaveDongle sein, und das hätten andere sicherlich auch schon bemerkt.

Ich werde noch mal einen Test machen indem ich das ZWave-Dongle abschirme und dann sehe ob das RFID-Pad dann die Pakete wiederholt und ich die alle am culfw sehen kann. Ansonsten werde ich heute abend mal den Laptop weiter einrichten und dann das System mal dort weiterlaufen lassen und schauen sich dann was am Verhalten ändert.

Ich kann mir auch nicht wirklich vorstellen was einerseits ein mehrfaches Empfangen von Nachrichten, andererseits ein Ausbleiben einer Nachricht erklären kann. Wenn Du auch keine Idee hast dann warten wir mal ab was der Test auf dem echten Rechner ergibt.

Gruß,
Andreas.

P.S.: 100kBaud -> Gibt es andere Systeme (HM?) die mit 100kBaud auf dem Cul arbeiten? Dann könnte man dort mal nach den Parametern für Bandbreite etc. schauen.

rudolfkoenig · 07 Dezember 2015, 10:45:19

ZitatGibt es andere Systeme (HM?) die mit 100kBaud auf dem Cul arbeiten?

HM und MAX sind 10 oder 20 kBaud (da bin ich unsicher).
RFR/FastRF ist 250kBaud.
Wo hast du G-FSK / bWidth etc her?

A.Harrenberg · 07 Dezember 2015, 11:20:13

Hi Rudi,

die meisten Infos sind von hier:
http://www.rfwireless-world.com/Tutorials/z-wave-tutorial.html

Wobei ich aber die bandbreite auf den 325kHz (Voreinstellung von TI) belassen habe. Die "Deviation" müsste ich mir noch mal anschauen, ich denke das man hiermit den Empfang am ehesten beeinflussen kann. In der Spec wird 58 kHz angegeben, daher müsste theoretisch 58/2 -> 29 kHz eingestellt werden...

Gruß,
Andreas.

A.Harrenberg · 07 Dezember 2015, 19:09:45

Hallo Rudi,

das mit dem ausprobieren auf dem Laptop klappt schon mal nicht... Das Ding stürzt schon im normalen Betrieb ab ,-(
Muss mal sehen ob ich jetzt meinen alten Server noch mal rauskrame und den nutzen kann.

Zitat von: rudolfkoenig am 07 Dezember 2015, 10:45:19
HM und MAX sind 10 oder 20 kBaud (da bin ich unsicher).
RFR/FastRF ist 250kBaud.

Wenn FastRF mit 250 kBaud auf dem CUL läuft, sollte es mit 100kBaud / ZWave doch auch keinen Engpass geben was Verarbeitungsgeschwindigkeit angeht...
Wird eigentlich irgendwo / irgendwie gemeldet falls der Buffer von dem CC "überläuft"? Ich gehe aber doch davon aus das der Atmel sich die Sachen dort per IRQ abholt, oder?

Gruß,
Andreas.

rudolfkoenig · 07 Dezember 2015, 19:23:24

ZWAVE/HM/MAX/etc in culfw pollen den CC1101.
Ich stelle die Paketlaenge auf 255 ein, und bitte das CC1101 ein Pin zu setzen, falls 8 Bytes in RX-FIFO sind. Falls Pin gesetzt, lese die 8 Bytes, Byte 8 enthaelt die ZWave-Paketlaenge, danach lese ich die CC1101 solange, bis ich alle Daten habe. Danach faengt alles von vorne an.
Alles in rf_zwave_task(), was in Endlosschleife aufgerufen wird.

CUL 3.1 hatte Probleme mit FastRF, die anderen Modelle mWn nicht.

A.Harrenberg · 07 Dezember 2015, 19:35:26

Hi Rudi,

Zitat von: rudolfkoenig am 07 Dezember 2015, 19:23:24
ZWAVE/HM/MAX/etc in culfw pollen den CC1101.
Ich stelle die Paketlaenge auf 255 ein, und bitte das CC1101 ein Pin zu setzen, falls 8 Bytes in RX-FIFO sind. Falls Pin gesetzt, lese die 8 Bytes, Byte 8 enthaelt die ZWave-Paketlaenge, danach lese ich die CC1101 solange, bis ich alle Daten habe. Danach faengt alles von vorne an.
Alles in rf_zwave_task(), was in Endlosschleife aufgerufen wird.

CUL 3.1 hatte Probleme mit FastRF, die anderen Modelle mWn nicht.

das wird jetzt hier vielleicht recht OT...

D.h. der Pin am CC löst keinen IRQ aus, sondern wird nur in rf_zwave_task() genutzt um das auslesen anzustossen. Was passiert denn wenn weniger Bytes kommen als in der Länge angegeben ist? Gibt es da auch eine Art Timeout? Sonst würden ja dann das die ersten Bytes der nächsten Nachricht ausgelesen werden und die CS würde nicht stimmen, die Pakete würden dann durcheinander kommen...

Gruß,
Andreas.

P.S.: Der Server läuft schon mal jetzt muss ich das FHEM da mal rüberkopieren...

rudolfkoenig · 07 Dezember 2015, 19:53:05

Weiss ich nicht....

A.Harrenberg · 07 Dezember 2015, 21:25:08

Hallo,

so, der Server läuft rudimentär, den CUL habe ich zum Sniffen mit eingebunden, allerdings nicht als zwcul, die Kiste will momentan irgendwie nicht mit dem Internet reden...
Aus den bisherigen Logs werde ich allerdings noch nicht so wirklich schlau ,-(

Messages tauchen im CUL teilweise 50ms früher auf als in Zwave, da ist anscheinend eine relativ große Totzeit dazwischen.
Mehrfache WUN kommen immer noch, auch wenn ich den RFID-Leser auf den Schreibtisch hole und die Neighborlist aktualisere
Bisher habe ich einmal zwei WUN beim CUL gesehen während Zwave 4 gesehen hat, ansonsten immer eine bei CUL, 4 bei ZWave
Wenn ZWave sendet ist die Antwort vom Gerät SOFORT da, d.h. die tauch bei CUL/RAW bereits in der gleichen Zeile auf -> Geräte antworten SEHR schnell...
Die Acknowledge Nachrichten im Netz kommen mMn viel früher als das ACK in FHEM (auch wenn ich die Totzeit betrachte), daher vermute ich fast das "unser" ACK nur dem Controller gilt und der selbstätig eine Acknowledge Nachricht absetzt falls die empfangene Nachricht iO ist.

Erstes Fazit ist erst mal nur das es anscheinend nicht an der virtuellen Umgebung liegt, das Phänomen tritt auch auf einem echten Rechner auf.
Ich werde jetzt mal anfangen ein paar Sachen aus der Config zu löschen um zu sehen ob es evtl. an weiteren Modulen oder meinen Erweiterungen liegt.

Allerdings muss ich dann wieder "zurückbauen", sonst leidet der WAF.

Gruß,
Andreas

A.Harrenberg · 07 Dezember 2015, 22:18:38

Hi,

hier mal ein Logausschnitt (jetzt wieder von der virtuellen Maschine)
40kBaud, RFID-Leser liegt ca. 0.5m neben dem Dongle, Routing findet anscheinend nicht statt

Hier kommt der Code vom Leser bei CUL an, quasi gleichzeitig gibt es eine Bestätigungsnachricht:

Code Auswählen

2015.12.07 21:59:18.866 5: CUL/RAW: /zE173B78D09410114017105000000FF0606010180

2015.12.07 21:59:18.866 4: CUL_Parse: CUL_1 zE173B78D09410114017105000000FF0606010180
2015.12.07 21:59:18.868 2: CUL_1: unknown message zE173B78D09410114017105000000FF0606010180
2015.12.07 21:59:18.876 5: CUL/RAW: /zE173B78D0103010A0957

2015.12.07 21:59:18.876 4: CUL_Parse: CUL_1 zE173B78D0103010A0957
2015.12.07 21:59:18.879 2: CUL_1: unknown message zE173B78D0103010A0957

Jetzt kommt der Code bei ZWave an und es wird ein ACK generiert:

Code Auswählen


2015.12.07 21:59:18.883 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060101
2015.12.07 21:59:18.883 5: SW: 06
2015.12.07 21:59:18.884 5: ZWDongle_0 dispatch 000400090a7105000000ff06060101
2015.12.07 21:59:18.884 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060101

Hier kommt die WUN bei CUL an, wieder quasi gleichzeitig die Bestätigungsnachricht:

Code Auswählen


2015.12.07 21:59:21.894 5: CUL/RAW: /zE173B78D0941020C01840793
zE173B78D0103020A0954

2015.12.07 21:59:21.894 4: CUL_Parse: CUL_1 zE173B78D0941020C01840793
2015.12.07 21:59:21.895 2: CUL_1: unknown message zE173B78D0941020C01840793
2015.12.07 21:59:21.896 4: CUL_Parse: CUL_1 zE173B78D0103020A0954
2015.12.07 21:59:21.897 2: CUL_1: unknown message zE173B78D0103020A0954

Jetzt kommt die WUN bei ZWave an und es wird ein ACK generiert.
Dann kommen drei weitere WUN/ACK die vom CUL nicht gesehen werden (weil sie nicht da sind?)

Code Auswählen


2015.12.07 21:59:21.897 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.897 5: SW: 06
2015.12.07 21:59:21.898 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.898 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.902 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.902 5: SW: 06
2015.12.07 21:59:21.903 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.903 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.907 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.907 5: SW: 06
2015.12.07 21:59:21.908 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.908 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.911 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.911 5: SW: 06
2015.12.07 21:59:21.912 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.912 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407

Jetzt wird die WUNMI von ZWave gesendet:

Code Auswählen


2015.12.07 21:59:22.902 5: ZWDongle_Write 00 13090284082509
2015.12.07 21:59:22.902 5: SW: 010900130902840825094e
2015.12.07 21:59:22.905 5: ACK received, WaitForAck=>2 for 010900130902840825094e
2015.12.07 21:59:22.920 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.07 21:59:22.920 5: SW: 06
2015.12.07 21:59:22.921 5: ZWDongle_0 dispatch 011301

Hier kommt die WUNMI bei CUL an, danach die Bestätigung vom Gerät:

Code Auswählen


2015.12.07 21:59:22.922 5: CUL/RAW: /zE173B78D01410C0C09840892

2015.12.07 21:59:22.922 4: CUL_Parse: CUL_1 zE173B78D01410C0C09840892
2015.12.07 21:59:22.924 2: CUL_1: unknown message zE173B78D01410C0C09840892
2015.12.07 21:59:22.926 5: CUL/RAW: /zE173B78D09030C0A015A

2015.12.07 21:59:22.926 4: CUL_Parse: CUL_1 zE173B78D09030C0A015A
2015.12.07 21:59:22.928 2: CUL_1: unknown message zE173B78D09030C0A015A
2015.12.07 21:59:22.945 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000003
2015.12.07 21:59:22.945 5: SW: 06
2015.12.07 21:59:22.946 5: device ack reveived, removing 010900130902840825094e from dongle sendstack
2015.12.07 21:59:22.946 5: ZWDongle_0 dispatch 001309000003
2015.12.07 21:59:22.946 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.07 21:59:22.946 4: ZWDongle_0 transmit OK for 09

Ehrlich gesagt glaube ich nicht das der CUL Nachrichten verschluckt...
Empfangsprobleme kann ich bei der Entfernung eigentlich auch ausschliessen...

Ich kann jetzt noch mal den Empfangsbuffer von ZWDongle mit Lognachrichten zupflastern, für weitere Ideen wäre ich dankbar.

Gruß,
Andreas.

krikan · 07 Dezember 2015, 22:47:44

Hallo Andreas,
leider kann ich nicht wirklich etwas hilfreiches beitragen, außer meiner Behauptung, dass es in Deinem System begründet ist. Ich logge ZWave im Produktivsystem mit verbose 5 und bin jetzt alle WUN im Dezember durchgegangen und kann solche Dopplungen nicht feststellen. Immer nur eine. Hast Du mal probiert bspw. den AEOTEC Sensor mit einzubinden? Hat der das Problem dann auch?
Gruß, Christian

A.Harrenberg · 07 Dezember 2015, 23:15:11

Hi,

hier mal ein Log mit ein paar zusätzlichen Logmessages in ZWDongle.pm

Code Auswählen

2015.12.07 22:59:10.048 5: CUL/RAW: /zE173B78D0941020C01840793

2015.12.07 22:59:10.049 4: CUL_Parse: CUL_1 zE173B78D0941020C01840793
2015.12.07 22:59:10.051 2: CUL_1: unknown message zE173B78D0941020C01840793
2015.12.07 22:59:10.053 5: ZWDongle RAW buffer: 0110000400090a7105000000ff06
2015.12.07 22:59:10.055 5: ZWDongle RAW buffer: 0110000400090a7105000000ff0606
2015.12.07 22:59:10.058 5: ZWDongle RAW buffer: 0110000400090a7105000000ff060601
2015.12.07 22:59:10.059 5: ZWDongle RAW buffer: 0110000400090a7105000000ff06060104
2015.12.07 22:59:10.059 5: CUL/RAW: /zE173B78D0103020A0954

2015.12.07 22:59:10.059 4: CUL_Parse: CUL_1 zE173B78D0103020A0954
2015.12.07 22:59:10.066 2: CUL_1: unknown message zE173B78D0103020A0954
2015.12.07 22:59:10.066 5: ZWDongle RAW buffer: 0110000400090a7105000000ff0606010466
2015.12.07 22:59:10.066 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060104
2015.12.07 22:59:10.067 5: SW: 06
2015.12.07 22:59:10.070 5: ZWDongle_0 dispatch 000400090a7105000000ff06060104
2015.12.07 22:59:10.071 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060104
2015.12.07 22:59:13.076 1: PERL WARNING: Use of uninitialized value $camret in concatenation (.) or string at ./FHEM/49_IPCAM.pm line 234.
2015.12.07 22:59:13.083 1: ProcessSendStack called
2015.12.07 22:59:13.086 5: ZWDongle RAW buffer: 0108000400090284077b0108000400090284077b0108000400090284077b0108000400090284077b

Hier kommt die WUN bei CUL an:
2015.12.07 22:59:10.051 2: CUL_1: unknown message zE173B78D0941020C01840793

Nachdem ZWave dann mit der auslesen der vorher gesendeten Nachricht fertig ist, befinden sich plötzlich 4 Nachrichten im ZWDongle buffer...
Und FHEM ist hier auch irgendwie 3 sekunden schlafen gegangen...

Alles SEHR merkwürdig!

@Krikan: Die Idee mit dem AEOTEC war mir eben auch gekommen, schaffe ich aber heute nicht mehr. im Testsystem ist mir das bisher auch nicht aufgefallen.

Gruß,
Andreas.