ZWave Netzwerk reagiert nicht mehr bei "Überlast"

[adb76]

Hallo zusammen,

ich habe aktuell das Problem, dass meine ZWave Installation immer wieder mal plötzlich keine Nachrichten empfängt und erst mit einem expliziten GET-Kommando auf ein Device ich diese wieder aktivieren kann.  Nach etwas Analyse habe ich einen Verdacht - und daher auch eine konkrete Fragestellung:

Kann es sein, dass die Verarbeitung von ZWave-Telegrammen in FHEM aus Sicht des Controllers und der Devices zeitkritisch ist, also innerhalb von x Sekunden eine Verarbeitung stattgefunden haben muss - insbesondere wenn dann auch noch Batterie-betriebene Devices "dazwischenfunken"?

Nun aber zunächst etwas detaillierten zu meinem Setup:

Habe zwei unabhängige ZWave-Netzwerke (im 2. Stock und im Keller) im Einsatz die über Powerline verbunden sind - die Reichweite hatte für eine Direktverbindung nicht ausgereicht - und bei den Nachbarn kann ich keine Repeater installieren ;-). Als USB-Dongle habe ich zweimal den von Z-WAVE.me im  Einsatz:

Code: [Auswählen]

list ZWDongle_0

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/serial/by-id/usb-0658_0200_12345678-9012-3456-7890-123456789012-if00@115200
   DeviceName /dev/serial/by-id/usb-0658_0200_12345678-9012-3456-7890-123456789012-if00@115200
   FD         13
   MaxSendRetries 3
   NAME       ZWDongle_0
   NR         30
   PARTIAL
   RAWMSG     0004000d1e8f010403800364097105000000ff070800053105030114063105012200b9
   ReadTime   1451462624.30363
   STATE      Initialized
   SendRetries 0
   SendTime   1451462622.21859
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_0_MSGCNT 6549
   ZWDongle_0_TIME 2015-12-30 09:03:44
   homeId     0e0d0c0b
   nodeIdHex  01
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2015-12-28 08:41:00   caps            Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2015-12-05 13:00:33   ctrlCaps        PRIMARY
     2015-12-28 08:41:00   homeId          HomeId:0e0d0c0b CtrlNodeId:01
     2015-12-20 11:15:44   neighborList_1  wg.bz.sd.heizluefter wg.wz.ms.balkontuer wg.fl.tk.wohnungstuer wg.fl.sd.led wg.wz.bm.schrank wg.wz.sd.multimedia wg.ku.sd.kaffeemaschine wg.sz.sd.luftbefeuchter
     2015-12-30 09:01:54   nodeInfo_1      STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
     2015-12-30 09:02:21   nodeInfo_12     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:02:26   nodeInfo_13     ROUTING_SLAVE SENSOR_NOTIFICATION sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:02:37   nodeInfo_16     ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:02:40   nodeInfo_17     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:02:53   nodeInfo_21     ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:03:09   nodeInfo_26     ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:03:12   nodeInfo_27     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:03:16   nodeInfo_28     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:03:34   nodeInfo_33     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:01:41   nodeList        ZWDongle_0 wg.bz.sd.heizluefter wg.wz.ms.balkontuer wg.fl.tk.wohnungstuer wg.fl.sd.led wg.wz.bm.schrank key_fob_1 wg.wz.sd.multimedia wg.ku.sd.kaffeemaschine wg.sz.sd.luftbefeuchter
     2015-12-28 08:41:00   random          2dc5538e1f30d5d0e6005bb868d8caa26af0706c64bc39d56559ca6a0900617a
     2015-12-28 08:41:00   state           Initialized
     2015-12-05 13:01:08   timeouts        01060102
     2015-12-11 14:06:34   version         Z-Wave 3.99 STATIC_CONTROLLER
   SendStack:
Attributes:
   group      Controller
   room       Fhem
   

Code: [Auswählen]

list ZWDongle_1
   
Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        192.168.2.51:3001
   DeviceName 192.168.2.51:3001
   FD         62
   MaxSendRetries 3
   NAME       ZWDongle_1
   NR         123
   PARTIAL
   RAWMSG     000400040e3202213400000125000000000000
   ReadTime   1451462425.45791
   STATE      Initialized
   SendRetries 0
   SendTime   1451462424.47817
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_1_MSGCNT 5258
   ZWDongle_1_TIME 2015-12-30 09:00:25
   homeId     e7e9184c
   nodeIdHex  01
   nrNAck     0
   CHANGETIME:
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1451317701.57412
           VALUE      CONNECTED
   Matchlist:
     1:ZWave    .*
   Readings:
     2015-12-28 16:48:18   caps            Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2015-12-28 08:41:05   homeId          HomeId:e7e9184c CtrlNodeId:01 
     2015-12-30 08:59:36   neighborList_1  kg.wk.sd.trockner kg.wk.sd.waschmaschine kg.kr.sd.gefrierschrank
     2015-12-30 09:00:06   nodeInfo_1      STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
     2015-12-30 09:00:13   nodeInfo_3      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:00:16   nodeInfo_4      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:00:19   nodeInfo_5      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-30 09:00:21   nodeInfo_6      ROUTING_SLAVE METER sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
     2015-12-30 08:59:31   nodeList        ZWDongle_1 kg.wk.sd.trockner kg.wk.sd.waschmaschine kg.kr.sd.gefrierschrank wg.xx.sz.allgemein
     2015-12-28 16:48:21   random          a6f8d83657ed4e6e4bcbb01132a8c128667eaabba0481ba3e26ea846642539f4
     2015-12-28 16:48:21   state           Initialized
     2015-11-23 06:13:31   version         Z-Wave 3.99 STATIC_CONTROLLER
   SendStack:
Attributes:
   group      Controller
   room       Fhem
Der Controller ZWDongle_1 über socat an einem PI: 

Code: [Auswählen]

socat tcp4-listen:3001,reuseaddr,fork file:/dev/ttyACM0,nonblock,echo=0,raw

Nun zu meinem Verdacht: Ich hatte am ZWDongle_0 einen weiteren Fibaro Funk-Schalter für meine Kaffeemaschine angemeldet. Danach hatte ich plötzlich massive Probleme mit meinem Fibaro Bewegungssensor, dass dieser zeitweise keine Meldungen mehr gesendet hat bzw. das Netzwerk am ZWDongle_0 mehrmals am Tag hing. Nach einiger Analyse hatte ich festgestellt, dass der neu eingebundene Fibaro Funk-Schalter mehrmals pro Sekunde Nachrichten bzgl. dem Stromverbrauch gesendet hat, da dieser
sich um 15% verändert hat (Voreinstellung Fibaro). Nachdem ich diesen Wert auf 25% erhöht hatte war Fhem plötzlich wieder sehr schnell und ich hatte auch kein Probleme mehr mit dem Bewegungssensor.

Nun hatten die letzten Tage der Trockner und die Waschmaschine Großeinsatz an denen jeweils ein Devolo Funk-Schalter hängt, der bereits bei 5% Stromverbrauchs-Veränderung feuert - kann ich mangels Konfigurierbarkeit aber auch nicht abändern. Während nun Trockner und Waschmaschine liefen konnte ich feststellen, dass plötzlich mal wieder im ZWave-Netzwerk im Keller (ZWDongle_1) aber auch (!) in der Wohnung (ZWDongle_0) nichts mehr geht. Und das in diesen Tagen mehrmals. Erst ein "GET" Befehl auf einzelne Devices scheinen die ZWave-Netzwerke dann wieder aufzuwecken! Wobei FHEM jetzt aber "gefühlt" nicht wesentlich langsamer wurde.

Aber wie gesagt ist nur ein Anfangsverdacht - lohnt es sich aus eurer Sicht in diese Richtung weiter zu forschen?

Bitte melden, falls ihr detaillierte Logs oder ähnliches benötigt.

Gruß,

André

[rudolfkoenig]

Kann es sein, dass die Verarbeitung von ZWave-Telegrammen in FHEM aus Sicht des Controllers und der Devices zeitkritisch ist

Meines Wissens ist das nur bei aktivierten Verschluesselung der Fall, im "Normalfall" senden die Controller die Acks selbst, ohne FHEMs zutun.

Die ZWave Controller sind verwirrt, wenn sie mehr als einen nicht bestaetigten Request gesendet haben, das versucht FHEM aber neuerdings (gefuehlt seit 2 Monaten) zu vermeiden.

Soweit ich weiss, muessen die ZWave Dongles nicht das 1% Regel beim Senden einhalten, da sie CCA verwenden, d.h. der Kanal muss eine Weile frei sein, bevor sie senden. Die ITU G.9959 Angabe von 1100ms ist aber offensichtlich falsch. Weiss jemand genaueres? Das braeuchte ich auch fuer ZWCUL.

Ich wuerde im Problemfall den Sendstack der beiden ZWDongles und der einzelnen Geraete pruefen, "attr ZWDongle_X verbose 5" aktivieren, und solange mitlaufen lassen, bis sicher einige Nachrichten haetten eintreffen muessen. Idealerweise wuerde man ein ZWCUL Log dazupacken, aber das erfordert ein zusaetzliches CUL und ein bisschen Bastelei.

Mein Bauchgefuehl: die Controller haben ein Problem, und haengen sich ab und zu auf.
Evtl. reicht ein regelmaessig abgesetztes get, um die Symptome zu fixen.

[adb76]

Idealerweise wuerde man ein ZWCUL Log dazupacken, aber das erfordert ein zusaetzliches CUL und ein bisschen Bastelei.

Das werde ich direkt mal angehen - da ich hier aktuell einen CUL "rumliegen" habe. Muss ich bei der Einrichtung des ZWCUL etwas bestimmtes beachten (ausser natürlich die richtige Firmware zu installieren und in Fhem anzulegen) oder hört der dann direkt mit?

[rudolfkoenig]

Es sollte ein aktuelles culfw haben, am besten den von gestern, zu finden auf Sourceforge. .hex Files gibts fuer CUL_V3 und CUL_V4. Weiterhin muss man ein bischen mit dataRate experimentieren, um mitzukriegen was bei dir gesprochen wird, ich vermute 100k. Die ZWDongles koennen auf 3 "Datenraten" auf einmal hoeren (9.6k, 40k, 100k), ZWCul nur auf einem. Details gibts es hier, auch wenn das zum Lernen etwas muehsam ist.

Beispielconfig:

Code: [Auswählen]

attr global logfile -
attr global modpath .
attr global mseclog 1

define telnetPort telnet 7074

define zwc ZWCUL /dev/cu.usbmodemfd141 00000000 01
attr zwc dataRate 100k
attr zwc noDispatch 1
attr zwc verbose 5
Device bei der zwc Definition anpassen, FHEM in einem Terminal starten, und zuschauen.

[adb76]

Heute kam es am ZWDongle_1 zu folgenden Telegrammen und danach ging mal wieder nichts mehr - vorher sah bis dahin alles gut aus:

Code: [Auswählen]

2015.12.31 13:42:03.446 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004dd5000000000000
2015.12.31 13:42:03.449 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004dd5000000000000
2015.12.31 13:42:03.717 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004dd5000000000000
2015.12.31 13:42:03.719 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004dd5000000000000
2015.12.31 13:42:03.985 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004dd5000000000000
2015.12.31 13:42:03.988 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004dd5000000000000
2015.12.31 13:42:04.252 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004dd5000000000000
2015.12.31 13:42:04.254 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004dd5000000000000
2015.12.31 13:42:04.517 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004ca3000000000000
2015.12.31 13:42:04.520 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004ca3000000000000
2015.12.31 13:42:04.783 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004ca3000000000000
2015.12.31 13:42:04.786 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004ca3000000000000
2015.12.31 13:42:05.050 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004ca3000000000000
2015.12.31 13:42:05.052 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004ca3000000000000
2015.12.31 13:42:05.320 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004ca3000000000000
2015.12.31 13:42:05.322 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004ca3000000000000
2015.12.31 13:42:05.583 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004e3b000000000000
2015.12.31 13:42:05.585 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004e3b000000000000
2015.12.31 13:42:05.848 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004e3b000000000000
2015.12.31 13:42:05.850 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004e3b000000000000
2015.12.31 13:42:06.116 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004e3b000000000000
2015.12.31 13:42:06.119 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004e3b000000000000
2015.12.31 13:42:06.384 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400004e3b000000000000
2015.12.31 13:42:06.387 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400004e3b000000000000

Danach kamen keine Nachrichten mehr rein - stündlich hätten mindestens mal die Verbrauchswerte kommen müssen. Mit GET auf ein Device könnte ich ihn reaktivieren. Soll ich hierzu noch vorher an den Devices ein Verbose 5 einschalten? Habe ich bisher noch nicht gemacht...
ZWDongle_0 arbeitet normal weiter.

Hilft das eventuell irgendwie in der Analyse?

André

[rudolfkoenig]

Moeglichkeit 1: Verbindung FHEM - socat ist gestoert, z.Bsp. weil das RPi im Keller durch reset neu gebootet wurde, und deswegen keine Gelegenheit hatte die TCP/IP Verbindung "ordentlich" zu schliessen. Das "normale" TCP/IP Keepalive muesste das Problem nach ca 2 Stunden merken, und in FHEM-Log muss was von "disconnected" stehen. Es kann sich aber auch um ein anderes Netzwerkproblem handeln, mit anderen Symptomen.
Moeglichkeit 2: Verbindung socat - USB ist gestoert. Workaround: ser2net probieren.
Moeglichkeit 3: der USB-Stick (zme) hat sich aufgehaengt. Workaround: jede Minute ein "get ZWDongle_1 homeId" absaetzen. Das kann auch andere Netzwerkprobleme "heilen".

[krikan]

Moeglichkeit 3: der USB-Stick (zme) hat sich aufgehaengt. Workaround: jede Minute ein "get ZWDongle_1 homeId" absaetzen. Das kann auch andere Netzwerkprobleme "heilen".

Hast Du dazu mehr Infos? Ich hatte es bei älteren Modul-Versionen über einige Wochen, dass ich den per USB angeschlossenen Stick per at regelmäßig (5Min) mit get-Abfragen beschäftigen musste, sonst war er -wie hier im Problem- tot.

[rudolfkoenig]

Ich nicht, das war nur meine theoretische Betrachtung. Wird natuerlich sofort gefixt, wenn ich weiss wie.
Mein Produktions-Goodway hat das Problem nicht, das zme ist ueblicherweise nicht so lange untaetig dran.

[krikan]

Ich nicht, das war nur meine theoretische Betrachtung. Wird natuerlich sofort gefixt, wenn ich weiss wie.
Mein Produktions-Goodway hat das Problem nicht, das zme ist ueblicherweise nicht so lange untaetig dran.

Ok. Das betraf meinen Vision-Stick. War irgendwann nicht mehr nötig und ist nie mehr aufgetreten. Ursache ist mir unbekannt. Hab es auf meine zu heftigen Contollerexperimente geschoben. Deine Äußerung machte mir Hoffnung, dass es eine logische Erklärung gibt. Also von mir: Gibt keinen Bug, den man fixen müsste.

[krikan]

Soweit ich weiss, muessen die ZWave Dongles nicht das 1% Regel beim Senden einhalten, da sie CCA verwenden, d.h. der Kanal muss eine Weile frei sein, bevor sie senden. Die ITU G.9959 Angabe von 1100ms ist aber offensichtlich falsch. Weiss jemand genaueres? Das braeuchte ich auch fuer ZWCUL.

Bin gerade beim Lesen im Paetz in Kapitel 4.4.5 "Die Kosten der Sicherheit" von Security über eine Aussage gestolpert. Bin unsicher, ob es das ist was Du suchst, weil ich es nicht verstehe: Im Paetz steht etwas von einem Duty-Cycle von 1% und das ein nächstes Funkkomando erst nach ca. 100ms Pause ausgesendet werden kann. Evtl. muss man das auch im Gesamtzusammenhang des Beispiels im Kapitel sehen, verstehe ich aber nicht so.

[rudolfkoenig]

Welche Ausgabe hast du? Meins ist eine deutsche vom März 2014 (habs vom Autor auf der frankfurter Elektrikermesse bekommen), hier ist dieser Kapitel unter 4.6.6. Der Text steht in meiner Version auch so da, allerdings glaube ich, dass der Autor weder die Gesetze genau gelesen hat, noch im Besitz eines Sniffers war.:)

Im Gesetz steht, dass fuer diese Anwendungen _entweder_ 1% _oder_ LBT (Listen Before Talk, CCA auf dem CC1101) angewendet werden muss. Allerdings weiss ich nicht, wie lange man bei LBT zuhoeren muss, und auch beim 1% ist mW nicht definiert, ob das pro Stunde oder pro Sekunde zu gelten hat. Mit dem Sniffer sieht man, dass die zweite Nachricht schon nach 10ms (40k, s.u) ausgesendet wird, wobei hier unklar ist, ob das nicht doch ein "Bug" in FHEM ist. Ich meine nicht, weil in der G.9959 von CCA/LBT gesprochen wird.

Die 100ms ist mAn falsch: bei 6 Byte Nutzlast ist ein Frame 16 Byte, auf 9600 mit Praeambel 24+1+16+1 = 42*8 = 336Bit, die Uebertragung dauert also 35ms, man muesste also 3.5 Sekunden Pause einlegen, wenn man das 1% direkt erzwingen will. Bei 40k 0.84 Sekunden, und bei 100k (40 Byte Praeambel) 0.464 Sekunden.

[krikan]

Welche Ausgabe hast du? Meins ist eine deutsche vom März 2014 (habs vom Autor auf der frankfurter Elektrikermesse bekommen), hier ist dieser Kapitel unter 4.6.6.

Nach Überprüfung ist es auch bei mir 4.6.6 (neue Brille fällig!?). Habe ein eBook ohne Veröffentlichungsdatum; ISBN führt aber zur Veröffentlichung 11/15.