Problem in 00_ZWDongle.pm

Begonnen von gero, 22 Mai 2015, 10:41:13

Vorheriges Thema - Nächstes Thema

gero

Hallo,

ich beschäftige mich erst seit Kurzem mit ZWave. Aber einige Effekte, die ich beobachtet habe, haben mich dazu veranlaßt, doch mal genauer nachzuforschen.
- häufige Meldungen "ZWDongle: wrong checksum:"
- das spontane Ändern der homeId vom Dongle
- das Auftauchen von neuen Endpoints oder Geräten

Zumindest für das erste Problem habe ich die Ursache gefunden und ich bin mir ziemlich sicher, dass die anderen Probleme ebenfalls die gleich Ursache haben.

Problem:
- ZWDongle_Read hängt die gelesenen Daten an $hash->{PARTIAL}
- Falls ein komplettes Frame in den Daten vorhanden ist, wird ZWDongle_Parse aufgerufen, ohne vorher $hash->{PARTIAL} zu aktualisieren.
- ZWDongle_Parse kann Funktionen aufrufen, die ihrerseits ZWDongle_ReadAnswer aufrufen, das wiederum ZWDongle_Read aufruft (Rekursion).
Resultat sind ungültige Frames

Wenn man z.B. bei einem batteriebetriebenen Device über ein Notify auf das Wakeup-Telegramm ein get triggert, kann man den Fehler sehr einfach reproduzieren

define ZWave_SENSOR_BINARY_6.Battery notify ZWave_SENSOR_BINARY_6:wakeup:.* get ZWave_SENSOR_BINARY_6 battery

Ich habe das Logging etwas erweitert. Die Ausgabe "ZWDongle_Read data remaining:..." erfolgt direkt vor dem ZWDongle_Parse Aufruf in der Funktion ZWDongle_Read und Die Ausgabe "ZWDongle_Read partial:... " erfolgt kurz vor Verlassen der ZWDongle_Read Funktion.

Hier das Log für den Gut-Fall:


2015.05.22 09:24:26 5: ZWDongle/RAW: /01080004000602840774
2015.05.22 09:24:26 5: SW: 06
2015.05.22 09:24:26 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.22 09:24:26 5: ZWDongle_Read data remaining:
2015.05.22 09:24:26 5: ZWDongle dispatch 00040006028407
2015.05.22 09:24:26 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.22 09:24:26 2: ZWave get ZWave_SENSOR_BINARY_6 battery
2015.05.22 09:24:26 5: SW: 01080013060280020567
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: arg: battery regexp: ^00040006
2015.05.22 09:24:26 5: ZWDongle/RAW: /06
2015.05.22 09:24:26 5: ZWDongle_Read partial:
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: answ:
2015.05.22 09:24:26 5: ZWDongle/RAW: /0104011301e8
2015.05.22 09:24:26 5: SW: 06
2015.05.22 09:24:26 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 09:24:26 5: ZWDongle_Read data remaining:
2015.05.22 09:24:26 5: ZWDongle dispatch 011301
2015.05.22 09:24:26 5: ZWDongle_Read partial:
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: answ:
2015.05.22 09:24:26 5: ZWDongle/RAW: /01
2015.05.22 09:24:26 5: ZWDongle_Read partial: 01
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: answ:
2015.05.22 09:24:26 5: ZWDongle/RAW: 01/07001354000003bc
2015.05.22 09:24:26 5: SW: 06
2015.05.22 09:24:26 5: ZWDongle_Read ZWDongle: 001354000003
2015.05.22 09:24:26 5: ZWDongle_Read data remaining:
2015.05.22 09:24:26 5: ZWDongle dispatch 001354000003
2015.05.22 09:24:26 4: ZWDongle CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.05.22 09:24:26 4: ZWDongle transmit OK for 54
2015.05.22 09:24:26 5: ZWDongle_Read partial:
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: answ:
2015.05.22 09:24:26 5: ZWDongle/RAW: /0109000400060380036410
2015.05.22 09:24:26 5: SW: 06
2015.05.22 09:24:26 5: ZWDongle_Read ZWDongle: 0004000603800364
2015.05.22 09:24:26 5: ZWDongle_Read data remaining:
2015.05.22 09:24:26 5: ZWDongle_Read partial:
2015.05.22 09:24:26 5: ZWDongle_ReadAnswer: answ: 0004000603800364
2015.05.22 09:24:26 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800364
2015.05.22 09:24:26 3: ZWave_SENSOR_BINARY_6.Battery return value: battery:100 %
2015.05.22 09:24:26 5: ZWDongle_Read partial:


Und hier das Log für den Fehler:


2015.05.22 09:54:24 5: ZWDongle/RAW: /010800040006
2015.05.22 09:54:24 5: ZWDongle_Read partial: 010800040006
2015.05.22 09:54:24 5: ZWDongle/RAW: 010800040006/02840774
2015.05.22 09:54:24 5: SW: 06
2015.05.22 09:54:24 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.22 09:54:24 5: ZWDongle_Read data remaining:
2015.05.22 09:54:24 5: ZWDongle dispatch 00040006028407
2015.05.22 09:54:24 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.22 09:54:24 2: ZWave get ZWave_SENSOR_BINARY_6 battery
2015.05.22 09:54:24 5: SW: 01080013060280020567
2015.05.22 09:54:24 5: ZWDongle_ReadAnswer: arg: battery regexp: ^00040006
2015.05.22 09:54:24 5: ZWDongle/RAW: 010800040006/06
2015.05.22 09:54:24 5: ZWDongle_Read partial: 01080004000606
2015.05.22 09:54:24 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 09:54:24 5: ZWDongle/RAW: 01080004000606/0104011301e8
2015.05.22 09:54:24 1: ZWDongle: wrong checksum: received 01, computed f6 for 0800040006060104
2015.05.22 09:54:24 5: SW: 15
2015.05.22 09:54:24 1: ZWDongle: SOF missing (got 13 instead of 01)
2015.05.22 09:54:24 5: ZWDongle_Read partial: 1301e8
2015.05.22 09:54:24 5: ZWDongle_ReadAnswer: answ: 00040006060104
2015.05.22 09:54:24 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:060104
2015.05.22 09:54:24 3: ZWave_SENSOR_BINARY_6.Battery return value: UNPARSED:UNKNOWN_01 060104
2015.05.22 09:54:24 5: ZWDongle_Read partial:
2015.05.22 09:54:24 5: ZWDongle/RAW: /0104011301e8
2015.05.22 09:54:24 5: SW: 06
2015.05.22 09:54:24 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 09:54:24 5: ZWDongle_Read data remaining:
2015.05.22 09:54:24 5: ZWDongle dispatch 011301
2015.05.22 09:54:24 5: ZWDongle_Read partial:
2015.05.22 09:54:24 5: ZWDongle/RAW: /0109000400
2015.05.22 09:54:24 5: ZWDongle_Read partial: 0109000400
2015.05.22 09:54:24 5: ZWDongle/RAW: 0109000400/060380036410
2015.05.22 09:54:24 5: SW: 06
2015.05.22 09:54:24 5: ZWDongle_Read ZWDongle: 0004000603800364
2015.05.22 09:54:24 5: ZWDongle_Read data remaining:
2015.05.22 09:54:24 5: ZWDongle dispatch 0004000603800364
2015.05.22 09:54:24 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800364
2015.05.22 09:54:24 5: ZWDongle_Read partial:
2015.05.22 09:54:24 5: ZWDongle/RAW: /0107001354000008b7
2015.05.22 09:54:24 5: SW: 06
2015.05.22 09:54:24 5: ZWDongle_Read ZWDongle: 001354000008
2015.05.22 09:54:24 5: ZWDongle_Read data remaining:
2015.05.22 09:54:24 5: ZWDongle dispatch 001354000008
2015.05.22 09:54:24 4: ZWDongle CMD:ZW_SEND_DATA ID:00 ARG:0008
2015.05.22 09:54:24 4: ZWDongle transmit OK for 54
2015.05.22 09:54:24 5: ZWDongle_Read partial:
2015.05.22 09:54:24 5: ZWDongle/RAW: /0109000400060380036410
2015.05.22 09:54:24 5: SW: 06
2015.05.22 09:54:24 5: ZWDongle_Read ZWDongle: 0004000603800364
2015.05.22 09:54:24 5: ZWDongle_Read data remaining:
2015.05.22 09:54:24 5: ZWDongle dispatch 0004000603800364
2015.05.22 09:54:24 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800364
2015.05.22 09:54:24 5: ZWDongle_Read partial:
2015.05.22 09:54:41 5: ZWDongle/RAW: /010c00040005063105
2015.05.22 09:54:41 5: ZWDongle_Read partial: 010c00040005063105
2015.05.22 09:54:41 5: ZWDongle/RAW: 010c00040005063105/0422002ec8
2015.05.22 09:54:41 5: SW: 06
2015.05.22 09:54:41 5: ZWDongle_Read ZWDongle: 000400050631050422002e
2015.05.22 09:54:41 5: ZWDongle_Read data remaining:
2015.05.22 09:54:41 5: ZWDongle dispatch 000400050631050422002e
2015.05.22 09:54:41 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:0631050422002e
2015.05.22 09:54:41 5: ZWDongle_Read partial:



Hier noch ein Beispiel für das Auftauchen eines neuen Gerätes:

2015.05.22 09:04:28 5: ZWDongle/RAW: /01080004
2015.05.22 09:04:28 5: ZWDongle_Read partial: 01080004
2015.05.22 09:04:28 5: ZWDongle/RAW: 01080004/000602840774
2015.05.22 09:04:28 5: SW: 06
2015.05.22 09:04:28 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.22 09:04:28 5: ZWDongle_Read data remaining:
2015.05.22 09:04:28 5: ZWDongle dispatch 00040006028407
2015.05.22 09:04:28 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.22 09:04:28 2: ZWave get ZWave_SENSOR_BINARY_6 battery
2015.05.22 09:04:28 5: SW: 01080013060280020567
2015.05.22 09:04:28 5: ZWDongle/RAW: 01080004/06
2015.05.22 09:04:28 5: ZWDongle_Read partial: 0108000406
2015.05.22 09:04:28 5: ZWDongle/RAW: 0108000406/0104011301e8
2015.05.22 09:04:28 1: ZWDongle: wrong checksum: received 01, computed e2 for 0800040601040113
2015.05.22 09:04:28 5: SW: 15
2015.05.22 09:04:28 1: ZWDongle: SOF missing (got e8 instead of 01)
2015.05.22 09:04:28 5: ZWDongle_Read partial: e8
2015.05.22 09:04:28 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:01 ARG:040113
2015.05.22 09:04:28 3: UNDEFINED ZWave_Node_1 ZWave c9cde420 1, please define it
2015.05.22 09:04:28 5: ZWDongle_Read partial:
2015.05.22 09:04:28 5: ZWDongle/RAW: /0104011301e8
2015.05.22 09:04:28 5: SW: 06
2015.05.22 09:04:28 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 09:04:28 5: ZWDongle_Read data remaining:
2015.05.22 09:04:28 5: ZWDongle dispatch 011301
2015.05.22 09:04:28 5: ZWDongle_Read partial:
2015.05.22 09:04:28 5: ZWDongle/RAW: /0107001354000002bd
2015.05.22 09:04:28 5: SW: 06
2015.05.22 09:04:28 5: ZWDongle_Read ZWDongle: 001354000002
2015.05.22 09:04:28 5: ZWDongle_Read data remaining:
2015.05.22 09:04:28 5: ZWDongle dispatch 001354000002
2015.05.22 09:04:28 4: ZWDongle CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.05.22 09:04:28 4: ZWDongle transmit OK for 54
2015.05.22 09:04:28 5: ZWDongle_Read partial:
2015.05.22 09:04:28 5: ZWDongle/RAW: /01090004000603
2015.05.22 09:04:28 5: ZWDongle_Read partial: 01090004000603
2015.05.22 09:04:28 5: ZWDongle/RAW: 01090004000603/80036410
2015.05.22 09:04:28 5: SW: 06
2015.05.22 09:04:28 5: ZWDongle_Read ZWDongle: 0004000603800364
2015.05.22 09:04:28 5: ZWDongle_Read data remaining:
2015.05.22 09:04:28 5: ZWDongle dispatch 0004000603800364
2015.05.22 09:04:28 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800364
2015.05.22 09:04:28 5: ZWDongle_Read partial:

Hier sieht man meiner Meinung nach noch andere Fehler:
Bei einem SOF-Fehler, wird die while-Schleife beendet und $msg als return value zurückgeliefert, obwohl die regexp nicht matched.
In diesem Fall sollte zumindest msg auf undef gesetzt werden.

Zitat
    if($fb ne "01") {   # SOF
      Log3 $name, 1, "$name: SOF missing (got $fb instead of 01)";
      undef @{$hash->{SendStack}};
      $msg = undef;
      last;
    }
Aber evtl. sollte man auch alle empfangenen Daten verwerfen oder den Buffer nach einem gültigen Frame durchsuchen.

Eine mögliche Lösung wäre es  $hash->{PARTIAL}  vor der Rekursion, also vor dem Aufruf von ZWDongle_Parse zu aktualisieren.
Zitat
    # upper layer function may call ZWDongle_Get -> ZWDongle_Read
    # so we have to update $hash->{PARTIAL} at this point
   $hash->{PARTIAL} = $data;   

    ZWDongle_Parse($hash, $name, $msg);

Aber ich halte die Rekursion von Read -> Parse -> ... -> ReadAnswer -> Read -> ... insgesamt für ein unglückliches und gefährliches Konstrukt. Vielleicht sollte man hier eher über ein SW-Redesign nachdenken.
Dafür spricht auch ein weiteres Problem:
Ein get läuft unweigerlich in ein Timeout, wenn sich ein anderes Kommando im sendstack befindet:

2015.05.22 10:09:49 2: ZWave set ZWave_SENSOR_BINARY_6 wakeupInterval

2015.05.22 10:14:05 5: ZWDongle/RAW: /01
2015.05.22 10:14:05 5: ZWDongle_Read partial: 01
2015.05.22 10:14:05 5: ZWDongle/RAW: 01/0c0004000506310504220027c1
2015.05.22 10:14:05 5: SW: 06
2015.05.22 10:14:05 5: ZWDongle_Read ZWDongle: 0004000506310504220027
2015.05.22 10:14:05 5: ZWDongle_Read data remaining:
2015.05.22 10:14:05 5: ZWDongle dispatch 0004000506310504220027
2015.05.22 10:14:05 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:06310504220027
2015.05.22 10:14:05 5: ZWDongle_Read partial:
2015.05.22 10:14:22 5: ZWDongle/RAW: /01080004000602840774
2015.05.22 10:14:22 5: SW: 06
2015.05.22 10:14:22 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.22 10:14:22 5: ZWDongle_Read data remaining:
2015.05.22 10:14:22 5: ZWDongle dispatch 00040006028407
2015.05.22 10:14:22 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.22 10:14:22 5: SW: 010d00130606840400003c0105065f
2015.05.22 10:14:22 2: ZWave get ZWave_SENSOR_BINARY_6 battery
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: arg: battery regexp: ^00040006
2015.05.22 10:14:22 5: ZWDongle/RAW: /060104011301e8
2015.05.22 10:14:22 5: SW: 06
2015.05.22 10:14:22 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 10:14:22 5: ZWDongle_Read data remaining:
2015.05.22 10:14:22 5: ZWDongle dispatch 011301
2015.05.22 10:14:22 5: ZWDongle_Read partial:
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 10:14:22 5: ZWDongle/RAW: /01
2015.05.22 10:14:22 5: ZWDongle_Read partial: 01
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 10:14:22 5: ZWDongle/RAW: 01/07001306000004e9
2015.05.22 10:14:22 5: SW: 06
2015.05.22 10:14:22 5: ZWDongle_Read ZWDongle: 001306000004
2015.05.22 10:14:22 5: ZWDongle_Read data remaining:
2015.05.22 10:14:22 5: ZWDongle dispatch 001306000004
2015.05.22 10:14:22 4: ZWDongle CMD:ZW_SEND_DATA ID:00 ARG:0004
2015.05.22 10:14:22 5: SW: 01080013060284080569
2015.05.22 10:14:22 4: ZWDongle transmit OK for 06
2015.05.22 10:14:22 5: ZWDongle_Read partial:
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 10:14:22 5: ZWDongle/RAW: /06
2015.05.22 10:14:22 5: ZWDongle_Read partial:
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 10:14:22 5: ZWDongle/RAW: /0104011301e8
2015.05.22 10:14:22 5: SW: 06
2015.05.22 10:14:22 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 10:14:22 5: ZWDongle_Read data remaining:
2015.05.22 10:14:22 5: ZWDongle dispatch 011301
2015.05.22 10:14:22 5: ZWDongle_Read partial:
2015.05.22 10:14:22 5: ZWDongle_ReadAnswer: answ: undef
2015.05.22 10:14:25 3: ZWave_SENSOR_BINARY_6.Battery return value: Timeout reading answer for get battery
2015.05.22 10:14:25 5: ZWDongle_Read partial:
2015.05.22 10:14:25 5: SW: 01080013060280020567
2015.05.22 10:14:26 5: ZWDongle/RAW: /060104011301e8
2015.05.22 10:14:26 5: SW: 06
2015.05.22 10:14:26 5: ZWDongle_Read ZWDongle: 011301
2015.05.22 10:14:26 5: ZWDongle_Read data remaining:
2015.05.22 10:14:26 5: ZWDongle dispatch 011301
2015.05.22 10:14:26 5: ZWDongle_Read partial:

Die ZWDongle_Write Funktion setzt zwar einen InternalTimer mit einer Sekunde für das nächste Kommando. Aber solange in der Funktion ZWDongle_ReadAnswer auf eine passende Antwort gewartet wird, wird der Timer nicht ausgeführt.

Außerdem bin ich mir nicht sicher, ob die korrekte Zuordnung eines Frames durch die regexp 100% gesichert ist. Dazu überblicke ich die Implementierung (noch) zu wenig.

Meiner Meinung nach sollte die Funktion ZWDongle_ReadAnswer komplett rausdesigned und das get asynchron realisiert werden. Ich bin mir allerdings bewußt, dass das nicht ganz einfach wird.

Ich liefere absichtlich noch keinen Patch, weil ich mir noch nicht sicher bin, ob die von mir vorgeschlagenen minimalen Änderungen wirklich eine Lösung sind.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

micha80

Und ich dachte, das ist nur bei mir so...
Wenn du Hilfe beim testen benötigst, bin ich gern dabei :)

gero

Danke für das Angebot. Mit den beiden oben genannten Änderungen, habe ich bisher keine "wrong checksum", SOF, "undefined device" oder homeId-Fehler.
Ich komme wahrscheinlich erst morgen dazu einen Patch zum Testen zu erzeugen.
Gruß,
Gero

Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

micha80

soweit so richtig?

raspi2:~/fhem-code/fhem/FHEM# svn diff
Index: 00_ZWDongle.pm
===================================================================
--- 00_ZWDongle.pm      (Revision 8620)
+++ 00_ZWDongle.pm      (Arbeitskopie)
@@ -522,6 +522,8 @@
     if($fb ne "01") {   # SOF
       Log3 $name, 1, "$name: SOF missing (got $fb instead of 01)";
       undef @{$hash->{SendStack}};
+      #changed_for: #37418
+      $msg = undef;
       last;
     }

@@ -546,6 +548,10 @@
     Log3 $name, 5, "ZWDongle_Read $name: $msg";

     last if(defined($local) && (!defined($regexp) || ($msg =~ m/$regexp/)));
+    #changed_for: #37418
+    # upper layer function may call ZWDongle_Get -> ZWDongle_Read
+    # so we have to update $hash->{PARTIAL} at this point
+    $hash->{PARTIAL} = $data;
     ZWDongle_Parse($hash, $name, $msg);
     $msg = undef;
   }


gero

Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

gero

Anbei ein Patch mit minimalen Änderungen, der zumindest einige wichtige Probleme löst.

Ungelöst bleibt
- Das Nichtabarbeiten des sendstacks, wenn in der Funktion ReadAnswer gewartet wird.
- Das unzureichende Patternmatching, um Anworten eindeutig einer Anfrage zuzuordnen. (Warum wird als Pattern nur "^000400$id" genommen und nicht auch zusätzlich der Befehlscode?)

Vor allem letzteres muß noch dringend gelöst werden, um einen wirklich stabilen ZWave-Betrieb zu gewährleisten.
Hier noch ein Beispiel für eine falsche Zuordnung:
2015.05.23 23:30:41 5: ZWDongle/RAW: /01080004000602840774
2015.05.23 23:30:41 5: SW: 06
2015.05.23 23:30:41 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.23 23:30:41 5: ZWDongle dispatch 00040006028407
2015.05.23 23:30:41 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.23 23:30:41 2: ZWave get ZWave_SENSOR_BINARY_6 battery
2015.05.23 23:30:41 5: SW: 01080013060280020567
2015.05.23 23:30:41 5: ZWDongle_ReadAnswer: arg: battery regexp: ^00040006
2015.05.23 23:30:42 5: ZWDongle/RAW: /01080004000602
2015.05.23 23:30:42 5: ZWDongle/RAW: 01080004000602/84077418
2015.05.23 23:30:42 5: SW: 06
2015.05.23 23:30:42 5: ZWDongle_Read ZWDongle: 00040006028407
2015.05.23 23:30:42 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.05.23 23:30:42 3: ZWave_SENSOR_BINARY_6.Battery return value: wakeup:notification
2015.05.23 23:30:42 4: ZWDongle: CANCEL received, retransmitting.
2015.05.23 23:30:42 5: SW: 01080013060280020567
2015.05.23 23:30:42 5: ZWDongle/RAW: /060104011301e8
2015.05.23 23:30:42 5: SW: 06
2015.05.23 23:30:42 5: ZWDongle_Read ZWDongle: 011301
2015.05.23 23:30:42 5: ZWDongle dispatch 011301
2015.05.23 23:30:42 5: ZWDongle/RAW: /01
2015.05.23 23:30:42 5: ZWDongle/RAW: 01/09000400060380036410
2015.05.23 23:30:42 5: SW: 06
2015.05.23 23:30:42 5: ZWDongle_Read ZWDongle: 0004000603800364
2015.05.23 23:30:42 5: ZWDongle dispatch 0004000603800364
2015.05.23 23:30:42 4: ZWDongle CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800364


Einen Patch für die 00_CUL.pm habe ich ebenfalls vorbereitet. Die Datei hat zwar nichts mit ZWave zu tun, ist aber ebenfalls von ähnlichen Problemen betroffen.
In welchen anderen Dateien sich ähnliche Probleme finden, kann ich leider nicht überblicken.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

rudolfkoenig

Die teilweise verdauten Daten in PARTIAL zu merken, waehrend man Dispatch aufruft, ist jedenfalls richtig, hab dein Patch uebernommen. Die andere Aenderung bei SOF kommt nur bei CRC-Fehler zum Einsatz, das Problem sollte mAn nach auch da geloest werden: habe die Zeile dorthin geschoben.

"Das unzureichende Patternmatching" kann auch auftauchen, ich habe das Regexp jetzt mit der Klasse ergaenzt, sollte in den meisten Faellen reichen.

Das Problem der "Nichtabarbeiten des sendstacks" sehe ich noch nicht.

gero

Zitat von: rudolfkoenig am 24 Mai 2015, 13:45:23
Die teilweise verdauten Daten in PARTIAL zu merken, waehrend man Dispatch aufruft, ist jedenfalls richtig, hab dein Patch uebernommen. Die andere Aenderung bei SOF kommt nur bei CRC-Fehler zum Einsatz, das Problem sollte mAn nach auch da geloest werden: habe die Zeile dorthin geschoben.

"Das unzureichende Patternmatching" kann auch auftauchen, ich habe das Regexp jetzt mit der Klasse ergaenzt, sollte in den meisten Faellen reichen.
Danke für das Einpflegen der Änderungen und das Erweitern des Patternmatchings.

Zitat von: rudolfkoenig am 24 Mai 2015, 13:45:23
Das Problem der "Nichtabarbeiten des sendstacks" sehe ich noch nicht.
Das Problem gibt es scheinbar doch nicht. Ich hatte mich durch ein Log etwas in die Irre führen lassen.

Es gehört zwar nicht zu ZWave. Aber, da wir am Beispiel von 00_ZWDongle.pm die Problematik identifiziert haben, poste ich trotzdem hier einen Patch für die 00_CUL.pm.
Ich nehme an, dass auch viele andere Modulauthoren, deine Low-Level-Module als Vorlage genommen haben und dass daher auch andere Module von ähnlichen Problemen betroffen sein könnten. Wäre es nicht sinnvoll die entsprechenden Authoren darauf aufmerksam zu machen?

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

rudolfkoenig

Habs eingebaut.

Ich glaube das Problem tritt beim CUL deutlich seltener auf, da es nicht ueblich ist auf eine Nachricht hin eine Abfrage zu machen, wie das beim batteriebetriebenen ZWave Geraeten der Fall ist. Ich habe aber kein Problem damit, wenn du Modul-Autoren darauf aufmerksam machen willst.

gero

Du hast recht: In den meisten Modulen ist der Aufruf von Read -> Parse -> Get -> ReadAnswer wahrscheinlich eher selten. Aber falls doch, kommt es zu evtl. schwer analysierbaren Fehlern. Und eine saubere Basiskommunikation halte ich auch für zukünfigte Module für sehr wichtig.
Ich werde mal nachsehen, welche Module potentiell betroffen sind.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

krikan

#10
Hallo Gero, Hallo Rudi,

vermutlich durch die hier diskutierten Änderungen der 00_ZWDongle.pm werden bei mir nun anscheinend Befehle an die Geräte mehrfach  (bis zum Abbruch nach 3 Versuchen) verschickt und auch mehrfach verarbeitet.

In den nachfolgenden Logs kann man das mMn erkennen:
2015.06.05 19:48:34 2: ZWave get ZWave_SWITCH_BINARY_6 powerlevelTest
2015.06.05 19:48:34 5: ZWDongle_Write msg 130602730505
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: sending msg 01080013060273050593
2015.06.05 19:48:34 5: SW: 01080013060273050593
2015.06.05 19:48:34 4: ZWDongle_ReadAnswer arg:powerlevelTest regexp:^00040006..73
2015.06.05 19:48:34 5: ZWDongle_ReadAnswer: read 7 bytes
2015.06.05 19:48:34 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:48:34 5: ZWDongle_0: ACK received
2015.06.05 19:48:34 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:34 5: SW: 06
2015.06.05 19:48:34 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:48:34 5: ZWDongle_0 dispatch 011301
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:34 5: ZWDongle_Read returning local msg undef hash PARTIAL:
2015.06.05 19:48:34 5: ZWDongle_ReadAnswer: read 14 bytes
2015.06.05 19:48:34 5: ZWDongle RAW buffer: 010c0004000606730604010046c1
2015.06.05 19:48:34 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:34 5: SW: 06
2015.06.05 19:48:34 5: ZWDongle_Read ZWDongle_0: processing 0004000606730604010046
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:34 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:34 5: ZWDongle_Read returning local msg 0004000606730604010046 hash PARTIAL:
2015.06.05 19:48:35 5: ZWDongle_ReadAnswer: returning 0004000606730604010046
2015.06.05 19:48:35 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:06730604010046
2015.06.05 19:48:36 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:36 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:48:36 5: ZWave_ProcessSendStack: sending msg 01080013060273050593
2015.06.05 19:48:36 5: SW: 01080013060273050593
2015.06.05 19:48:36 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:48:36 5: ZWDongle_0: ACK received
2015.06.05 19:48:36 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:36 5: SW: 06
2015.06.05 19:48:36 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:48:36 5: ZWDongle_0 dispatch 011301
2015.06.05 19:48:36 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:36 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:36 5: ZWDongle RAW buffer: 010c0004000606730604010046c1
2015.06.05 19:48:36 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:36 5: SW: 06
2015.06.05 19:48:36 5: ZWDongle_Read ZWDongle_0: processing 0004000606730604010046
2015.06.05 19:48:36 5: ZWDongle_0 dispatch 0004000606730604010046
2015.06.05 19:48:36 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:06730604010046
2015.06.05 19:48:37 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:37 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:38 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:38 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:48:38 5: ZWave_ProcessSendStack: sending msg 01080013060273050593
2015.06.05 19:48:38 5: SW: 01080013060273050593
2015.06.05 19:48:38 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:48:38 5: ZWDongle_0: ACK received
2015.06.05 19:48:38 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:38 5: SW: 06
2015.06.05 19:48:38 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:48:38 5: ZWDongle_0 dispatch 011301
2015.06.05 19:48:38 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:38 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:38 5: ZWDongle RAW buffer: 010c0004000606730604010046c1
2015.06.05 19:48:38 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:38 5: SW: 06
2015.06.05 19:48:38 5: ZWDongle_Read ZWDongle_0: processing 0004000606730604010046
2015.06.05 19:48:38 5: ZWDongle_0 dispatch 0004000606730604010046
2015.06.05 19:48:38 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:06730604010046
2015.06.05 19:48:39 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:39 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:43 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:43 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:48:43 5: ZWave_ProcessSendStack: sending msg 01080013060273050593
2015.06.05 19:48:43 5: SW: 01080013060273050593
2015.06.05 19:48:44 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:48:44 5: ZWDongle_0: ACK received
2015.06.05 19:48:44 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:44 5: SW: 06
2015.06.05 19:48:44 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:48:44 5: ZWDongle_0 dispatch 011301
2015.06.05 19:48:44 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:44 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:48:44 5: ZWDongle RAW buffer: 010c0004000606730604010046c1
2015.06.05 19:48:44 5: ZWDongle_Read -> sending ACK
2015.06.05 19:48:44 5: SW: 06
2015.06.05 19:48:44 5: ZWDongle_Read ZWDongle_0: processing 0004000606730604010046
2015.06.05 19:48:44 5: ZWDongle_0 dispatch 0004000606730604010046
2015.06.05 19:48:44 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:06730604010046
2015.06.05 19:48:45 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:48:45 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:48:45 1: ZWave_ProcessSendStack: max send retrys reached -> cancel sending

Obwohl die Antwort auf die Abfrage bereits gekommen ist, wird die Anfrage nochmals verschickt. Auch das wird wieder beantwortet und dann kommt der Abbruch.

Hier das gleiche für eine andere Abfrage. Ich kann das beliebig reproduzieren.
015.06.05 19:51:56 2: ZWave get ZWave_SWITCH_BINARY_6 version
2015.06.05 19:51:56 5: ZWDongle_Write msg 130602861105
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: sending msg 01080013060286110572
2015.06.05 19:51:56 5: SW: 01080013060286110572
2015.06.05 19:51:56 4: ZWDongle_ReadAnswer arg:version regexp:^00040006..86
2015.06.05 19:51:56 5: ZWDongle_ReadAnswer: read 7 bytes
2015.06.05 19:51:56 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:51:56 5: ZWDongle_0: ACK received
2015.06.05 19:51:56 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:56 5: SW: 06
2015.06.05 19:51:56 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:51:56 5: ZWDongle_0 dispatch 011301
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:51:56 5: ZWDongle_Read returning local msg undef hash PARTIAL:
2015.06.05 19:51:56 5: ZWDongle_ReadAnswer: read 17 bytes
2015.06.05 19:51:56 5: ZWDongle RAW buffer: 010f0004000609861203035c0318500078
2015.06.05 19:51:56 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:56 5: SW: 06
2015.06.05 19:51:56 5: ZWDongle_Read ZWDongle_0: processing 0004000609861203035c03185000
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:56 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:51:56 5: ZWDongle_Read returning local msg 0004000609861203035c03185000 hash PARTIAL:
2015.06.05 19:51:56 5: ZWDongle_ReadAnswer: returning 0004000609861203035c03185000
2015.06.05 19:51:56 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:09861203035c03185000
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:57 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: sending msg 01080013060286110572
2015.06.05 19:51:57 5: SW: 01080013060286110572
2015.06.05 19:51:57 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:51:57 5: ZWDongle_0: ACK received
2015.06.05 19:51:57 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:57 5: SW: 06
2015.06.05 19:51:57 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:51:57 5: ZWDongle_0 dispatch 011301
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:51:57 5: ZWDongle RAW buffer: 010f0004000609861203035c0318500078
2015.06.05 19:51:57 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:57 5: SW: 06
2015.06.05 19:51:57 5: ZWDongle_Read ZWDongle_0: processing 0004000609861203035c03185000
2015.06.05 19:51:57 5: ZWDongle_0 dispatch 0004000609861203035c03185000
2015.06.05 19:51:57 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:09861203035c03185000
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:57 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:51:58 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:58 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:51:58 5: ZWave_ProcessSendStack: sending msg 01080013060286110572
2015.06.05 19:51:58 5: SW: 01080013060286110572
2015.06.05 19:51:58 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:51:58 5: ZWDongle_0: ACK received
2015.06.05 19:51:58 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:58 5: SW: 06
2015.06.05 19:51:58 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:51:58 5: ZWDongle_0 dispatch 011301
2015.06.05 19:51:58 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:58 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:51:58 5: ZWDongle RAW buffer: 010f0004000609861203035c0318500078
2015.06.05 19:51:58 5: ZWDongle_Read -> sending ACK
2015.06.05 19:51:58 5: SW: 06
2015.06.05 19:51:58 5: ZWDongle_Read ZWDongle_0: processing 0004000609861203035c03185000
2015.06.05 19:51:58 5: ZWDongle_0 dispatch 0004000609861203035c03185000
2015.06.05 19:51:58 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:09861203035c03185000
2015.06.05 19:51:59 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:51:59 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:52:00 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: sending msg 01080013060286110572
2015.06.05 19:52:00 5: SW: 01080013060286110572
2015.06.05 19:52:00 5: ZWDongle RAW buffer: 060104011301e8
2015.06.05 19:52:00 5: ZWDongle_0: ACK received
2015.06.05 19:52:00 5: ZWDongle_Read -> sending ACK
2015.06.05 19:52:00 5: SW: 06
2015.06.05 19:52:00 5: ZWDongle_Read ZWDongle_0: processing 011301
2015.06.05 19:52:00 5: ZWDongle_0 dispatch 011301
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:52:00 5: ZWDongle RAW buffer: 010f0004000609861203035c0318500078
2015.06.05 19:52:00 5: ZWDongle_Read -> sending ACK
2015.06.05 19:52:00 5: SW: 06
2015.06.05 19:52:00 5: ZWDongle_Read ZWDongle_0: processing 0004000609861203035c03185000
2015.06.05 19:52:00 5: ZWDongle_0 dispatch 0004000609861203035c03185000
2015.06.05 19:52:00 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:09861203035c03185000
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:52:00 5: ZWave_ProcessSendStack: waiting for ACK -> check again
2015.06.05 19:52:01 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 1
2015.06.05 19:52:01 2: ZWave_ProcessSendStack: timeout sending message -> trigger resend
2015.06.05 19:52:01 1: ZWave_ProcessSendStack: max send retrys reached -> cancel sending


Nach meiner Meinung sollte das so nicht sein oder übersehe/mißinterpretiere ich etwas?

Wenn ich mir openzwave anschaue, wird dort nach meinem Verständnis bei fehlendem ACK auch nicht mehr mehrfach verschickt.
Aus https://github.com/OpenZWave/open-zwave/blob/f99b8b35307f7bcc5a8e140afe895cf7eaf28574/cpp/src/Defs.h:
Zitat
#define MAX_TRIES   1   // set this to one, as I believe now that a ACK failure is indication that the device is offline, hence additional attempts will not work.
Mehrfach (bis zu 7x) wird nach meinem Nicht-Programmiererverständnis (also bitte Nachsicht) nur bei CAN verschickt.

Wäre schön, wenn Ihr Euch das einmal anschauen könntet.

Danke und Gruß, Christian

gero

#11
Tut mit leid, ich kann mich erst in zwei Wochen wieder drum kümmern. Bin im Urlaub.
In den letzten openzwave Sourcen, die ich gesehen habe, stand MAX_TRIES mMn auf 3.
Ich werde es mir aber dann gerne nochmal ansehen.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

krikan

@gero:
Am Meisten wundert mich halt, dass mehrfach verschickt wird, obwohl Antwort vom Gerät kommt. MAX_TRIES in ozw ist mir nur bei der Suche nach dem Problem untergekommen und nicht so wichtig.
Schönen Urlaub und keine Hektik, Christian

rudolfkoenig

00_ZWDongle fuehrt ein resend aus, falls Nachrichten an Geraete (01....13.*, also nicht an das Dongle selbst) nicht mit ZW_SEND_DATA:OK (0013..00) bestaetigt wurden. Falls ich z.Bsp version abfrage, dann kriege ich zunaechst ein 06 (ACK), dann ein 011301 (??), und dann ein 00130500 (ZW_SEND_DATA:OK). Nach dieser Nachricht entfernt 00_ZWDongle die Versions-Abfrage vom SendStack, damit wird es nicht nochmal gesendet. Anschliessend kommt die eigentliche Nachricht mit dem Antwort des Geraetes. In deinem Fall gab es nur 06 und 011301, aber kein 0013..00.

Der Patch von gero sollte an diesem Verhalten nichts aendern, das war mAn auch frueher schon so.
Gero hat den SendStack fuer Nachrichten, die direkt an das Dongle gehen, aktiviert.

Nach dem openzwave Kommentar klingt es so, dass im Falle eines Funkproblems die Resends vom Dongle ausgefuehrt werden, da bin ich aber noch unsicher und das sollten wir verifizieren.

Genauso interessant waere zu wissen, was genau 011301 zu bedeuten hat.

krikan

Zitataber kein 0013..00
Das fehlt bei meinem Vison-Controller anscheinend seit kurzem immer. Habe es gerade auf einer "frischen" Fhem-Installation ausprobiert und dort das gleiche Problem. Mein Experimentiercontroller UZB1 hat das Problem definitv nicht, dort gibt es die "transmit ..OK" - Einträge im Log noch und es wird alles nur 1x  verschickt. Also eine Macke in meiner Installation, bei der ich keine Ahnung habe, wie ich den Vision-Controller wieder auf Spur bringe. Da das mein Controller für das Produktivsystem ist, ziehe ich mich mit dem Reset etwas. Sorry für die falsche "Verdächtigung".

ZitatDer Patch von gero sollte an diesem Verhalten nichts aendern, das war mAn auch frueher schon so.
Nach meiner Erinnerung wurde früher aber nur 1x verschickt, einen Resend gab es doch nicht?
Zitat
Nach dem openzwave Kommentar klingt es so, dass im Falle eines Funkproblems die Resends vom Dongle ausgefuehrt werden, da bin ich aber noch unsicher und das sollten wir verifizieren.
Verstehe ich eben auch so; zumindest, wenn die zu verschickende Nachricht ordnungsgemäß im Controller landet. Ansonsten machen mMn die TRANSMIT_OPTIONS bei SEND_DATA keinen Sinn (-> Explorer Frames).
Hast Du ein Testsetup im Kopf, wie man das verifizieren könnte? Ansonsten suche ich mal die Stellen im INS*.