zwave am Raspberry empfängt nichts mehr

[DD]

Hallo,

nach einem Neustart meines Raspberry empfängt der ZWAVE Dongle (die kleine Platine) nichts mehr. Befehle senden ist kein Problem aber z.B. die Leistungsvereinbarungen der Steckdosen oder Fensterkontakte werden nicht mehr aufgenommen.
Ich vermute dass da etwas abgeschaltet ist,  weiß aber nicht was ich tun muß.

Unter den Readings wird mir bei caps folgendes angezeigt:

Vers:5 Rev:0 ManufID:0147 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 ZW_SET_WUT_TIMEOUT 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

Hat jemand eine Idee?

[rudolfkoenig]

Schau mal, was nach "attr zwdongle verbose 5" im FHEM-Log zu sehen ist.
Warum meinst Du, dass caps bei diesem Problem relevant ist?

[DD]

Hallo Rudolf,

das war die Lösung. Verbose war gar nicht (mehr) vorhanden.
Ich hatte caps reingenommen weil ich dachte dass das bisher leer war und der Inhalt befürchten mich etwas chaotisch aussah.

Danke dir
Tobias

[Barracus]

Hallo!

Ich habe auch das gleiche Problem.
Bei mir passiert es regelmäßig, dass der Dongle (bei mir ist es auch die Razberry Board) nichts mehr empfängt.
Nach einem Shutdown Restart geht es wieder.

Jetzt, als ich ebenfalls Verbose auf 5 gesetzt habe, funktioniert es wieder ohne FHEM-Restart.

Woran liegt/lag das Problem?

Danke!

Ciao

[Barracus]

Hallo Nochmal,

bei mir ist das Problem immer noch da:
Alles Funktioniert wunderbar für 2-3 Tage bis das Razberry einfach aufhört Signale zu empfangen.
(Ich habe im Z-Wave Netzwerk 4 Multisensoren und 2 Sirenen - Wenn das Problem auftritt, empfange ich keine Signale mehr von den AEON Multisensoren)

Sobald ich dann ein beliebiges Z-Wave Gerät ansteuere (in meinem Fall eine Sirene), funktioniert die Ansteuerung wunderbar und danach kann ich auch die Signalen aus den Multisensoren wieder Empfangen.

Habe ich irgendwas am Gateway vergessen einzustellen?

Code Auswählen Erweitern


Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyAMA0@115200
   DeviceName /dev/ttyAMA0@115200
   FD         107
   MaxSendRetries 3
   NAME       ZWAVE_GATEWAY
   NR         358
   PARTIAL
   RAWMSG     000400080531051b0100
   ReadTime   1485289661.4385
   STATE      Initialized
   SendRetries 0
   SendTime   1485289539.86951
   TYPE       ZWDongle
   WaitForAck 0
   ZWAVE_GATEWAY_MSGCNT 18523
   ZWAVE_GATEWAY_TIME 2017-01-24 21:27:41
   homeId     ebb662f2
   nodeIdHex  01
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2017-01-22 10:18:22   caps            Vers:5 Rev:0 ManufID:0147 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 ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT 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
     2017-01-22 10:18:22   ctrlCaps        PRIMARY
     2017-01-22 10:18:22   homeId          HomeId:ebb662f2 CtrlNodeIdHex:01
     2017-01-22 10:18:22   random          19bdf8507fd6af2e5e805287c0186a8c9f6005be1a0004fc6a9c7c9a709e5656
     2017-01-22 10:18:22   state           Initialized
     2017-01-22 10:18:22   sucNodeId       no
   SendStack:
Attributes:
   room       30_IO_Devices,ZWave
   verbose    5


Danke euch!

[A.Harrenberg]

Hi,

kannst Du mal ein List machen wenn das Problem noch vorhanden ist?

Mich würde interessieren ob dann noch etwas auf dem Sendstack liegt und ob evtl. gerade auf eine Antwort gewartet wird.

Gruß,
Andreas.

[Barracus]

Hallo Andreas,

danke für deine Antwort.
Klar, werde ich machen sobald es wieder auftritt.

Ciao.

[DeeSPe]

Ich hänge mich hier mal dran!

Seit dem Umstieg auf ZME_UZB1 (und auch weg vom RPi) sind bei mir auch vermehrt "Aussteiger" aufgetreten.
Einen Sonntag ging nach dem Mittagsschlaf auch gar nichts mehr.
FHEM war normal zu erreichen, aber Z-Wave hat gar nichts mehr gemacht. Kein Licht ging an, nichts!
Laut Log (leider nur verbose 3) hat in der ganzen Zeit keine Kommunikation im Z-Wave Netzwerk stattgefunden.
Alles Andere lief ganz normal weiter (HM, Hue, JeeLink).

Ab und an ging Z-Wave auch nach einem FHEM "update" und "shutdown restart" nicht mehr!
Habe es bisher nicht genauer analysiert sonder immer einen kompletten Systemneustart gemacht und dann lief es immer wieder.

Das Alles gab es auch ab und an beim RaZberry Modul, nur gefühlt seltener.

Wenn ich zur Lösung beitragen kann, mache ich das gerne, allerdings möchte ich ungern den ZME_UZB1 die ganze Zeit auf "verbose 5" laufen lassen! Das sind mir auf Dauer zu viel Daten.
Es tritt, spontan gesagt, so alle paar Tage (1-2 Mal die Woche vielleicht) auf. Eine genauere Angabe kann ich leider nicht machen da wie gesagt noch nicht analysiert.

Werd auf jeden Fall mal ein list machen wenn es wieder auftritt.

Gruß
Dan

[rudolfkoenig]

Wenn ich zur Lösung beitragen kann, mache ich das gerne, allerdings möchte ich ungern den ZME_UZB1 die ganze Zeit auf "verbose 5" laufen lassen!

Wenn nichts geht
- eine zweite FHEM-Instanz mit ZWCUL im monitor mode aktivieren, und schauen, welche Funk-Signale gesendet werden.
- parallel dazu "attr verbose zwdongle 5" setzen.

[burgi400]

Hatte das gleiche Problem, allerdings hat auch verbose 5 nicht geholfen, keine Log-Einträge, einfach tot....
Jetzt rufe ich per doif alle 2 Tage reopen vom Stick auf und er läuft seit 2 Monaten ohne Probleme durch.

[krikan]

Am Rande ein wenig Spekulation:
Bisher tritt das Problem nur bei ZME-Controllern auf. Oder kann jemand mit einem anderen Controller davon berichten? Mein Vision läuft problemlos.
z-way setzt laut den zugänglichen Logs beim Programmstart den Controller-Befehl D2 (WATCHDOG_START) ab. Verhindert der so etwas?

[rudolfkoenig]

Ich gehe davon aus, sonst haetten sie es nicht abgesetzt. Haettest du dafuer ein Hex-Code?
Btw. mein Goodway hat solche Probleme auch nicht, den ZME habe ich nie lange genug im Betrieb, um das Problem sehen zu koennen.

[krikan]

Code Auswählen Erweitern

get <ZWDongle> raw D2
nach Setzen des timeout.

Wenn die Reihenfolge in ZWDongle_DoInit($) entscheidend ist, müsste der Rest ggfs. auch noch umgestellt werden. Doku finde ich leider nichts, außer eine nichtssagende Funktionsbeschreibung in https://github.com/Z-Wave-Me/Z-Way-Manual/raw/master/zwayDev.pdf

Die Controller-Funktion gibt es mWn erst ab Chipsatz 500. Alle mir bekannten ZWave+ - Controller haben die Funktion, auch mein Vision. Mein 400er Stick kennt die nicht und Dein Goodway bestimmt auch nicht.

[gamauf]

Ich habe mit meinem ZME_UZB1 seit fast zwei Jahren zum Glück keine Probleme!

[rudolfkoenig]

get <ZWDongle> raw D2

Ah so einfach.

@Barracus/@DeeSpe: koennt ihr das bitte als "define zw_watchdog notify global:INITIALIZED get zwdongle_0 raw D2" einbauen, und testen?
Ich will es nur dann einbauen, wenn es hilft. Oder sieht das jemand anders?