ZWave @ culfw

A.Harrenberg · 10 Dezember 2015, 15:55:44

Hi Rudi,

Zitat von: rudolfkoenig am 10 Dezember 2015, 15:29:07
Habe das ITU Dokument grob durchgelesen, und ein paar Flags angepasst. Routing ist da nicht beschrieben, aber beams. Und alles andere, was wir auch schon wissen

Du willst damit sagen das wir diese Quelle jetzt ignorieren können weil alles interessante bereits integriert ist?

Zitat von: rudolfkoenig am 10 Dezember 2015, 15:29:07
Weiterhin kann man jetzt auf 100k schalten mit "attr ZWCUL dataRate 100k", leider funktioniert das bei mir immer noch nicht, keine Ahnung, wieso.

Ich werde mal schauen ob ich da heute abend ein wenig probieren kann und werde dann ggf. noch mal mit den Parametern vom CC experimentieren. In einer Quelle (die ich mir natürlich nicht gemerkt habe) war als "deviation" 0 angegeben. Erster Versuch wäre daher mal diese 0 mit den 400kHz Bandbreite...

Gruß,
Andreas.

A.Harrenberg · 10 Dezember 2015, 19:52:12

Hallo Rudi,

bist Du Dir hier sicher oder ist da was durcheinander geraten...

Code Auswählen


  if($s100 && $rmsg =~ '^z(........)(..)(..)(..)(..)(..)(..)(.*)(....)$') {
    ($H,$S,$F,$f,$L,$sn,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

  } elsif(!$s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(..)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

Für die 100k sind da zu viele "." : ERROR: Unknown packet ze015dfed0103010bab36a8
Die Nachricht ist dafür zu kurz, mit Nibbles für $4 und $5 passt das wieder...

Aber Du hast da auch noch verschiedene Reihenfolgen in den Variablen -> $sn und $L vertauscht, hier würde ich auch dazu tendieren das die 40K Reihenfolge stimmt...

Gruß,
Andreas.

P.S.: Ich kann standardmäßig 100k lesen...

A.Harrenberg · 10 Dezember 2015, 21:01:31

Hallo Rudi,

kannst Du mal diese Parameter für 100kBaud probieren?

Code Auswählen

#define ZWAVE_100k_SIZE (8*2)
  CC1100_FREQ2,     0x21, // 0D Frequency control word, high byte 869.85 MHz
  CC1100_FREQ1,     0x74, // 0E
  CC1100_FREQ0,     0xAD, // 0F
  CC1100_MDMCFG4,   0x4b, // 10 Modem configuration               bW 406kHz
  CC1100_MDMCFG3,   0xf8, // 11 Modem configuration               dr 100kBaud
  CC1100_MDMCFG2,   0x06, // 12 Modem configuration               GFSK/16sync
  CC1100_MDMCFG1,   0x72, // 13 Modem configuration               24 preamble
  CC1100_DEVIATN,   0x41  // 15 Modem deviation setting           dev:28 kHz -> 2*28 ~ 57 kHz

Das funktioniert bei mir einwandfrei, ich kann mit dem Bewegungssensor in die letzte Ecke von der Wohnung gehen und erhalte einwandfreie Protokolle.

Gruß,
Andreas.

rudolfkoenig · 10 Dezember 2015, 22:19:19

Zitatbist Du Dir hier sicher oder ist da was durcheinander geraten...

Kann gut sein, ich habe halt fleissig das ITU Dokument abgeschrieben, und ich kann 100k nicht testen. Im ITU steht drin, dass mit 100k seqNum nicht mehr ein nibble, sondern ein extra Byte nach len ist. Bitte Korrektur schicken, falls das nicht dem Realitaet entspricht.

Zitatkannst Du mal diese Parameter für 100kBaud probieren?

Habs gemacht, kein Unterschied. Weder den as6 in 100k Modus, noch den KFOB kann ich empfangen.

Komisch: die zwave.me Fernbedienung kann ich mit culfw@40k auch nicht empfangen, und da sie zum goodway gehoert, kann sie hoechstens 40k sein, insofern haben wir noch ein generelles Problem bei Fernbedienungen. Seufz.

rudolfkoenig · 10 Dezember 2015, 22:29:32

Sorry, gerade gefunden: bei nicht gesetzten dataRate gabs unter 40k Probleme. Das habe ich gefixt.

A.Harrenberg · 10 Dezember 2015, 22:40:59

Hallo Rudi,

kann es sein das Du beim Lesen der ITU "Channel configuration" und "Datarate" durcheinander geworfen hast?

Ich finde einen etwas anderen Aufbau (mit getrenntem Byte für Sequencenumber) nur für Channel configuration 3, die haben wir aber nicht! Wir haben auch mit 100kBaud nur Channel configuration 1 oder 2.
[Rec. ITU-T G.9959 (01/2015) Seite 41, 42, 44]

Übersicht über Channel configuration / Datarate ist auf Seite 10 zu finden.
(Welche Version von dem Dokument hast Du denn eigentlich?)

Ich bin daher der Meinung das dies für 40k / 100k gleich sein muss. Einzig die Checksumme ist unterschiedlich 40k -> CS, 100k -> CRC_16
Und wie Du an dem Beispiel sehen konntest z.B. so eine ACK Nachricht ansonsten zu kurz..

Gruß,
Andreas.

A.Harrenberg · 11 Dezember 2015, 08:02:12

Hi Rudi,

ich habe mir das jetzt so abgeändert:

Code Auswählen

  if($s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(....)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

  } elsif(!$s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(..)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

-> identisch außer Checksumme.

Und beim Parsen habe ich mir den Block für die 100kBaud auskommentiert:

Code Auswählen

      # ($s100 ?
      #   ((($hF & 0x40)==0x20 ? " lowPower":"").
      #    (($hF & 0x80)==0x40 ? " ackReq":"").
      #    (($hf&0x7)==0 ? " "               :
      #     ($hf&0x7)==1 ? " shortBeam"      :
      #     ($hf&0x7)==2 ? " longBeam"       :
      #     ($hf&0x7)==4 ? " fragmentedBeam" : " unknownBeam"))
      # :
      ((($hF & 0x10)==0x10 ? " speedModified":"").
         (($hF & 0x20)==0x20 ? " lowPower":"").
         (($hF & 0x40)==0x40 ? " ackReq":"").
         (($hF & 0x80)==0x80 ? " routed, rf:$rf hopCount:$hc, hops:$hops":"").
         ((($hf>>1)&3)==0 ? " "          :
          (($hf>>1)&3)==1 ? " shortBeam" :
          (($hf>>1)&3)==2 ? " longBeam"  :" unknownBeam"));

Sieht für mich erst mal ok aus, allerdings habe ich jetzt noch nicht so viele Pakete angeschaut und geroutete Nachrichten hatte ich da jetzt auch noch nicht dabei. (Kriege ich nur hin wenn ich z.B. den Steckdosenschalter rausziehe, dann fällt das Netz aber auf 40K zurück...)

Gruß,
Andreas.

P.S.: Demnächst dann auch als Patchdatei... ,-)
P.P.S.: Ganz optimal sind die 100K Parameter anscheinend auch nicht, bei mir tauchen zwischendurch immer wieder recht lange falsche Nachrichten auf...

A.Harrenberg · 11 Dezember 2015, 09:12:02

Hi Rudi,

irgendwas stimmt da mit dem Parsen der einzelnen Befehle für FHEMWEB noch nicht, in dem DropDown werden die Befehle alle mit Komma getrennt hintereinander ausgegeben und nicht als einzelne DropDown-Zeilen.

Siehe Anhang/Bild
(http://forum.fhem.de/index.php?action=dlattach;topic=44905.0;attach=41869;image)

Auf Anhieb finde ich aber nicht was da anders ist als in ZWave.pm.
Die (manuelle) Befehlseingabe funktioniert aber einwandfrei.

Gruß,
Andreas.

rudolfkoenig · 11 Dezember 2015, 11:54:07

Zitatin dem DropDown werden die Befehle alle mit Komma getrennt hintereinander ausgegeben

Danke, habs gefixt.

Zitatkann es sein das Du beim Lesen der ITU "Channel configuration" und "Datarate" durcheinander geworfen hast?

Yepp, habe bei der Beschriftung der Tabelle nicht nachgedacht. Da Channel Configuration 3 nur in Japan und Korea zum tragen kommt, habe ich den entsprechenden Kode entfernt, und dein regexp Vorschlag uebernommen. Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?

ZitatGanz optimal sind die 100K Parameter anscheinend auch nicht, bei mir tauchen zwischendurch immer wieder recht lange falsche Nachrichten auf...

Das gibts bei 40k auch, nur seltener. Kannst du mir bitte 2-3 komplette 100k Nachrichten schicken, damit ich die Checksummenberechnung testen kann? Dann wuerde ich die Checksummen-Pruefung auch fuer Monitor-Mode aktivieren.

A.Harrenberg · 11 Dezember 2015, 13:18:27

Hi Rudi,

Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?

da kann ich leider nichts zu sagen da ich keine ZWave Fernbedienung habe.

Das einzige was mir dazu gerade einfällt ist das die vielleicht Beams verwenden, bzw. eine andere Anzahl an Präambel Paketen und deswegen nichts vom Chip gemeldet wird.

Ich habe das jetzt nicht noch mal ausprobiert, aber man könnte noch mal die Sync/Präambel im CC ausschalten und sehen was dann so alles ankommt. Problem dabei ist das dann kontinuirlich Müll ankommt... Die Frage wäre ob man dann dort die Präambel und das SyncByte erkennen würde, das wird ja ansonsten direkt vom CC entfernt. Das macht man dann am besten nur per Screen... Mal schauen ob ich heute abend Zeit finde das mal zu probieren, ansonsten frühestens Sonntag.

Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Das gibts bei 40k auch, nur seltener. Kannst du mir bitte 2-3 komplette 100k Nachrichten schicken, damit ich die Checksummenberechnung testen kann? Dann wuerde ich die Checksummen-Pruefung auch fuer Monitor-Mode aktivieren.

Kann ich Dir erst heute abend schicken, auf die Test-Maschine habe ich aktuell keinen Remotezugriff, aber die Berechnung die ich für die CRC_16 Klasse gemacht habe funktioniert. Die ersten Pakete hatte ich händisch mit dem Code geprüft und die CRC war identisch.
Mir ist jetzt auf Anhieb nicht mehr geläufig wie generisch ich das umgesetzt habe, aber es würde sich wohl anbieten das auch in die ZWlib.pm auszulagern.

Gruß,
Andreas.

krikan · 11 Dezember 2015, 14:28:51

Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?

Sprichst Du vom KFOB-S oder von der alten DÜWI.
Erstes könnte ich mal testen.
Wenn es um die uralte DÜWI geht, dann ist die Frage, ob die überhaupt schon 40k kann oder noch bei 9600 war.

rudolfkoenig · 11 Dezember 2015, 14:55:31

ZitatSprichst Du vom KFOB-S oder von der alten DÜWI.

Eigentlich von beiden:

KFOB-S an zme:
zwd nodeInfo_51 => ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0

DÜWI mit zwave.me Firmware an goodway:
zwd nodeInfo_22 => ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0

krikan · 11 Dezember 2015, 19:22:25

Kurztest mit 100k:
KFOB-S sehe ich auch nichts.
Bei Netzgespeisten Geräten (Sirene und LED) sehe ich Telegramme sporadisch. 2dbi-Antenne verbessert es ein wenig.

@Andreas: Siehst Du den AEOTEC Multisensor?

A.Harrenberg · 11 Dezember 2015, 19:37:03

Hi,

hier mal ein kurzer Logausschnitt mit dem AEOTEC Multisensor 6 und dem CUL auf 100kBaud:

Code Auswählen

2015.12.11 19:34:00.092 4: ZWCUL_ReadAnswer arg:Clear regexp:wontmatch
2015.12.11 19:34:00.592 5: ZWCUL_ReadAnswer: select timeout
2015.12.11 19:34:00.592 5: SW: V
2015.12.11 19:34:00.594 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2015.12.11 19:34:00.955 4: ZWCUL_ReadAnswer for Version: V 1.66 CUL868
2015.12.11 19:34:00.955 5: SW: zi0000000001
2015.12.11 19:34:00.956 5: SW: zm1
2015.12.11 19:34:15.272 5: ZWCul: ze015dfedab410115017105000000ff070300000283
2015.12.11 19:34:15.272 5: e015dfed S:ab F:41 f:0 SN:1 L:15 T:01 P:7105000000ff07030000 C:0283
2015.12.11 19:34:15.272 5:    F: singleCast ackReq 
2015.12.11 19:34:15.280 5: ZWCul: ze015dfed0103010bab36a8
2015.12.11 19:34:15.280 5: e015dfed S:01 F:03 f:0 SN:1 L:0b T:ab P: C:36a8
2015.12.11 19:34:15.280 5:    F: ack 
2015.12.11 19:34:15.294 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab0a7105000000ff07030000
2015.12.11 19:34:15.294 5: SW: 06
2015.12.11 19:34:15.295 5: ZWDongle_0 dispatch 000400ab0a7105000000ff07030000
2015.12.11 19:34:15.295 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:0a7105000000ff07030000
2015.12.11 19:34:23.385 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.385 5: SW: 06
2015.12.11 19:34:23.386 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.387 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:ab ARG:120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.788 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:23.788 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:23.792 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:23.801 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:23.801 5: SW: 06
2015.12.11 19:34:23.802 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:23.807 5: ZWCul: ze015dfed01410e0dab84086eb5
2015.12.11 19:34:23.807 5: e015dfed S:01 F:41 f:0 SN:e L:0d T:ab P:8408 C:6eb5
2015.12.11 19:34:23.807 5:    F: singleCast ackReq 
2015.12.11 19:34:23.815 5: ZWCul: ze015dfedab030e0b0162f3
2015.12.11 19:34:23.815 5: e015dfed S:ab F:03 f:0 SN:e L:0b T:01 P: C:62f3
2015.12.11 19:34:23.815 5:    F: ack 
2015.12.11 19:34:23.834 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2015.12.11 19:34:23.834 5: SW: 06
2015.12.11 19:34:23.835 5: device ack reveived, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:23.835 5: ZWDongle_0 dispatch 0013ab000002
2015.12.11 19:34:23.835 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.12.11 19:34:23.835 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:24.279 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000404ab028407
2015.12.11 19:34:24.279 5: SW: 06
2015.12.11 19:34:24.280 5: ZWDongle_0 dispatch 000404ab028407
2015.12.11 19:34:24.280 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2015.12.11 19:34:24.681 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:24.681 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:24.684 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:24.699 5: ZWCul: ze015dfed01410f0dab8408c4e4
2015.12.11 19:34:24.699 5: e015dfed S:01 F:41 f:0 SN:f L:0d T:ab P:8408 C:c4e4
2015.12.11 19:34:24.699 5:    F: singleCast ackReq 
2015.12.11 19:34:24.706 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:24.706 5: SW: 06
2015.12.11 19:34:24.708 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:24.766 5: ZWCul: ze015dfed01410f0dab8408c4e4
2015.12.11 19:34:24.766 5: e015dfed S:01 F:41 f:0 SN:f L:0d T:ab P:8408 C:c4e4
2015.12.11 19:34:24.766 5:    F: singleCast ackReq 
2015.12.11 19:34:24.867 5: ZWCul: ze015dfed0141010dab84080b4c
2015.12.11 19:34:24.867 5: e015dfed S:01 F:41 f:0 SN:1 L:0d T:ab P:8408 C:0b4c
2015.12.11 19:34:24.867 5:    F: singleCast ackReq 
2015.12.11 19:34:24.919 5: ZWCul: ze015dfed0141010dab84080b4c
2015.12.11 19:34:24.919 5: e015dfed S:01 F:41 f:0 SN:1 L:0d T:ab P:8408 C:0b4c
2015.12.11 19:34:24.919 5:    F: singleCast ackReq 
2015.12.11 19:34:26.710 4: no response from device, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:29.005 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab0101ae
2015.12.11 19:34:29.005 5: SW: 06
2015.12.11 19:34:29.006 5: ZWDongle_0 dispatch 0013ab0101ae
2015.12.11 19:34:29.007 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:01ae
2015.12.11 19:34:29.007 2: ZWDongle_0 transmit NO_ACK for ab
2015.12.11 19:34:49.147 2: ZWave get ZWave_SENSOR_MULTILEVEL_171 version 
2015.12.11 19:34:53.636 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.636 5: SW: 06
2015.12.11 19:34:53.637 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.637 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:ab ARG:120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.637 5: ZWDongle_Write 0013ab02861125ab (e015dfed)
2015.12.11 19:34:53.637 5: SW: 01090013ab02861125ab55
2015.12.11 19:34:53.640 5: ACK received, WaitForAck=>2 for 01090013ab02861125ab55
2015.12.11 19:34:53.657 5: ZWCul: ze015dfed0141020dab861100e4
2015.12.11 19:34:53.657 5: e015dfed S:01 F:41 f:0 SN:2 L:0d T:ab P:8611 C:00e4
2015.12.11 19:34:53.657 5:    F: singleCast ackReq 
2015.12.11 19:34:53.667 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:53.667 5: SW: 06
2015.12.11 19:34:53.668 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:53.668 5: ZWCul: ze015dfedab03020b011792
2015.12.11 19:34:53.668 5: e015dfed S:ab F:03 f:0 SN:2 L:0b T:01 P: C:1792
2015.12.11 19:34:53.668 5:    F: ack 
2015.12.11 19:34:53.674 5: ZWCul: ze015dfedab410214018612030405010664000a78
2015.12.11 19:34:53.674 5: e015dfed S:ab F:41 f:0 SN:2 L:14 T:01 P:861203040501066400 C:0a78
2015.12.11 19:34:53.674 5:    F: singleCast ackReq 
2015.12.11 19:34:53.683 5: ZWCul: ze015dfed0103020bab6ff8
2015.12.11 19:34:53.683 5: e015dfed S:01 F:03 f:0 SN:2 L:0b T:ab P: C:6ff8
2015.12.11 19:34:53.683 5:    F: ack 
2015.12.11 19:34:53.693 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000003
2015.12.11 19:34:53.693 5: SW: 06
2015.12.11 19:34:53.694 5: device ack reveived, removing 01090013ab02861125ab55 from dongle sendstack
2015.12.11 19:34:53.694 5: ZWDongle_0 dispatch 0013ab000003
2015.12.11 19:34:53.694 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 19:34:53.694 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:53.742 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab09861203040501066400
2015.12.11 19:34:53.742 5: SW: 06
2015.12.11 19:34:53.743 5: ZWDongle_0 dispatch 000400ab09861203040501066400
2015.12.11 19:34:53.743 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:09861203040501066400
2015.12.11 19:34:54.139 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:54.139 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:54.143 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:54.157 5: ZWCul: ze015dfed0141030dab84084fcf
2015.12.11 19:34:54.157 5: e015dfed S:01 F:41 f:0 SN:3 L:0d T:ab P:8408 C:4fcf
2015.12.11 19:34:54.157 5:    F: singleCast ackReq 
2015.12.11 19:34:54.158 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:54.158 5: SW: 06
2015.12.11 19:34:54.160 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:54.165 5: ZWCul: ze015dfedab03030b0120a2
2015.12.11 19:34:54.165 5: e015dfed S:ab F:03 f:0 SN:3 L:0b T:01 P: C:20a2
2015.12.11 19:34:54.165 5:    F: ack 
2015.12.11 19:34:54.187 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000003
2015.12.11 19:34:54.187 5: SW: 06
2015.12.11 19:34:54.188 5: device ack reveived, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:54.188 5: ZWDongle_0 dispatch 0013ab000003
2015.12.11 19:34:54.188 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 19:34:54.188 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:54.541 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000404ab028407
2015.12.11 19:34:54.541 5: SW: 06
2015.12.11 19:34:54.542 5: ZWDongle_0 dispatch 000404ab028407
2015.12.11 19:34:54.542 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2015.12.11 19:34:54.943 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:54.943 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:54.946 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:54.957 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:54.957 5: SW: 06
2015.12.11 19:34:54.958 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:54.959 5: ZWCul: ze015dfed0141040dab8408281b
2015.12.11 19:34:54.959 5: e015dfed S:01 F:41 f:0 SN:4 L:0d T:ab P:8408 C:281b
2015.12.11 19:34:54.959 5:    F: singleCast ackReq 
2015.12.11 19:34:54.997 5: ZWCul: ze015dfed0141040dab8408281b
2015.12.11 19:34:54.997 5: e015dfed S:01 F:41 f:0 SN:4 L:0d T:ab P:8408 C:281b
2015.12.11 19:34:54.997 5:    F: singleCast ackReq 
2015.12.11 19:34:55.071 5: ZWCul: ze015dfed0141050dab8408824a
2015.12.11 19:34:55.071 5: e015dfed S:01 F:41 f:0 SN:5 L:0d T:ab P:8408 C:824a
2015.12.11 19:34:55.071 5:    F: singleCast ackReq 
2015.12.11 19:34:55.123 5: ZWCul: ze015dfed0141050dab8408824a
2015.12.11 19:34:55.123 5: e015dfed S:01 F:41 f:0 SN:5 L:0d T:ab P:8408 C:824a
2015.12.11 19:34:55.123 5:    F: singleCast ackReq 
2015.12.11 19:34:56.959 4: no response from device, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:59.204 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab0101a8
2015.12.11 19:34:59.204 5: SW: 06
2015.12.11 19:34:59.206 5: ZWDongle_0 dispatch 0013ab0101a8
2015.12.11 19:34:59.206 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:01a8
2015.12.11 19:34:59.206 2: ZWDongle_0 transmit NO_ACK for ab

Irgendwo da drin ist auch ein NO_ACK, das ist aber weil das Ding so tierisch schnell einschläft... WNMI_delay war schon auf 0.4 sekunden... Hab' es jetzt mal auf 0.3 gesetzt.

@Krikan: Damit dürfte Deine Frage beantwortet sein ,-) Das Ding ist momentan aber auch nur 0.4m vom CUL entfernt, gestern war ich aber am anderen Ende der Wohnung, da ging es auch.

Gruß,
Andreas.

krikan · 12 Dezember 2015, 17:04:01

Längerer Test mit KFOB-S:
Habe jetzt mal gleichzeitig 40k und 100k mitgeschnitten. Telegramme sehe ich bei 100k, wenn ich Befehle vom Controller an den KFOB-S schicke; aber nur den Versand des Befehls an KFOB und das ACK vom KFOB zurück. Die Antwort des KFOB auf die Abfrage (wakeupIntverval und Co.) sowie das ACK des Controllers sehe ich danach nicht mehr.