Abarbeitung des WakeUp-Sendstacks wird in Einzelfällen unterbrochen

krikan · 08 März 2016, 21:04:40

Die Class CRC_16_ENCAP führt heute bei "versionClassAll" zu dieser Warnung:

2016.03.08 20:56:01.639 1: PERL WARNING: Argument "CRC_16_ENCAP" isn't numeric in sprintf at ./FHEM/10_ZWave.pm line 1604.
2016.03.08 20:56:01.642 3: stacktrace:
2016.03.08 20:56:01.645 3:     main::__ANON__                      called by ./FHEM/10_ZWave.pm (1604)
2016.03.08 20:56:01.648 3:     main::ZWave_versionClassGet         called by (eval 270) (1)
2016.03.08 20:56:01.651 3:     (eval)                              called by ./FHEM/10_ZWave.pm (840)
2016.03.08 20:56:01.654 3:     main::ZWave_Cmd                     called by ./FHEM/10_ZWave.pm (923)
2016.03.08 20:56:01.657 3:     main::ZWave_SCmd                    called by ./FHEM/10_ZWave.pm (928)
2016.03.08 20:56:01.659 3:     main::ZWave_Get                     called by ./FHEM/10_ZWave.pm (1624)
2016.03.08 20:56:01.662 3:     main::ZWave_versionClassAllGet      called by (eval 265) (1)
2016.03.08 20:56:01.665 3:     (eval)                              called by ./FHEM/10_ZWave.pm (840)
2016.03.08 20:56:01.668 3:     main::ZWave_Cmd                     called by ./FHEM/10_ZWave.pm (923)
2016.03.08 20:56:01.671 3:     main::ZWave_SCmd                    called by ./FHEM/10_ZWave.pm (928)
2016.03.08 20:56:01.673 3:     main::ZWave_Get                     called by fhem.pl (3148)
2016.03.08 20:56:01.676 3:     main::CallFn                        called by fhem.pl (1638)
2016.03.08 20:56:01.678 3:     main::CommandGet                    called by fhem.pl (1067)
2016.03.08 20:56:01.681 3:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2185)
2016.03.08 20:56:01.684 3:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (713)
2016.03.08 20:56:01.687 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (446)
2016.03.08 20:56:01.689 3:     main::FW_Read                       called by fhem.pl (3148)
2016.03.08 20:56:01.691 3:     main::CallFn                        called by fhem.pl (654)
2016.03.08 20:56:01.694 2: ZWave get ZWave_SENSOR_BINARY_18 versionClass CRC_16_ENCAP

krikan · 08 März 2016, 21:53:33

Nächste Problem

Ich weiß jetzt wieder, warum APPLICATION_UPDATE wie wakeupNotification behandelt wurde. Der Fibaro FGMS-001 signalisiert über ZW_APPLICATION_UPDATE ein manuelles wakeup. Ein wakeupNotfication kommt nicht. Derzeit kann man den also nicht manuell aufwecken, was mehr als schlecht ist. Und das wird vermutlich noch mehr Geräte treffen

Code Auswählen

2016.03.08 21:42:41.477 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984120f042001308485808f567286708e319c
2016.03.08 21:42:41.483 5: SW: 06
2016.03.08 21:42:41.488 5: ZWDongle_0 dispatch 004984120f042001308485808f567286708e319c
2016.03.08 21:42:41.492 4: CMD:ZW_APPLICATION_UPDATE ID:12 ARG:0f042001308485808f567286708e319c CB:84

Andreas, wie sieht beim Aeotec Multisensor 6 das störende APPLICATION_UPDATE aus, das nicht zum wakeUp des Sensors führt?

krikan · 08 März 2016, 21:57:40

Habe es schon gefunden, hattest Du schon gepostet:

Code Auswählen

2016.03.05 09:11:02.204 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
Unterschied???

A.Harrenberg · 08 März 2016, 22:40:20

Hi,

Zitat von: krikan am 08 März 2016, 21:53:33
Nächste Problem
Ich weiß jetzt wieder, warum APPLICATION_UPDATE wie wakeupNotification behandelt wurde. Der Fibaro FGMS-001 signalisiert über ZW_APPLICATION_UPDATE ein manuelles wakeup. Ein wakeupNotfication kommt nicht. Derzeit kann man den also nicht manuell aufwecken, was mehr als schlecht ist. Und das wird vermutlich noch mehr Geräte treffen

ich sag' doch Ihr wolltet das behalten...
Ich wäre aber wie gesagt dann doch dafür das bei diesen Geräten per Attribut zu aktivieren, es entspricht ja nun wirklich nicht der Spezifikation.

Zitat von: krikan am 08 März 2016, 21:53:33
Andreas, wie sieht beim Aeotec Multisensor 6 das störende APPLICATION_UPDATE aus, das nicht zum wakeUp des Sensors führt?

Das Problem ist ja zum einen das die WUN auch noch kommt und alles durcheinander bringt und das der Sensor wenn er nach dem APPLICATION_UPDATE kommuniziert so schnell wieder einschläft, da er ja offiziell gar nicht eingeschlafen ist.
Ich habe mir das noch nicht soo genau angesehen, aber wenn der Stack leer ist müsste der eigentlich eine WNMI bekommen BEVOR er die WUN verschickt hat...

Argl, können die sich nicht einfach mal an die eigenen Regeln halten?

Ich habe gerade noch mal das Senden nach APPLICATION_UPDATE noch mal aktiviert und bekomme danach trotz der ganzen Änderugen immer noch Fehler (getestet mit configAll). CAN und no_response und es werden teilweise configs nicht empfangen, der Sendstack ist danach aber leer... Das ist auch nicht schön...

Nur mit WUN scheint es aber einwandfrei zu funktionieren. Na ja, ich kann mich leider nicht wirklich darum kümmern und vertrau mal ganz auf euch! ,-)

Gruß,
Andreas.

krikan · 08 März 2016, 22:55:15

Zitat von: A.Harrenberg am 08 März 2016, 22:40:20
Ich wäre aber wie gesagt dann doch dafür das bei diesen Geräten per Attribut zu aktivieren, es entspricht ja nun wirklich nicht der Spezifikation.

Bei welchen Geräten entspricht das nicht der Spezifikation? Bisher hatten wir die Probleme meines Wissen nach nur mit dem Aeotec Multisensor 6

. Also sollten wir dem doch ein Attribut verpassen. ozw nimmt ZW_APPLICATION_UPDATE auch als wakeUp-Kennzeichen. Also ganz so falsch können wir nicht liegen.

krikan · 09 März 2016, 00:15:50

Zitat von: rudolfkoenig am 08 März 2016, 17:31:39
Kannst du bitte vorne in ZWave_processSendStack ein
Code Auswählen Erweitern
Log 4, "processSendStack ".$ss->[0];
einfuegen, und es nochmal probieren?

Habe das so gemacht:

Code Auswählen

sub
ZWave_processSendStack($$;$)
{
  my ($hash,$ackType, $omsg) = @_;
  my $ss = $hash->{SendStack};
  return if(!$ss);
  Log 4, "processSendStack ".$ss->[0];

Das ist aber vermutlich nicht OK, da ich den Log-Eintrag nie bekomme...

A.Harrenberg · 09 März 2016, 07:44:37

Hi Christian,

Zitat von: krikan am 08 März 2016, 22:55:15
Bei welchen Geräten entspricht das nicht der Spezifikation? Bisher hatten wir die Probleme meines Wissen nach nur mit dem Aeotec Multisensor 6 . Also sollten wir dem doch ein Attribut verpassen. ozw nimmt ZW_APPLICATION_UPDATE auch als wakeUp-Kennzeichen. Also ganz so falsch können wir nicht liegen.

das war wohl eher ironisch gemeint, oder? Auch wenn OZW das als WU interpretiert bedeutet ja nicht das es so richtig bzw. konform ist.

Wenn es Geräte gibt die konform eine WUN melden wenn man sie manuell aufweckt (nach dem sie APPLICATION_UPDATE gesendet haben) und welche die bei manuellem Aufwecken nur APPLICATION_UPDATE aber keine WUN melden fällt es mir leicht zu entscheiden wer der Sonderfall ist und das Attribut bekommen sollte

Letztendlich ist es (mir) aber egal, es sollte mMn aber konfigurierbar sein. Kann sein das es vielleicht sogar mehr Geräte gibt die das "falsch" machen als solche die es "richtig" machen. Da das bisherige Verhalten der "Standard" war, könnte es aus User Sicht auch wirklich besser sein das Attribut einzuführen wenn der bisherige Standard eben nicht mehr gilt.

Problematisch an der Sache sind ja zwei Sachen. Die Sensoren senden meist nach dem APPLICATION_UPADATE noch ein paar Statuswerte, wenn FHEM da direkt anfängt zu senden sind die CAN vorprogrammiert. Das zweite ist das Einschlafen, das ja vielleicht in wirklichkeit auch nur "ignorieren" auf Seite des Sensors ist?

Aber wie gesagt, ganz egal, ich hätte das nur gerne konfigurierbar, ob man das ein- oder ausschalten muss ist egal.

Gruß,
Andreas.

krikan · 09 März 2016, 08:02:26

Zitatdas war wohl eher ironisch gemeint, oder? Auch wenn OZW das als WU interpretiert bedeutet ja nicht das es so richtig bzw. konform ist.

Ja und nein. Ich habe keine Ahnung, ob ozw es richtig macht und ich mag bei meinem Nachwuchs die Aussage "Der macht das aber auch" nicht

. Ehrlicherweise müsste ich mir den Ablauf in ozw dann genauer anschauen. Mir fällt nur auf, dass es bisher nie Probleme mit dem Thema gab außer beim AEOTEC MS 6. Lösung ist mir ebenfalls egal

Nur ist es mMn besser dem Sonderfall das Attribut zu geben als dem Regelfall. Was Regelfall/Sonderfall ist, müsste man noch herausfinden. Meine derzeitige Vermutung kennst Du.

Habe bisher nicht wahrgenommen, dass APPLICATION_UPDATE eine unsolicited Message ist. Dem scheint ja beim MS 6 so zu sein. Ich hatte APPLICATION_UPDATE, das den NIF beinhaltet, als manuell angeforderte Nachricht betrachtet. In meinem Gedankengang ist das die gleiche Nachricht, die auch bei der Inklusion verschickt wird und dann ist der Sensor auch länger wach. Aber das sind alles nicht erprobte und hinterfragte Schlußfolgerungen. Hast Du weitere Infos dazu?

A.Harrenberg · 09 März 2016, 09:03:01

Hi Christian,

Zitat von: krikan am 09 März 2016, 08:02:26
Ja und nein. Ich habe keine Ahnung, ob ozw es richtig macht und ich mag bei meinem Nachwuchs die Aussage "Der macht das aber auch" nicht . Ehrlicherweise müsste ich mir den Ablauf in ozw dann genauer anschauen. Mir fällt nur auf, dass es bisher nie Probleme mit dem Thema gab außer beim AEOTEC MS 6. Lösung ist mir ebenfalls egal Nur ist es mMn besser dem Sonderfall das Attribut zu geben als dem Regelfall. Was Regelfall/Sonderfall ist, müsste man noch herausfinden. Meine derzeitige Vermutung kennst Du.

meine kennst du auch

Wie gesagt, technisch ist es egal wie herum man das Attribut anwenden würde, das wäre eine Glaubensfrage.

Keine Probleme gab es wahrscheinlich bisher nur deshalb weil nur sehr selten so viele Nachrichten im Stack liegen und das erst mit ConfigAll so "einfach" ist. Von der Spezifikation ist recht klar das man auf ein WUN warten soll bis man was sendet, die APPLICATION_UPDATE ist mMn etwas das ein Update bzw. eine Änderung im NIF ankündigen soll. Aber das Ding ist leider sehr schlecht dokumentiert, hier ist mehr raten als wissen vorhanden...

Zitat von: krikan am 09 März 2016, 08:02:26
Habe bisher nicht wahrgenommen, dass APPLICATION_UPDATE eine unsolicited Message ist. Dem scheint ja beim MS 6 so zu sein. Ich hatte APPLICATION_UPDATE, das den NIF beinhaltet, als manuell angeforderte Nachricht betrachtet. In meinem Gedankengang ist das die gleiche Nachricht, die auch bei der Inklusion verschickt wird und dann ist der Sensor auch länger wach. Aber das sind alles nicht erprobte und hinterfragte Schlußfolgerungen. Hast Du weitere Infos dazu?

Also eine Nachricht die per Taster ausgelöst wird und nicht mehr (Funk-) Anfrage ist für mich "unsolicited"

Jedenfalls aus Sicht des Empfängers. Das ist definitiv keine Antwort auf eine Frage.
WARUM APPLICATION_UPDATE überhaupt versendet wird ist mir nicht klar, meine Geräte senden jeweils den gleichen Block wie bei der Inklusion.

Jedenfalls ist die ganze Diskussion müssig, für den FGMS braucht Ihr das, also muss es wieder rein. Da das bisher das Standardverhalten war (und OZW es auch so macht) ist es wahrscheinlich besser das auch so als Standard drin zu lassen. Falls ich Rudi überzeugen kann dann hätte ich gerne ein Attribut um das auszblenden. ,-)

Wenn ich wieder zurück bin werde ich mir mal diese ganzen Application Dokumente ansehen und schauen ob wir da mehr zu diesen Themen finden können.

Gruß,
Andreas.

rudolfkoenig · 09 März 2016, 09:19:08

Nach durchlesen eurer Argumente:

ZitatnoWakeupForApplicationUpdate
some devices (notable the Aeotec Multisensor 6) are only awake after an
APPLICATION UPDATE telegram for a very short time. If this attribute is
set (recommended for the Aeotec Multisensor 6), the WakeUp-Stack is not
processed after receiving such a message.

Andreas kann sich damit troesten, dass er jetzt kein WNMI_delay mehr braucht.

ZitatDas ist aber vermutlich nicht OK, da ich den Log-Eintrag nie bekomme...

Sorry, klar: Log haengt vom global verbose ab, und das ist per default 3. Versuch mal an gleicher Stelle mit:

Code Auswählen

Log 1, "processSendStack ".$ss->[0];

ZitatPERL WARNING: Argument "CRC_16_ENCAP" isn't numeric in sprintf at ./FHEM/10_ZWave.pm line 1604.

Habs gefixt.

ZitatDokumentiert ist für ZW_SEND_DATA nur der Schlechtfall 00 mit "if transmit queue overflow".

D.h. bei FHEM stand in so einem Fall im Log:

ZitatERROR: cannot SEND_DATA to XXX: 00

Habe das 00 nach "transmit queue overflow" geaendert.

A.Harrenberg · 09 März 2016, 09:30:34

Hi Rudi,

Zitat von: rudolfkoenig am 09 März 2016, 09:19:08
Nach durchlesen eurer Argumente:Andreas kann sich damit troesten, dass er jetzt kein WNMI_delay mehr braucht.

ist ja eher das durch das Senden der Statusnachrichten nach APPLICATION_UPDATE und dem Sender der WUN vom Sensor, das "verfrühte" Senden von FHEM gestört wird.
Ich bekomme ja nach wie vor CAN und no_response Nachrichten wenn nach APPLICATION_UPDATE gesendet wird. Ob ich ein WNMI_delay brauche oder ein NO_ACK auf die WNMI bekomme weil das Ding schon eingeschlafen ist, ist mir herzlich egal. Das hat ja keine funktionale Auswirkung. Wenn aber durch das Durcheinander sogar Nachrichten verlorengehen, dann ist das was ganz anderes.

Aber schon mal Danke für das ganze hin-und-her bauen. Ich kann mir das aber dann erst im Mai richtig anschauen.

Gruß,
Andreas.

krikan · 09 März 2016, 13:48:38

Danke für die Codeanpassungen.

Habe gerade Schnelltest mit Log-Änderung gemacht. Das 2x 0013-ACK habe ich noch nicht nachstellen können, da mir die Zeit fehlt. Hier mal ein Log bei dem nach dem ersten CAN mit fast 1Sek Pause(?) nach meinem Eindruck alles durcheinander läuft. Frage mich auch, ob ein zu stark belasteter FHEM-Server auf den seltsamen Ablauf Einluß haben könnte.

Code Auswählen

2016.03.09 13:31:32.005 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass ASSOCIATION
2016.03.09 13:31:32.010 1: processSendStack get:1304038613852504
2016.03.09 13:31:32.015 5: ZWDongle_Write 001304038613852504 (e345c452)
2016.03.09 13:31:32.022 5: SW: 010a001304038613852504d0
2016.03.09 13:31:32.061 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass CONFIGURATION
2016.03.09 13:31:32.094 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass FIRMWARE_UPDATE_MD
2016.03.09 13:31:32.122 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 13:31:32.148 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 13:31:32.174 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_SPECIFIC
2016.03.09 13:31:32.200 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 13:31:32.223 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 13:31:32.244 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass POWERLEVEL
2016.03.09 13:31:32.266 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass PROTECTION
2016.03.09 13:31:32.289 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SCENE_ACTIVATION
2016.03.09 13:31:32.313 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 13:31:32.342 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 13:31:32.370 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.401 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.431 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.456 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_MULTILEVEL
2016.03.09 13:31:32.477 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass VERSION
2016.03.09 13:31:32.535 5: ACK received, WaitForAck=>2 for 010a001304038613852504d0
2016.03.09 13:31:32.537 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:32.539 5: SW: 06
2016.03.09 13:31:32.544 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:32.566 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:32.568 5: SW: 06
2016.03.09 13:31:32.572 5: device ack reveived, removing 010a001304038613852504d0 from dongle sendstack
2016.03.09 13:31:32.575 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:32.579 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:32.581 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:32.587 1: processSendStack sentget:1304038613852504
2016.03.09 13:31:32.598 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 13:31:32.600 5: SW: 06
2016.03.09 13:31:32.605 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 13:31:32.610 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 13:31:32.616 1: processSendStack sentackget:1304038613852504
2016.03.09 13:31:32.622 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.09 13:31:32.628 5: SW: 010a00130403861370250425
2016.03.09 13:31:32.643 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.09 13:31:33.572 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 13:31:33.574 5: SW: 06
2016.03.09 13:31:33.580 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 13:31:33.583 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 13:31:33.588 1: processSendStack sentget:1304038613702504
2016.03.09 13:31:33.593 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.09 13:31:33.597 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130403861370250425
2016.03.09 13:31:33.598 5: SW: 010a00130403861370250425
2016.03.09 13:31:33.611 5: ACK received, WaitForAck=>2 for 010a00130403861370250425
2016.03.09 13:31:33.613 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:33.615 5: SW: 06
2016.03.09 13:31:33.619 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:33.664 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:33.667 5: SW: 06
2016.03.09 13:31:33.670 5: device ack reveived, removing 010a00130403861370250425 from dongle sendstack
2016.03.09 13:31:33.673 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:33.676 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:33.678 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:33.683 1: processSendStack sentget:13040386137a2504
2016.03.09 13:31:33.687 5: SW: 010a0013040386137a25042f
2016.03.09 13:31:33.698 5: ACK received, WaitForAck=>2 for 010a0013040386137a25042f
2016.03.09 13:31:33.700 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:33.702 5: SW: 06
2016.03.09 13:31:33.707 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:33.719 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147001
2016.03.09 13:31:33.721 5: SW: 06
2016.03.09 13:31:33.725 5: ZWDongle_0 dispatch 000400040486147001
2016.03.09 13:31:33.728 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147001 CB:00
2016.03.09 13:31:33.734 1: processSendStack sentackget:13040386137a2504
2016.03.09 13:31:33.739 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 13:31:33.743 4: no response from device, removing 010a0013040386137a25042f from dongle sendstack
2016.03.09 13:31:33.745 5: SW: 010a001304038613912504c4
2016.03.09 13:31:33.758 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 13:31:33.761 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:33.762 5: SW: 06
2016.03.09 13:31:33.767 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:33.774 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:33.775 1: processSendStack sentget:1304038613912504
2016.03.09 13:31:33.780 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 13:31:34.146 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:34.148 5: SW: 06
2016.03.09 13:31:34.152 5: device ack reveived, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 13:31:34.155 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:34.159 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:34.162 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:34.168 1: processSendStack sentget:1304038613912504
2016.03.09 13:31:34.172 5: SW: 010a001304038613912504c4
2016.03.09 13:31:34.187 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 13:31:34.189 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:34.191 5: SW: 06
2016.03.09 13:31:34.196 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:34.807 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486149101
2016.03.09 13:31:34.809 5: SW: 06
2016.03.09 13:31:34.814 5: ZWDongle_0 dispatch 000400040486149101
2016.03.09 13:31:34.818 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486149101 CB:00
2016.03.09 13:31:34.823 1: processSendStack sentackget:1304038613912504
2016.03.09 13:31:34.829 5: ZWDongle_Write 001304038613722504 (e345c452)
2016.03.09 13:31:34.833 4: no response from device, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 13:31:34.836 5: SW: 010a00130403861372250427
2016.03.09 13:31:34.851 5: ACK received, WaitForAck=>2 for 010a00130403861372250427
2016.03.09 13:31:34.854 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:34.856 5: SW: 06
2016.03.09 13:31:34.861 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:34.868 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:34.870 1: processSendStack sentget:1304038613722504
2016.03.09 13:31:34.875 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.09 13:31:34.916 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:34.919 5: SW: 06
2016.03.09 13:31:34.923 5: device ack reveived, removing 010a00130403861372250427 from dongle sendstack
2016.03.09 13:31:34.926 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:34.930 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:34.932 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:34.938 1: processSendStack sentget:1304038613322504
2016.03.09 13:31:34.943 5: SW: 010a00130403861332250467
2016.03.09 13:31:34.955 5: ACK received, WaitForAck=>2 for 010a00130403861332250467
2016.03.09 13:31:34.957 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:34.958 5: SW: 06
2016.03.09 13:31:34.963 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:35.524 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:35.526 5: SW: 06
2016.03.09 13:31:35.529 5: device ack reveived, removing 010a00130403861332250467 from dongle sendstack
2016.03.09 13:31:35.532 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:35.535 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:35.538 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:35.543 1: processSendStack sentackget:1304038613322504
2016.03.09 13:31:35.549 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.09 13:31:35.555 5: SW: 010a00130403861332250467
2016.03.09 13:31:35.569 5: ACK received, WaitForAck=>2 for 010a00130403861332250467
2016.03.09 13:31:35.572 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:35.574 5: SW: 06
2016.03.09 13:31:35.578 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:36.053 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:36.056 5: SW: 06
2016.03.09 13:31:36.060 5: device ack reveived, removing 010a00130403861332250467 from dongle sendstack
2016.03.09 13:31:36.063 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:36.066 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:36.068 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:36.075 1: processSendStack sentget:1304038613322504
2016.03.09 13:31:40.563 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613322504
2016.03.09 13:31:40.566 1: processSendStack sentackget:1304038613322504
2016.03.09 13:31:40.571 5: ZWDongle_Write 001304038613732504 (e345c452)
2016.03.09 13:31:40.576 5: SW: 010a00130403861373250426
2016.03.09 13:31:40.589 5: ACK received, WaitForAck=>2 for 010a00130403861373250426
2016.03.09 13:31:40.593 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:40.595 5: SW: 06
2016.03.09 13:31:40.600 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:40.629 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:40.630 5: SW: 06
2016.03.09 13:31:40.634 5: device ack reveived, removing 010a00130403861373250426 from dongle sendstack
2016.03.09 13:31:40.637 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:40.639 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:40.642 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:40.647 1: processSendStack sentget:1304038613732504
2016.03.09 13:31:45.588 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613732504
2016.03.09 13:31:45.591 1: processSendStack sentackget:1304038613732504
2016.03.09 13:31:45.596 5: ZWDongle_Write 001304038613752504 (e345c452)
2016.03.09 13:31:45.600 5: SW: 010a00130403861375250420
2016.03.09 13:31:45.615 5: ACK received, WaitForAck=>2 for 010a00130403861375250420
2016.03.09 13:31:45.617 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:45.619 5: SW: 06
2016.03.09 13:31:45.623 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:45.651 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:45.652 5: SW: 06
2016.03.09 13:31:45.656 5: device ack reveived, removing 010a00130403861375250420 from dongle sendstack
2016.03.09 13:31:45.659 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:45.661 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:45.664 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:45.668 1: processSendStack sentget:1304038613752504
2016.03.09 13:31:45.748 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147502
2016.03.09 13:31:45.750 5: SW: 06
2016.03.09 13:31:45.756 5: ZWDongle_0 dispatch 000400040486147502
2016.03.09 13:31:45.759 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147502 CB:00
2016.03.09 13:31:45.765 1: processSendStack sentackget:1304038613752504
2016.03.09 13:31:45.770 5: ZWDongle_Write 0013040386132b2504 (e345c452)
2016.03.09 13:31:45.775 5: SW: 010a0013040386132b25047e
2016.03.09 13:31:45.790 5: ACK received, WaitForAck=>2 for 010a0013040386132b25047e
2016.03.09 13:31:45.793 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:45.795 5: SW: 06
2016.03.09 13:31:45.800 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:46.366 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142b01
2016.03.09 13:31:46.368 5: SW: 06
2016.03.09 13:31:46.372 5: ZWDongle_0 dispatch 000400040486142b01
2016.03.09 13:31:46.376 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142b01 CB:00
2016.03.09 13:31:46.381 1: processSendStack sentget:13040386132b2504
2016.03.09 13:31:46.387 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.09 13:31:46.392 4: no response from device, removing 010a0013040386132b25047e from dongle sendstack
2016.03.09 13:31:46.395 5: SW: 010a00130403861331250464
2016.03.09 13:31:46.413 5: ACK received, WaitForAck=>2 for 010a00130403861331250464
2016.03.09 13:31:46.417 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:46.419 5: SW: 06
2016.03.09 13:31:46.425 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:46.434 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:46.437 1: processSendStack sentget:1304038613312504
2016.03.09 13:31:46.444 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.09 13:31:46.465 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:46.468 5: SW: 06
2016.03.09 13:31:46.472 5: device ack reveived, removing 010a00130403861331250464 from dongle sendstack
2016.03.09 13:31:46.477 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:46.481 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:46.485 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:46.491 1: processSendStack sentget:1304038613312504
2016.03.09 13:31:46.497 5: SW: 010a00130403861331250464
2016.03.09 13:31:46.514 5: ACK received, WaitForAck=>2 for 010a00130403861331250464
2016.03.09 13:31:46.517 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:46.519 5: SW: 06
2016.03.09 13:31:46.524 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:48.550 4: no response from device, removing 010a00130403861331250464 from dongle sendstack
2016.03.09 13:31:51.455 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613312504
2016.03.09 13:31:51.457 1: processSendStack sentackget:1304038613312504
2016.03.09 13:31:51.463 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:51.469 5: SW: 010a00130403861325250470
2016.03.09 13:31:51.484 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:51.704 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:51.706 5: SW: 06
2016.03.09 13:31:51.711 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:51.781 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:51.783 5: SW: 06
2016.03.09 13:31:51.789 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:51.792 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:51.797 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:51.800 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:51.807 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:52.601 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:31:52.603 5: SW: 06
2016.03.09 13:31:52.608 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:31:52.611 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:31:52.613 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:31:56.480 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613252504
2016.03.09 13:31:56.486 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:56.490 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:56.495 5: SW: 010a00130403861325250470
2016.03.09 13:31:56.506 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:56.508 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:56.510 5: SW: 06
2016.03.09 13:31:56.515 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:57.025 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:57.028 5: SW: 06
2016.03.09 13:31:57.031 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:57.035 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:57.038 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:57.040 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:57.046 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:57.165 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142501
2016.03.09 13:31:57.167 5: SW: 06
2016.03.09 13:31:57.174 5: ZWDongle_0 dispatch 000400040486142501
2016.03.09 13:31:57.178 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142501 CB:00
2016.03.09 13:31:57.186 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:57.192 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:57.197 5: SW: 010a00130403861325250470
2016.03.09 13:31:57.217 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:57.220 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:57.222 5: SW: 06
2016.03.09 13:31:57.228 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:57.359 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:57.361 5: SW: 06
2016.03.09 13:31:57.365 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:57.369 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:57.373 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:57.375 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:57.381 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:57.408 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142501
2016.03.09 13:31:57.410 5: SW: 06
2016.03.09 13:31:57.415 5: ZWDongle_0 dispatch 000400040486142501
2016.03.09 13:31:57.418 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142501 CB:00
2016.03.09 13:31:57.424 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:57.429 5: ZWDongle_Write 001304038613262504 (e345c452)
2016.03.09 13:31:57.432 5: SW: 010a00130403861326250473
2016.03.09 13:31:57.447 5: ACK received, WaitForAck=>2 for 010a00130403861326250473
2016.03.09 13:31:57.449 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:57.451 5: SW: 06
2016.03.09 13:31:57.455 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:59.976 4: no response from device, removing 010a00130403861326250473 from dongle sendstack
2016.03.09 13:32:02.447 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613262504
2016.03.09 13:32:02.449 1: processSendStack sentget:1304038613262504
2016.03.09 13:32:02.456 5: ZWDongle_Write 001304038613862504 (e345c452)
2016.03.09 13:32:02.461 5: SW: 010a001304038613862504d3
2016.03.09 13:32:02.476 5: ACK received, WaitForAck=>2 for 010a001304038613862504d3
2016.03.09 13:32:02.696 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:32:02.698 5: SW: 06
2016.03.09 13:32:02.703 5: ZWDongle_0 dispatch 011301
2016.03.09 13:32:04.127 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:04.129 5: SW: 06
2016.03.09 13:32:04.133 5: device ack reveived, removing 010a001304038613862504d3 from dongle sendstack
2016.03.09 13:32:04.136 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:04.140 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:04.142 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.488 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613862504
2016.03.09 13:32:12.490 1: processSendStack sentget:1304038613862504
2016.03.09 13:32:12.502 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.504 5: SW: 06
2016.03.09 13:32:12.510 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.514 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.516 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.527 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.528 5: SW: 06
2016.03.09 13:32:12.533 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.536 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.537 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.547 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.549 5: SW: 06
2016.03.09 13:32:12.554 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.558 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.560 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.570 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.571 5: SW: 06
2016.03.09 13:32:12.576 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.578 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.580 2: ZWDongle_0 transmit NO_ACK for 04

krikan · 09 März 2016, 18:42:18

So hier ein Log mit Ausschalten eines Routers während der Abfrage und 2x 0013-ACK: es geht seltsamerweise auch mit knapp 3 Sekunden Pause.

Code Auswählen

2016.03.09 18:09:03.073 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass ASSOCIATION
2016.03.09 18:09:03.076 1: processSendStack get:1304038613852504
2016.03.09 18:09:03.079 5: ZWDongle_Write 001304038613852504 (e345c452)
2016.03.09 18:09:03.083 5: SW: 010a001304038613852504d0
2016.03.09 18:09:03.110 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass CONFIGURATION
2016.03.09 18:09:03.137 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass FIRMWARE_UPDATE_MD
2016.03.09 18:09:03.164 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 18:09:03.191 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 18:09:03.218 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_SPECIFIC
2016.03.09 18:09:03.247 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 18:09:03.278 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 18:09:03.308 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass POWERLEVEL
2016.03.09 18:09:03.338 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass PROTECTION
2016.03.09 18:09:03.368 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SCENE_ACTIVATION
2016.03.09 18:09:03.395 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 18:09:03.417 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 18:09:03.438 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.460 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.481 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.504 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_MULTILEVEL
2016.03.09 18:09:03.525 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass VERSION
2016.03.09 18:09:03.587 5: ACK received, WaitForAck=>2 for 010a001304038613852504d0
2016.03.09 18:09:03.590 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:03.593 5: SW: 06
2016.03.09 18:09:03.599 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:03.616 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:03.618 5: SW: 06
2016.03.09 18:09:03.622 5: device ack reveived, removing 010a001304038613852504d0 from dongle sendstack
2016.03.09 18:09:03.625 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:03.629 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:03.634 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:03.640 1: processSendStack sentget:1304038613852504
2016.03.09 18:09:03.658 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 18:09:03.660 5: SW: 06
2016.03.09 18:09:03.667 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 18:09:03.671 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 18:09:03.677 1: processSendStack sentackget:1304038613852504
2016.03.09 18:09:03.683 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.09 18:09:03.688 5: SW: 010a00130403861370250425
2016.03.09 18:09:03.705 5: ACK received, WaitForAck=>2 for 010a00130403861370250425
2016.03.09 18:09:03.707 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:03.709 5: SW: 06
2016.03.09 18:09:03.713 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:06.659 4: no response from device, removing 010a00130403861370250425 from dongle sendstack
2016.03.09 18:09:06.673 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.675 5: SW: 06
2016.03.09 18:09:06.680 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.684 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.686 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.691 1: processSendStack sentget:1304038613702504
2016.03.09 18:09:06.695 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.697 5: SW: 06
2016.03.09 18:09:06.702 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.706 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.708 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.714 1: processSendStack sentackget:1304038613702504
2016.03.09 18:09:06.718 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.09 18:09:06.723 5: SW: 010a0013040386137a25042f
2016.03.09 18:09:06.730 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.731 5: SW: 06
2016.03.09 18:09:06.736 5: device ack reveived, removing 010a0013040386137a25042f from dongle sendstack
2016.03.09 18:09:06.739 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.742 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.744 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.749 1: processSendStack sentget:13040386137a2504
2016.03.09 18:09:07.289 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147001
2016.03.09 18:09:07.290 5: SW: 06
2016.03.09 18:09:07.295 5: ZWDongle_0 dispatch 000400040486147001
2016.03.09 18:09:07.299 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147001 CB:00
2016.03.09 18:09:07.304 1: processSendStack sentackget:13040386137a2504
2016.03.09 18:09:07.309 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 18:09:07.313 5: SW: 010a001304038613912504c4
2016.03.09 18:09:07.320 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 18:09:07.323 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:07.325 5: SW: 06
2016.03.09 18:09:07.330 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:07.335 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:07.336 5: SW: 06
2016.03.09 18:09:07.340 5: device ack reveived, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 18:09:07.343 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:07.347 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:07.349 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:07.355 1: processSendStack sentget:1304038613912504

Habe versucht mit anderem PC und ZWCul mitzuloggen. Das gelingt mir komischerweise nicht; empfängt nur sehr vereinzelt Nachrichten. Eventuell weil Router und Dongle 100k; Ziel-Gerät 40k.

9zehn75 · 10 März 2016, 10:28:29

Heißt das, mein hier beschriebenes Problem ist möglicherweise gar keins, weil meine Fenstersensoren sehr wohl aufwachen, sich aber nicht per WUN melden, sondern nur mit APPLICATION_UPDATE? Ich bin schon verzweifelt, weil ich bei keinem einzigen meiner elf Fenstersensoren einen manuellen Wake-Up hinbekommen...

krikan · 10 März 2016, 10:38:58

Zitat von: 9zehn75 am 10 März 2016, 10:28:29
Heißt das, mein hier beschriebenes Problem ist möglicherweise gar keins, weil meine Fenstersensoren sehr wohl aufwachen, sich aber nicht per WUN melden, sondern nur mit APPLICATION_UPDATE? Ich bin schon verzweifelt, weil ich bei keinem einzigen meiner elf Fenstersensoren einen manuellen Wake-Up hinbekommen...

Nein.
APPLICATION_UPDATE führte nur bei einer 10_ZWave.pm, die ca. (ca. weil sorceforge streikt) vom 07.03.16-09.03.16 per update verteilt wurde, nicht zur Abarbeitung des Sendstacks. Vorher und aktuell ist alles in Ordnung.