Hi,
seit meinem Update auf die neuste Version von fhem habe ich verstärkt Probleme mit meiner Automatisierung.
Ich nutze einen Raspberry mit Razberry Modul und einer Edimax W-Lan USB Karte.
Mindestens einmal pro Tag stelle ich fest, dass mein Pi auf einmal nicht mehr im WLan ist und somit natürlich auch keine Automatisierungsbefehle annehmen kann. Wenn ich dann die Karte kurz ausstecke und wieder anstecke funktioniert wieder alles.
Ausserdem habe ich, auch bei funktionierendem W-Lan, immer öfter folgende Probleme im Logfile:
2015.10.05 07:15:13 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_12 after 10s for sent:130c03250100250c
2015.10.05 07:15:14 2: ZWave set ZWave_SWITCH_MULTILEVEL_8 on
2015.10.05 07:15:14 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501002508e4
2015.10.05 07:15:15 2: ZWave set ZWave_SWITCH_MULTILEVEL_9 on
2015.10.05 07:15:16 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130a032501FF250a1b
2015.10.05 07:15:16 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_8 after 10s for sent:1308032501002508
2015.10.05 07:15:17 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130d032501FF250d1b
2015.10.05 07:15:18 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130e032501FF250e1b
2015.10.05 07:15:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001302032501FF25021b
2015.10.05 07:15:21 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001306032501FF25061b
2015.10.05 07:15:22 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001307032501FF25071b
2015.10.05 07:15:23 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_7 after 10s for sent:1307032501FF2507
2015.10.05 07:15:23 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001309032501FF25091b
2015.10.05 07:15:25 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001309032501FF25091b
2015.10.05 07:15:25 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_9 after 10s for sent:1309032501FF2509
2015.10.05 07:15:26 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501FF25081b
Zu Automatisierung der Rolläden nutze ich DOIF wie folgt:
([homestatus] eq "home" and [07:15:00-19:30:00|8] or [09:00:00-19:30:00|7]) (set RL_EG_OG_alle Hoch) DOELSEIF ([homestatus] eq "home" and [19:30:01-07:14:59|8] or [19:30:01-09:00:00|7]) (set RL_EG_OG_alle Runter) DOELSEIF ([homestatus] eq "nachtdienst" and [07:14:59-19:30:00|8] or [08:59:59-19:30:00|7]) (set RL_Nachtdienst Runter) DOELSEIF ([homestatus] eq "party" and [19:30:00-07:29:59]) (set RL_Party Runter)
Der homestatus ist ein dummy, welchen ich mit einem einfach set füttere.
Kann mir da bitte jemand helfen?
Danke
Gruss
Dennis
Zitatseit meinem Update auf die neuste Version von fhem
Von welcher Version hast Du das Update gemacht? Schau ggfs. im letzten "restorDir"-Verzeichnis nach.
Hi,
ich kann erst heute Abend genau schauen. Aber ich hatte den Pi bestimmt das letzte mal im Frühjahr geupdatet.
Und dann eben jetzt vor einer Woche aktualisiert.
Gruss
Dennis
So, also gerade hat sich wieder alles komplett aufgehängt.
Laut restoreDir war das letzte Update am 19.08.2015
Anbei nochmal ein Auszug aus dem Log. Um 19.30 Uhr gehen die Rolläden automatisch zu. Aber da fängt es ja schon an mit den Fehlern
2015.10.06 19:30:03 2: ZWave set ZWave_SWITCH_MULTILEVEL_10 off
2015.10.06 19:30:04 2: ZWave set ZWave_SWITCH_MULTILEVEL_14 off
2015.10.06 19:30:04 2: ZWave set ZWave_SWITCH_MULTILEVEL_11 off
2015.10.06 19:30:05 2: ZWave set ZWave_SWITCH_MULTILEVEL_2 off
2015.10.06 19:30:05 2: ZWave set ZWave_SWITCH_MULTILEVEL_12 off
2015.10.06 19:30:05 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130b03250100250be4
2015.10.06 19:30:06 2: ZWave set ZWave_SWITCH_MULTILEVEL_6 off
2015.10.06 19:30:06 2: ZWave set ZWave_SWITCH_MULTILEVEL_13 off
2015.10.06 19:30:06 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001302032501002502e4
2015.10.06 19:30:07 2: ZWave set ZWave_SWITCH_MULTILEVEL_7 off
2015.10.06 19:30:07 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130c03250100250ce4
2015.10.06 19:30:08 2: ZWave set ZWave_SWITCH_MULTILEVEL_8 off
2015.10.06 19:30:09 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001306032501002506e4
2015.10.06 19:30:09 2: ZWave set ZWave_SWITCH_MULTILEVEL_9 off
2015.10.06 19:30:10 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130d03250100250de4
2015.10.06 19:30:11 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001307032501002507e4
2015.10.06 19:30:12 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501002508e4
2015.10.06 19:30:18 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_8 after 10s for sent:1308032501002508
2015.10.06 20:17:23 1: Including fhem.cfg
2015.10.06 20:17:23 3: telnetPort: port 7072 opened
2015.10.06 20:17:25 3: WEB: port 8083 opened
2015.10.06 20:17:25 3: WEBphone: port 8084 opened
2015.10.06 20:17:25 3: WEBtablet: port 8085 opened
2015.10.06 20:17:26 2: eventTypes: loaded 520 events from ./log/eventTypes.txt
2015.10.06 20:17:26 3: Opening ZWAVE1 device /dev/ttyAMA0
2015.10.06 20:17:27 3: Setting ZWAVE1 serial parameters to 115200,8,N,1
2015.10.06 20:17:27 3: ZWAVE1 device opened
2015.10.06 20:17:30 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2015.10.06 20:17:30 3: Opening Arduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXSQ-if00-port0
2015.10.06 20:17:30 3: Setting Arduino serial parameters to 9600,8,N,1
2015.10.06 20:17:30 3: Arduino device opened
2015.10.06 20:34:23 3: Arduino: Possible commands: VifdhtRq
2015.10.06 20:34:23 3: Define: Bowl FHEMduino_PT2262 F00F0F0FFF FF F0
2015.10.06 20:34:23 3: Define: Lampe1 FHEMduino_PT2262 F00F00FFFF FF F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_18_31 FHEMduino_PT2262 F00F0FFFFF 315 0F F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_18_27 FHEMduino_PT2262 F00F0FF0FF 313 0F F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_18_29 FHEMduino_PT2262 F00F0FFF0F 316 0F F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_18_7 FHEMduino_PT2262 F00F000FFF 315 0F F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_2_27 FHEMduino_PT2262 000F0FF0FF 314 0F F0
2015.10.06 20:34:24 3: Define: FHEMduino_PT2262_31_7 FHEMduino_PT2262 FFFFF00FFF 321 0F F0
2015.10.06 20:34:24 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2015.10.06 20:34:24 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2015.10.06 20:34:29 1: Including ./log/fhem.save
2015.10.06 20:34:30 1: statefile: Undefined value 313
2015.10.06 20:34:30 1: usb create starting
2015.10.06 20:34:32 1: usb create end
2015.10.06 20:34:32 2: Error messages while initializing FHEM: statefile: Undefined value 313
2015.10.06 20:34:32 0: Featurelevel: 5.6
2015.10.06 20:34:32 0: Server started with 79 defined entities (version $Id: fhem.pl 9307 2015-09-25 18:44:20Z rudolfkoenig $, os linux, user fhem, pid 2134)
2015.10.06 20:34:32 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
Ich brauche hier wirklich Hilfe.
Danke
Gruss
Dennis
Habe jetzt nochmal ein Update auf die aktuellste Version gemacht.
Anbei das logfile
2015.10.06 20:48:58 1: usb create starting
2015.10.06 20:49:00 1: usb create end
2015.10.06 20:49:00 2: SecurityCheck: WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.10.06 20:49:00 0: Featurelevel: 5.6
2015.10.06 20:49:00 0: Server started with 79 defined entities (version $Id: fhem.pl 9356 2015-10-03 13:41:25Z rudolfkoenig $, os linux, user fhem, pid 2277)
2015.10.06 20:49:00 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2015.10.06 20:49:01 3: ZWave reading config for fibaro/fgrm222.xml
2015.10.06 20:49:23 2: ZWave set ZWave_SWITCH_MULTILEVEL_10 off
2015.10.06 20:49:24 2: ZWave set ZWave_SWITCH_MULTILEVEL_14 off
2015.10.06 20:49:24 2: ZWave set ZWave_SWITCH_MULTILEVEL_11 off
2015.10.06 20:49:25 2: ZWave set ZWave_SWITCH_MULTILEVEL_2 off
2015.10.06 20:49:25 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130b03250100250be4
2015.10.06 20:49:25 2: ZWave set ZWave_SWITCH_MULTILEVEL_12 off
2015.10.06 20:49:26 2: ZWave set ZWave_SWITCH_MULTILEVEL_6 off
2015.10.06 20:49:26 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130b03250100250be4
2015.10.06 20:49:27 2: ZWave set ZWave_SWITCH_MULTILEVEL_13 off
2015.10.06 20:49:27 2: ZWave set ZWave_SWITCH_MULTILEVEL_7 off
2015.10.06 20:49:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130b03250100250be4
2015.10.06 20:49:28 2: ZWave set ZWave_SWITCH_MULTILEVEL_8 off
2015.10.06 20:49:29 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001302032501002502e4
2015.10.06 20:49:29 2: ZWave set ZWave_SWITCH_MULTILEVEL_9 off
2015.10.06 20:49:30 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130c03250100250ce4
2015.10.06 20:49:32 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130c03250100250ce4
2015.10.06 20:49:33 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130c03250100250ce4
2015.10.06 20:49:34 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001306032501002506e4
2015.10.06 20:49:35 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130d03250100250de4
2015.10.06 20:49:36 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130d03250100250de4
2015.10.06 20:49:37 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_13 after 10s for sent:130d03250100250d
2015.10.06 20:49:37 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_7 after 10s for sent:1307032501002507
2015.10.06 20:49:37 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130d03250100250de4
2015.10.06 20:49:38 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001307032501002507e4
2015.10.06 20:49:38 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_8 after 10s for sent:1308032501002508
2015.10.06 20:49:39 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501002508e4
2015.10.06 20:49:39 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_9 after 10s for sent:1309032501002509
2015.10.06 20:49:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501002508e4
2015.10.06 20:49:42 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501002508e4
2015.10.06 20:49:43 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001309032501002509e4
2015.10.06 20:49:53 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/14_FHEMduino_PT2262.pm line 227.
2015.10.06 20:49:53 2: FHEMduino_PT2262 set Bowl on IO_name:Arduino
2015.10.06 20:49:56 2: FHEMduino_PT2262 set Bowl off IO_name:Arduino
2015.10.06 20:49:59 2: FHEMduino_PT2262 set Bowl on IO_name:Arduino
Ich habe folgenden Thread gefunden, aber kann damit nichts anfangen. Scheinbar geht es ja aber um genau die Problematik.
http://forum.fhem.de/index.php/topic,40594.30.html (http://forum.fhem.de/index.php/topic,40594.30.html)
Gruss
Dennis
Was hat sich denn aufgehängt?
Am Anfang hast Du geschrieben, dass sich der WLAN-Stick aufhängt. Also ist doch der WLAN-Stick das Problem!?
Läuft Fhem denn weiter? Funktioniert die Jalousiesteuerung?
Die "no Ack"-Meldungen deuten auf Empfangs- und/oder Konfigurationsprobleme hin. Die könnten auch in der "alten" Fhem-Version dagewesen sein, sind Dir nur evtl. nicht aufgefallen, da das von Fhem nicht überwacht wurde und nicht zu resends führte. Schau mal in alte Logs (oder gehe auf alte Fassung zurück ->restore).
Vielleicht stören sich auch WLAN-Stick und Razberry: Kannst Du den Wlan-Stick nicht mit einer USB-Verlängerung anschließen oder mal per Netzkabel arbeiten?
Der von Dir verlinkte Thread ist aus meiner Sicht überholt.
Hi Krikan,
Danke für Deine Antwort.
Ich werde mal den Pi per LAN Kabel anschließen und versuchen das Problem so weiter einzuschränken.
Allerdings habe ich weder an der Hardware noch am Standort irgendetwas verändert.
Ich habe lediglich auf die neue fhem Version geupdatet und damit hat es angefangen.
Gruss
Dennis
So, ich habe mir mal die alten Logs angeschaut.
Erst mit dem fhem Update am 2.10.2015 haben die Probleme angefangen.
Dort findet sich zum ersten mal folgender Eintrag nach dem Update:
2015.10.02 17:48:17 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
Dann weiter unten:
2015.10.02 17:48:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
Gruss
Dennis
Hallo,
ich habe am 06.10. ein Update durchgeführt und habe seit dem exakt das selbe Problem.
Gleiche Fehlermeldung im log.
Das anlernen von Aktoren wird auch nicht mehr unterstützt: "addNode is unsupported by this controller"
Vor dem Update ließen sich Aktoren problemlos inkludieren.
FHEM läuft auf einem Windows 7 Rechner
Zu den Meldungen, die erst in neueren Versionen kommen:
2015.10.02 17:48:17 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
kein Fehler, sondern nur der Hinweis, dass das Perl-Modul Crypt::Rijndael nicht installiert ist und deshalb die Class SECURITY nicht genutzt werden kann.
Bleibt weg, wenn man das Modul installiert. So lange man SECURITY nicht nutzen will ist das uninteressant.
2015.10.02 17:48:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
Erst einmal nur der Hinweis, dass der Controller den Empfang der Nachricht nicht mit ACK bestätigt hat. Darauf hin verschickt Fhem noch einmal. Für diese Nachricht habe ich die Meldung bei meinem Produktivsystem auch. Der 2. Sendeversuch durch Fhem ist aber dann OK und damit ist die Nachricht mMn hinfällig.
Die Meldung deutet erst dann auf ein tatsächliches Problem hin, wenn sie permanent auftritt und Nachrichten nach x vergeblichen Versuchen verworfen werden:
ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_9 after 10s for sent:1309032501002509
Dann stimmt mMn am System etwas nicht.
Ich bezweifel auch, dass Rudi anhand der Angaben irgendwie dem Problem, wenn es denn ein allgemeines Problem wäre, auf die Spur kommt. Dazu ist das einfach zu unklar udn bietet zu mMn zu wenig Anhaltspunkte.
@alausm: Bitte mehr Details. list <ZWDongle>, logs, usw. (siehe Wiki). Das liest sich nicht nach dem gleichen Problem. Wenn addNode mal funktioniert hat, dann interpretiere ich "addNode is unsupported by this controller" in Richtung defekter fhem.save und/oder sonstiger installationsspezifischer Probleme.
Hallo Krikan,
ich verstehe halt nur nicht, wieso auf einmal am System etwas nicht stimmt, wenn doch vor dem Update immer alles funktioniert hat.
Kannst Du mir sagen, wie ich dem "falschen" System auf die Spur komme?
Danke
Gruss
Dennis
Hallo Dennis,
wenn ich das definitv wüsste, würde ich es Dir schreiben. Es ist aber von Außen schwierig festzustellen. Richtige Ideen habe ich keine.
Ich befürchte halt, dass Du auch vorher die No-Ack hattest und sie Dir nur nicht aufgefallen sind, da Fhem dort nicht so strikt bis gar nicht überwachte.
Mich irritiert bei Deinen kurzen Log-Auszügen, dass anscheinend überhaupt keine ACK vom Controller ankommen und alle Nachrichten nach den wiederholten Sendeversuchen verworfen werden.
Tritt das denn auch ohne Wlan-Stick auf?
Und das Hängen bleiben ist mir auch zu unklar. Bleibt Fhem hängen oder nur der Wlan-Stick?
Hast Du auf dem Raspi evtl. auch Raspian mit Updates versorgt?
Im Prinzip kannst Du probieren, berichten und hoffen, dass Du oder jemand anderes etwas erkennt.
Gruß, Christian
Hallo Krikan,
den test mit dem LAN Kabel starte ich heute Abend.
Updates für Raspbian habe ich keine gemacht. Denkst Du eher ich sollte die machen oder eher vorerst nicht um das Problem besser eingrenzen zu können?
Ich nutze ja das Frontend Tablet UI. Das Tablet ist immer an. Wenn ich dann daran vorbeilaufe, sehe ich auch einmal irgendwelche Errors, die mir Tablet UI angezeigt werden. Wenn ich dann einen Reload der Seite mache, ist fhem nicht mehr erreichbar.
In einem Fall habe ich dann gesehen, dass der Edimax WLAN Stick nicht mehr blau leuchtet. Sprich es war kein W-Lan mehr da.
In einem anderen Fall hat der Stick zwar blau geleuchtet, aber fhem war trotzdem nicht erreichbar.
In beiden Fällen habe ich den Stick kurz abgezogen und wieder eingesteckt. Nach ein paar Sekunden war fhem wieder erreichbar.
Es deutet schon viel darauf hin, dass der Stick vielleicht defekt ist. Ich teste heute Abend mit dem LAN und berichte weiter.
Gruss
Dennis
Zitat von: dennis_n am 07 Oktober 2015, 10:54:47
Denkst Du eher ich sollte die machen oder eher vorerst nicht um das Problem besser eingrenzen zu können?
Persönlich würde ich es lassen, aber wer weis schon....
ZitataddNode is unsupported by this controller
Beim Initialisieren der ZWDongle holt FHEM die "caps" ab, das Ergebnis kann man in der ZWDongle caps Reading bewundern. Danach werden nur die Befehle erlaubt, die laut caps moeglich sind.
Ich habe auch mal gesehen, dass bei fehlerhafter Initialisierung "get caps" nicht beantwortet wurde, und danach nichts mehr ging. "set ZWDongle reopen" sollte das Problem loesen, noch besser waere es, wenn ich wuesste, woran ich kaputte caps erkennen kann. Kannst du bitte deine caps zeigen?
Also bei mir steht folgendes, aber ich denke Du hast alausm gemeint.
ZWAVE1 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 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
Gruss
Dennis
Ich meinte alle die, bei denen die erwaehnte Fehlermeldung kommt.
Da in deiner caps Eintrag ZW_ADD_NODE_TO_NETWORK vorkommt, duerfte die Meldung auch nicht kommen.
Hallo,
ich möchte keinen fremden Thread kapern, aber ich denke meine Fehler passen ganz gut hier hin. Auch ich habe seit einem Update (am 31.07.2015 ???) Probleme mit ZWave:
1. Ich habe 6 Jalousien in einer structure, welche vor dem Update einwandfrei funktionierte. Nach dem Update hatten einige Jalusien des öfteren "No Ack" Meldungen und bewegten sich dem entsprechend nicht (Einzeln kann ich alle Jalousien problemlos bedienen). Durch ein Einfügen von einem async_delay konnte dies behoben werden.
2. In meinem Log sehe ich seit dem Update regelmässig Fehlermeldungen:
ZWDongle_ProcessSendStack: no ACK, resending message 010a001308032501FF25081b
ZWDongle_ProcessSendStack: no ACK, resending message 010a001309032501FF25091b
ZWave: No ACK from JalousieErker_M after 10s for sent:1305032501FF2505
Gruß
Thomas
Ich hatte gehofft, durch das Firmwareupdate meines Sticks von 5.01 auf 5.03 meine Probleme zu lösen. Hat nicht geklappt, der Stick hängt wieder. Keine Meldung im Log. Einzige Auffälligkeit ist im Log meines Fibaro Motion Sensor FGMS-001
2015-10-17_13:54:41 ZWave_SENSOR_BINARY_4 temperature: 20.3 C
2015-10-17_13:57:11 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:13 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:15 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:17 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:19 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:22 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:24 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:26 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:28 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:29 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:29 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:30 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:32 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:35 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:57:59 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:58:00 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:58:00 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:58:00 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
2015-10-17_13:58:00 ZWave_SENSOR_BINARY_4 luminance: 64 Lux
Ein List meines Dongels (noch steht er)
Internals:
CallbackNr 20
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 66
MaxSendRetries 3
NAME ZWDongle_0
NR 581
PARTIAL
RAWMSG 00040004063105030a0040
ReadTime 1445083079.47589
STATE Initialized
SendRetries 0
SendTime 1445079615.70117
TYPE ZWDongle
WaitForAck 0
ZWDongle_0_MSGCNT 1509
ZWDongle_0_TIME 2015-10-17 13:58:00
homeId e3839725
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2015-10-17 11:10:49 caps Vers:5 Rev:3 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-10-17 11:10:49 homeId HomeId:e3839725 CtrlNodeId:01
2015-10-02 10:25:23 neighborList_1 2,5,6
2015-10-15 18:01:37 nodeList 1
2015-10-17 11:10:49 random 87501d6a743325987ae2d54fdbc19b0134d7418365df23d589fdeececd97c4da
2015-10-17 11:10:49 state Initialized
2015-09-20 14:32:46 timeouts 0106640f
2015-10-15 17:25:05 version Z-Wave 4.05 STATIC_CONTROLLER
SendStack:
Attributes:
room ZWave,Server
Ist eigentlich der Eintrag bei den timeouts normal?
Kommen die Sensor-Meldungen auch nach dem Aufhängen?
Antwortet der Dongle auf sowas wie "get ZWDongle_0 random 10" ?
ZitatIst eigentlich der Eintrag bei den timeouts normal?
Ja, und sollte Nicht-Entiwckler nicht interessieren, ist im Modul auch nicht dokumentiert.
Zitat von: rudolfkoenig am 18 Oktober 2015, 12:31:05
Kommen die Sensor-Meldungen auch nach dem Aufhängen?
Nein, nach dem Aufhängen kommen keine Sensor-Meldungen mehr an.
Zitat von: rudolfkoenig am 18 Oktober 2015, 12:31:05
Antwortet der Dongle auf sowas wie "get ZWDongle_0 random 10" ?
Das werde ich dann mal beim nächsten Hänger mal ausprobieren
So, diesmal hatte ich einen Hänger, bei dem zufällig noch verbose 5 aktiv war. Ich hoffe, dass unsere Spezialisten damit etwas anfangen können.
Neben dem Dongle habe ich 2 Sensoren, die regelmäßig Werte liefern:
- PSM02-1 Slim Multi-Sensor - liefert Daten spätestens alle 30 Min.
- FGMS001 Motion Sensor - liefert Daten spätestens alle 10 Min.
Zur Überwachung habe ich ein DOIF (di_zwaveControl), das aktiv wird, wenn der FGMS001 länger als 40 Min. keinen Wert liefert.
Zugeschlagen hat der DOIF um 00:14:24, da der letzte Wert von 23:38:11 war. Der 1. Befehl im DOIF ist der
get ZWDongle_0 random 10
der anscheinend auch beantwortet wird. Danach läuft alles wieder, die Sensoren liefern regelmäßig ihre Daten.
Aufgefallen ist mir, dass die Hänger bisher immer in die Zeit um den Tageswechsel fielen.
Auszug aus dem Log, vor und nach dem Hänger:
2015.11.03 23:24:23 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105030a0036
2015.11.03 23:24:23 5: SW: 06
2015.11.03 23:24:23 5: ZWDongle_0 dispatch 00040004063105030a0036
2015.11.03 23:24:23 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105030a0036
2015.11.03 23:25:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004033003ff
2015.11.03 23:25:24 5: SW: 06
2015.11.03 23:25:24 5: ZWDongle_0 dispatch 00040004033003ff
2015.11.03 23:25:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:033003ff
2015.11.03 23:25:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004032001ff
2015.11.03 23:25:24 5: SW: 06
2015.11.03 23:25:24 5: ZWDongle_0 dispatch 00040004032001ff
2015.11.03 23:25:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:032001ff
2015.11.03 23:25:55 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403300300
2015.11.03 23:25:55 5: SW: 06
2015.11.03 23:25:55 5: ZWDongle_0 dispatch 0004000403300300
2015.11.03 23:25:55 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03300300
2015.11.03 23:25:55 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403200100
2015.11.03 23:25:55 5: SW: 06
2015.11.03 23:25:55 5: ZWDongle_0 dispatch 0004000403200100
2015.11.03 23:25:55 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03200100
2015.11.03 23:27:57 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004033003ff
2015.11.03 23:27:57 5: SW: 06
2015.11.03 23:27:57 5: ZWDongle_0 dispatch 00040004033003ff
2015.11.03 23:27:57 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:033003ff
2015.11.03 23:27:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004032001ff
2015.11.03 23:27:58 5: SW: 06
2015.11.03 23:27:58 5: ZWDongle_0 dispatch 00040004032001ff
2015.11.03 23:27:58 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:032001ff
2015.11.03 23:28:41 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105012200d3
2015.11.03 23:28:41 5: SW: 06
2015.11.03 23:28:41 5: ZWDongle_0 dispatch 00040004063105012200d3
2015.11.03 23:28:41 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105012200d3
2015.11.03 23:29:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403300300
2015.11.03 23:29:24 5: SW: 06
2015.11.03 23:29:24 5: ZWDongle_0 dispatch 0004000403300300
2015.11.03 23:29:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03300300
2015.11.03 23:29:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403200100
2015.11.03 23:29:24 5: SW: 06
2015.11.03 23:29:24 5: ZWDongle_0 dispatch 0004000403200100
2015.11.03 23:29:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03200100
2015.11.03 23:30:09 3: CUL_HM set Zw_Stecker_LM_3_Sw off
2015.11.03 23:34:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105030a0000
2015.11.03 23:34:24 5: SW: 06
2015.11.03 23:34:24 5: ZWDongle_0 dispatch 00040004063105030a0000
2015.11.03 23:34:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105030a0000
2015.11.03 23:35:00 2: Backup with command: tar -cf - fhem.cfg ./FHEM/99_ESXi.cfg ./FHEM/99_Watchdogs.cfg ./log/fhem.save ./CHANGED ./config ./configDB.pm ./contrib ./demolog ./docs ./FHEM ./fhem.cfg ./fhem.cfg.demo ./fhem.pl ./log ./README_DEMO.txt ./restoreDir ./tempList.cfg ./unused ./www |gzip > ./backup/FHEM-20151103_233500.tar.gz
2015.11.03 23:38:00 1: backup done: FHEM-20151103_233500.tar.gz (83446238 Bytes)
2015.11.03 23:38:00 3: SYS_BackupRun return value:
backup done: FHEM-20151103_233500.tar.gz (83446238 Bytes)
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000303800364
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 0004000303800364
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03800364
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000303800364
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 0004000303800364
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03800364
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000303800364
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 0004000303800364
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03800364
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000303800364
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 0004000303800364
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03800364
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003043003000a
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003043003000a
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:043003000a
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003043003000a
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003043003000a
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:043003000a
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003043003000a
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003043003000a
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:043003000a
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003043003000a
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003043003000a
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:043003000a
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003053105030101
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003053105030101
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:053105030101
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003053105030101
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003053105030101
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:053105030101
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003053105030101
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003053105030101
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:053105030101
2015.11.03 23:38:11 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040003053105030101
2015.11.03 23:38:11 5: SW: 06
2015.11.03 23:38:11 5: ZWDongle_0 dispatch 00040003053105030101
2015.11.03 23:38:11 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:053105030101
2015.11.04 00:14:24 4: ZWDongle get ZWDongle_0 random 10
2015.11.04 00:14:24 5: ZWDongle_Write 00 1c0a
2015.11.04 00:14:24 5: SW: 0104001c0aed
2015.11.04 00:14:24 4: ZWDongle_ReadAnswer arg:random regexp:^011c
2015.11.04 00:14:24 5: ACK received, removing 0104001c0aed from dongle sendstack
2015.11.04 00:14:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011c010ad1feae6d32566e35e469
2015.11.04 00:14:24 5: SW: 06
2015.11.04 00:14:24 4: ZWDongle_ReadAnswer for random: 011c010ad1feae6d32566e35e469
2015.11.04 00:14:24 2: di_zwaveControl: get ZWDongle_0 random 10: ZWDongle_0 random => d1feae6d32566e35e469
2015.11.04 00:14:24 2: di_zwaveControl: set pushC6503 message ZWDongle_0 muss neu gestartet werden: OK! Message sent to C6503 (id: 1366)
ZWDongle_0 muss neu gestartet werden
2015.11.04 00:14:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105012200d2
2015.11.04 00:14:24 5: SW: 06
2015.11.04 00:14:24 5: ZWDongle_0 dispatch 00040004063105012200d2
2015.11.04 00:14:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105012200d2
2015.11.04 00:14:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105030a0000
2015.11.04 00:14:24 5: SW: 06
2015.11.04 00:14:24 5: ZWDongle_0 dispatch 00040004063105030a0000
2015.11.04 00:14:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105030a0000
2015.11.04 00:14:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105012200d1
2015.11.04 00:14:24 5: SW: 06
2015.11.04 00:14:24 5: ZWDongle_0 dispatch 00040004063105012200d1
2015.11.04 00:14:24 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105012200d1
2015.11.04 00:14:28 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105030a0000
2015.11.04 00:14:28 5: SW: 06
2015.11.04 00:14:28 5: ZWDongle_0 dispatch 00040004063105030a0000
2015.11.04 00:14:28 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105030a0000
2015.11.04 00:18:47 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040004063105012200d0
2015.11.04 00:18:47 5: SW: 06
Auszug aus dem Log vom PSM02-1
2015-11-03_23:06:35 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-03_23:06:35 ZWave_SENSOR_BINARY_3 temperature: 6.0 C
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 battery: 100 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 battery: 100 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 battery: 100 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 battery: 100 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 doorWindow: 00
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 doorWindow: 00
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 doorWindow: 00
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 doorWindow: 00
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-03_23:38:11 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-04_00:32:31 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-04_00:32:31 ZWave_SENSOR_BINARY_3 temperature: 5.5 C
2015-11-04_00:32:31 ZWave_SENSOR_BINARY_3 wakeup: notification
2015-11-04_01:01:08 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-04_01:01:08 ZWave_SENSOR_BINARY_3 temperature: 5.5 C
2015-11-04_01:29:44 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-04_01:29:44 ZWave_SENSOR_BINARY_3 temperature: 5.0 C
2015-11-04_01:58:19 ZWave_SENSOR_BINARY_3 luminance: 1 %
2015-11-04_01:58:19 ZWave_SENSOR_BINARY_3 temperature: 5.0 C
2015-11-04_02:26:54 ZWave_SENSOR_BINARY_3 luminance: 1 %
Auszug aus dem Log vom FGMS001
2015-11-03_23:22:04 ZWave_SENSOR_BINARY_4 basicSet: 00
2015-11-03_23:24:23 ZWave_SENSOR_BINARY_4 luminance: 54 Lux
2015-11-03_23:25:24 ZWave_SENSOR_BINARY_4 open
2015-11-03_23:25:24 ZWave_SENSOR_BINARY_4 reportedState: open
2015-11-03_23:25:24 ZWave_SENSOR_BINARY_4 basicSet: ff
2015-11-03_23:25:55 ZWave_SENSOR_BINARY_4 closed
2015-11-03_23:25:55 ZWave_SENSOR_BINARY_4 reportedState: closed
2015-11-03_23:25:55 ZWave_SENSOR_BINARY_4 basicSet: 00
2015-11-03_23:27:57 ZWave_SENSOR_BINARY_4 open
2015-11-03_23:27:57 ZWave_SENSOR_BINARY_4 reportedState: open
2015-11-03_23:27:58 ZWave_SENSOR_BINARY_4 basicSet: ff
2015-11-03_23:28:41 ZWave_SENSOR_BINARY_4 temperature: 21.1 C
2015-11-03_23:29:24 ZWave_SENSOR_BINARY_4 closed
2015-11-03_23:29:24 ZWave_SENSOR_BINARY_4 reportedState: closed
2015-11-03_23:29:24 ZWave_SENSOR_BINARY_4 basicSet: 00
2015-11-03_23:34:24 ZWave_SENSOR_BINARY_4 luminance: 0 Lux
2015-11-04_00:14:24 ZWave_SENSOR_BINARY_4 temperature: 21.0 C
2015-11-04_00:14:24 ZWave_SENSOR_BINARY_4 luminance: 0 Lux
2015-11-04_00:14:24 ZWave_SENSOR_BINARY_4 temperature: 20.9 C
2015-11-04_00:14:28 ZWave_SENSOR_BINARY_4 luminance: 0 Lux
2015-11-04_00:18:47 ZWave_SENSOR_BINARY_4 temperature: 20.8 C
2015-11-04_00:24:30 ZWave_SENSOR_BINARY_4 luminance: 0 Lux
2015-11-04_00:28:48 ZWave_SENSOR_BINARY_4 temperature: 20.7 C
2015-11-04_00:34:31 ZWave_SENSOR_BINARY_4 luminance: 0 Lux
2015-11-04_00:38:49 ZWave_SENSOR_BINARY_4 temperature: 20.7 C
Kann das gleiche Problem seit einiger Zeit ebenfalls bestätigen.
System:
-Raspberry Pi B+
-Vision Z-Wave USB Stick ZU 1401 EU (VIS_ZU1401) (http://www.zwave-shopping.com/de/z-wave-terminals/vision-security/147-vision-usb-stick.html) (version Z-Wave 3.41 STATIC_CONTROLLER)
-Fhem: stets aktuell $Id: fhem.pl 9755 2015-11-02 19:34:14Z rudolfkoenig $ (mal 2-3 Tage Verzögerung)
-FIBARO System FGSS101 Smoke Sensor
-FIBARO System FGWPE Wall Plug
-FIBARO System FGMS001 Motion Sensor
-2x Popp / Duwi ZW ZS 3500 Plugin Switch
Dazu ein HomeMatic-USB-Stick und 4x Thermostate HM-CC-RT-DN
Seit einiger Zeit bekommen die Z-Wave-Produkte immer wieder NO_ACK
Beispiel vom FIBARO System FGWPE Wall Plug
2015.11.08 14:58:34.012 5: Cmd: >set Zwischenstecker_1 on<
2015.11.08 14:58:34.019 2: ZWave set Zwischenstecker_1 on
2015.11.08 14:58:34.021 5: ZWDongle_Write 00 1309032501FF2509
2015.11.08 14:58:34.024 5: SW: 010a001309032501FF25091b
2015.11.08 14:58:34.028 5: Triggering Zwischenstecker_1 (1 changes)
2015.11.08 14:58:34.029 5: Notify loop for Zwischenstecker_1 on
2015.11.08 14:58:34.080 4: name: /fhem?cmd.Zwischenstecker_1=set%20Zwischenstecker_1%20on&room=Licht&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.08 14:58:34.083 5: ACK received, removing 010a001309032501FF25091b from dongle sendstack
2015.11.08 14:58:34.084 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 011301
2015.11.08 14:58:34.085 5: SW: 06
2015.11.08 14:58:34.088 5: ZWave_USB_Stick dispatch 011301
2015.11.08 14:58:34.095 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00130900
2015.11.08 14:58:34.096 5: SW: 06
2015.11.08 14:58:34.098 5: ZWave_USB_Stick dispatch 00130900
2015.11.08 14:58:34.100 4: ZWave_USB_Stick CMD:ZW_SEND_DATA ID:00 ARG:
2015.11.08 14:58:34.101 4: ZWave_USB_Stick transmit OK for 09
2015.11.08 14:58:43.185 4: FHEMWEB:192.168.2.101:55573 POST /fhem?cmd.Zwischenstecker_1=set%20Zwischenstecker_1%20off&room=Licht&XHR=1; BUFLEN:0
2015.11.08 14:58:43.188 5: Cmd: >set Zwischenstecker_1 off<
2015.11.08 14:58:43.195 2: ZWave set Zwischenstecker_1 off
2015.11.08 14:58:43.197 5: ZWDongle_Write 00 1309032501002509
2015.11.08 14:58:43.199 5: SW: 010a001309032501002509e4
2015.11.08 14:58:43.203 5: Triggering Zwischenstecker_1 (1 changes)
2015.11.08 14:58:43.205 5: Notify loop for Zwischenstecker_1 off
2015.11.08 14:58:43.268 4: name: /fhem?cmd.Zwischenstecker_1=set%20Zwischenstecker_1%20off&room=Licht&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.08 14:58:43.271 5: ACK received, removing 010a001309032501002509e4 from dongle sendstack
2015.11.08 14:58:43.273 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 011301
2015.11.08 14:58:43.273 5: SW: 06
2015.11.08 14:58:43.276 5: ZWave_USB_Stick dispatch 011301
2015.11.08 14:58:47.597 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00130901
2015.11.08 14:58:47.598 5: SW: 06
2015.11.08 14:58:47.601 5: ZWave_USB_Stick dispatch 00130901
2015.11.08 14:58:47.603 4: ZWave_USB_Stick CMD:ZW_SEND_DATA ID:01 ARG:
2015.11.08 14:58:47.604 2: ZWave_USB_Stick transmit NO_ACK for 09
2015.11.08 14:58:47.609 5: Triggering Zwischenstecker_1 (2 changes)
2015.11.08 14:58:47.610 5: Notify loop for Zwischenstecker_1 TRANSMIT_NO_ACK
Der FIBARO System FGMS001 Motion Sensor sendet oder der Vision Z-Wave USB Stick empfängt sehr unzuverlässig ein open/closed bei Bewegungen oder stellt einfach für x Stunden zufällig auch die Temperatur-Meldungen ein, leider nur als einfaches Log
2015-11-04_08:11:16 FlurMotion temperature: 21.3 C
2015-11-04_08:12:03 FlurMotion closed
2015-11-04_08:12:03 FlurMotion reportedState: closed
2015-11-04_08:12:03 FlurMotion basicSet: 00
2015-11-04_08:12:06 FlurMotion open
2015-11-04_08:12:06 FlurMotion reportedState: open
2015-11-04_08:12:06 FlurMotion basicSet: ff
2015-11-04_08:15:04 FlurMotion closed
2015-11-04_08:15:04 FlurMotion reportedState: closed
2015-11-04_08:15:04 FlurMotion basicSet: 00
2015-11-04_08:16:08 FlurMotion open
2015-11-04_08:16:08 FlurMotion reportedState: open
2015-11-04_08:16:08 FlurMotion basicSet: ff
2015-11-04_08:18:31 FlurMotion closed
2015-11-04_08:18:31 FlurMotion reportedState: closed
2015-11-04_08:18:31 FlurMotion basicSet: 00
..
..
2015-11-04_16:13:20 FlurMotion temperature: 21.1 C
2015-11-04_17:19:13 FlurMotion closed
2015-11-04_17:19:13 FlurMotion reportedState: closed
2015-11-04_17:19:13 FlurMotion basicSet: 00
Angeblich hat er also von 8:16 - 17:19 durchgehend bewegung registriert, bzw "closed" vergessen... komisch ,denn genau in dem Zeitraum war niemand zuhause.. erst als wieder tatsächliche Bewegung wurde "close" gemeldet, dabei soll in der Zeit alle 20 Minuten die Temp melden.
Dieses Verhalten ist häufiger in den letzten Wochen aufgetreten und scheint hier im Post die richtige Heimat zu haben.
NO_ACK passiert auf allen Z-Wave Aktoren, bei dem Homematic habe ich absolut keine Probleme.
Vielleicht/hoffentlich helfen die Logs weiter :)
Bitte http://forum.fhem.de/index.php/topic,43735.msg356420.html#msg356420 beachten.
Und mit geänderten Modulen noch mal testen.
Okay, werde ich morgen testen... habe an dem Post, mit Störungen und Pause knapp 2 Stunden geschrieben :) daher hat es sich zeitlich überschnitten...
Bin mir nicht sicher, ob die neue Version bei Deinem Problem hilft. Aber jetzt alte Versionen zu analysieren ist wenig zielführend.
Wenn es weiterhin Probleme gibt oder Erfolg vorliegt, bitte melden.
Gruß, Christian
Heute Vormittag habe ich ein Update durchgeführt und die 00_ZWDongle.pm & 10_ZWave.pm sind mit aktuellen Zeitstempeln von gestern.
Nach dem Umschalten eines Popp / Duwi ZW ZS 3500 Plugin Switch
2015.11.09 12:51:37.193 2: ZWave set Zwischenstecker_2 on
2015.11.09 12:51:37.197 5: ZWDongle_Write 00 130b032501FF250b
2015.11.09 12:51:37.199 5: SW: 010a00130b032501FF250b1b
2015.11.09 12:51:37.284 5: ACK received, WaitForAck=>2 for 010a00130b032501FF250b1b
2015.11.09 12:51:37.285 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 011301
2015.11.09 12:51:37.286 5: SW: 06
2015.11.09 12:51:37.289 5: ZWave_USB_Stick dispatch 011301
2015.11.09 12:51:39.305 4: no response from device, removing 010a00130b032501FF250b1b from dongle sendstack
2015.11.09 12:51:41.598 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00130b01
2015.11.09 12:51:41.599 5: SW: 06
2015.11.09 12:51:41.605 5: ZWave_USB_Stick dispatch 00130b01
2015.11.09 12:51:41.608 4: ZWave_USB_Stick CMD:ZW_SEND_DATA ID:01 ARG:
2015.11.09 12:51:41.609 2: ZWave_USB_Stick transmit NO_ACK for 0b
2015.11.09 12:51:47.206 2: ZWave: No ACK from Zwischenstecker_2 after 10s for sent:130b032501FF250b
2015.11.09 12:54:04.342 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00040008063105012200e4
2015.11.09 12:54:04.343 5: SW: 06
2015.11.09 12:54:04.348 5: ZWave_USB_Stick dispatch 00040008063105012200e4
2015.11.09 12:54:04.351 4: ZWave_USB_Stick CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105012200e4
2015.11.09 12:56:18.334 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00040010028407
2015.11.09 12:56:18.335 5: SW: 06
2015.11.09 12:56:18.338 5: ZWave_USB_Stick dispatch 00040010028407
2015.11.09 12:56:18.340 4: ZWave_USB_Stick CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:028407
2015.11.09 12:56:20.409 5: ZWDongle_Write 00 13100284082510
2015.11.09 12:56:20.411 5: SW: 010900131002840825104e
2015.11.09 12:56:20.417 5: ACK received, WaitForAck=>2 for 010900131002840825104e
2015.11.09 12:56:20.418 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 011301
2015.11.09 12:56:20.419 5: SW: 06
2015.11.09 12:56:20.421 5: ZWave_USB_Stick dispatch 011301
2015.11.09 12:56:20.431 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00131000
2015.11.09 12:56:20.432 5: SW: 06
2015.11.09 12:56:20.434 5: device ack reveived, removing 010900131002840825104e from dongle sendstack
2015.11.09 12:56:20.436 5: ZWave_USB_Stick dispatch 00131000
2015.11.09 12:56:20.437 4: ZWave_USB_Stick CMD:ZW_SEND_DATA ID:00 ARG:
2015.11.09 12:56:20.438 4: ZWave_USB_Stick transmit OK for 10
2015.11.09 12:56:28.374 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00040010063105012200e3
2015.11.09 12:56:28.375 5: SW: 06
2015.11.09 12:56:28.379 5: ZWave_USB_Stick dispatch 00040010063105012200e3
2015.11.09 12:56:28.382 4: ZWave_USB_Stick CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:063105012200e3
Ansonsten scheint es das gleich wie in dem Post zu sein: http://forum.fhem.de/index.php/topic,43413.0.html
Ich sehe hier ein set um 12:51:37, was vom Geraet nicht bestaetigt wurde (00130b01). Da parallel keine weitere Kommunikation stattfand, liegt das nicht an den Modifkiationen von gestern, ich vermute, Zwischenstecker_2 ist entweder nicht im Betrieb, nicht erreichbar oder nicht inkludiert. Danach kommen irgendwelche Nachrichten rein, ohne Probleme.
Zitat von: rudolfkoenig am 09 November 2015, 15:51:05
...ich vermute, Zwischenstecker_2 ist entweder nicht im Betrieb, nicht erreichbar oder nicht inkludiert....
Das betrifft ALLE Aktoren(3 Zwischenstecker), schalten tun sie alle trotzdem.
Innerhalb der nächsten 10 Sekunden reagieren die aber auf keine weiteren set- oder get-Befehle und/oder es kommt zum Timeout.
Sie liefen ja Monatelang (1x Fibaro seit 2'2015 + 2x POPP/DÜWI seit 5'2015)problemlos, bloß seit einigen Wochen ständig "NO_ACK".. was Schaltungen mit "toggle" ziemlich träge oder unmöglich macht, sowie Notify auch nicht zuverlässig funktioniert, weil der State ja schließlich bei on und off auf NO_ACK steht.
Das es mit den Befehlen erst 10 Sekunden spaeter losgeht, ist ein FHEM-"Problem".
Das die Bestaetigung der Aktoren nicht eintrifft, bzw. dass NO_ACK gemeldet wird, ist von FHEM unabhaengig.
Ahoi, alles gemacht:
- stromlos
- exkludiert
- device aus Fhem gelöscht
- inkludiert
Problem besteht weiter :(
2015.11.09 20:55:14.100 2: ZWave set Zwischenstecker_1 on
2015.11.09 20:55:14.102 5: ZWDongle_Write 00 1312032501FF2512
2015.11.09 20:55:14.104 5: SW: 010a001312032501FF25121b
2015.11.09 20:55:14.162 5: ACK received, WaitForAck=>2 for 010a001312032501FF25121b
2015.11.09 20:55:14.163 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 011301
2015.11.09 20:55:14.164 5: SW: 06
2015.11.09 20:55:14.167 5: ZWave_USB_Stick dispatch 011301
2015.11.09 20:55:16.178 4: no response from device, removing 010a001312032501FF25121b from dongle sendstack
2015.11.09 20:55:18.593 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 00131201
2015.11.09 20:55:18.598 5: SW: 06
2015.11.09 20:55:18.602 5: ZWave_USB_Stick dispatch 00131201
2015.11.09 20:55:18.604 4: ZWave_USB_Stick CMD:ZW_SEND_DATA ID:01 ARG:
2015.11.09 20:55:18.605 2: ZWave_USB_Stick transmit NO_ACK for 12
2015.11.09 20:55:25.275 2: ZWave: No ACK from Zwischenstecker_1 after 10s for sent:1312032501FF2512Es ist egal, welchen Zwischenschalter ich benutze. Immer das gleiche.
Entfernung ~5 Meter, fast Sichtkontakt, keine feste Wand dazwischen.
Wenn du noch weitere Logs brauchst, sag bescheid wie.
Dann mal munteres Brainstorming (bezweifel, dass das ein Fhem Problem ist):
Hast Du immer NO_ACK oder auch mal ACK?
Ist nodeList sauber und neigborUpdate durchgeführt?
Assoziationen sind korrekt gesetzt?
Könntest Du den Fibaro Zwischenstecker näher an das Dongle bringen (Abstand max. ca. 3m und freie Sicht) und dann mal testen?
3 Meter, Sichtkontakt
Zitat von: krikan am 09 November 2015, 21:23:37
Ist nodeList sauber und neigborUpdate durchgeführt?
get Zwischenstecker_1 neighborList = Timeout reading answer for get neighborList
015.11.09 21:42:28.918 2: ZWave get Zwischenstecker_1 neighborList
2015.11.09 21:42:28.919 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.11.09 21:42:31.923 5: ZWDongle_ReadAnswer: select timeout
2015.11.09 21:42:34.205 2: ZWave: No ACK from Zwischenstecker_1 after 10s for sent:4812
2015.11.09 21:42:34.209 5: ZWDongle_Write 00 80120101
2015.11.09 21:42:34.212 5: SW: 010600801201016b
2015.11.09 21:42:34.220 5: ACK received, removing 010600801201016b from dongle sendstack
2015.11.09 21:42:34.222 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 01800106000000000000000000000000000000000000000000000000000000
2015.11.09 21:42:34.223 5: SW: 06
2015.11.09 21:42:34.226 5: ZWave_USB_Stick dispatch 01800106000000000000000000000000000000000000000000000000000000
2015.11.09 21:42:34.230 4: ZWave_USB_Stick unhandled ANSWER: GET_ROUTING_TABLE_LINE 0106000000000000000000000000000000000000000000000000000000
2015.11.09 21:42:44.222 2: ZWave: No ACK from Zwischenstecker_1 after 10s for sent:80120101Beim Schalten habe ich kein aktuell kein NO_ACK.
Und noch beim Post schreiben:
get Zwischenstecker_1 neighborList
2015.11.09 21:49:19.954 2: ZWave get Zwischenstecker_1 neighborList
2015.11.09 21:49:19.956 5: ZWDongle_Write 00 80120101
2015.11.09 21:49:19.959 5: SW: 010600801201016b
2015.11.09 21:49:19.962 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.11.09 21:49:19.964 5: ACK received, removing 010600801201016b from dongle sendstack
2015.11.09 21:49:19.966 4: ZWDongle_Read ZWave_USB_Stick: sending ACK, processing 01800106000000000000000000000000000000000000000000000000000000
2015.11.09 21:49:19.967 5: SW: 06
2015.11.09 21:49:19.970 4: ZWDongle_ReadAnswer for neighborList: 01800106000000000000000000000000000000000000000000000000000000Was ich bloß verwunderlich finde, warum es bei allein Geräten der Fall ist ?
Frisch ausgeführt:
get ZWave_USB_Stick nodeList =
ZWave_USB_Stick nodeList => ZWave_USB_Stick UNKNOWN_2 UNKNOWN_3 UNKNOWN_4 UNKNOWN_5 UNKNOWN_6 UNKNOWN_7 Zwischenstecker_3 UNKNOWN_15 FlurMotion UNKNOWN_17 Zwischenstecker_1
Komisch, aber irgendwie standen dort zuvor nur IDs
Zitat von: krikan am 09 November 2015, 21:23:37
Assoziationen sind korrekt gesetzt?
Ja, Fibaro = assocGroups 3
Hab mal den "Vision Z-Wave USB Stick ZU 1401 EU" in einen aktiven USB-Hub umgesteckt... evtl hilft das etwas...
Zitatget ZWave_USB_Stick nodeList
Komisch, aber irgendwie standen dort zuvor nur IDs
Hat Rudi eben geändert, ist OK. Aber die nodeList enthält mir zu viele UNKNOWN. Woher kommen die? Mein Standardratschlag: Wenn das tote Nodes sind, bitte entfernen. Dann bitte neigborUpdate durchführen.
ZitatWas ich bloß verwunderlich finde, warum es bei allein Geräten der Fall ist ?
Darum tippe ich auf Dongle-Problem oder Betriebssystem/Rechner-Problem.
Hatte mit meinem Vision-Stick auch schon mal seltsame Probleme, die nach längerem stromlos und anderen Experimenten plötzlich weg waren. Aber wissen tue ich es nicht.
Leider sehe ich keinen sinnvollen Ansatzpunkte. Wie geschrieben, denke ich, dass das Problem systemspezifisch ist. Vielleicht sieht jemand anderes noch Ansatzpunkte.
Zitat von: krikan am 09 November 2015, 22:18:56
Hat Rudi eben geändert, ist OK. Aber die nodeList enthält mir zu viele UNKNOWN. Woher kommen die? Mein Standardratschlag: Wenn das tote Nodes sind, bitte entfernen. Dann bitte neigborUpdate durchführen.
Habe vor einigen Tagen die nodeList durchgeforstet in der Hoffnung, dass es Besserung bringt, danach war diese auch sauber.
Warum die plötzlich fast alle "UNKNOWN_x" heißen ist mir ein Rätsel.
Hier mal ne weitere handvoll Informationen:
Internals:
CallbackNr 4
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 4
MaxSendRetries 3
NAME ZWave_USB_Stick
NR 20
PARTIAL
RAWMSG 00040008063105012200f1
ReadTime 1447104839.06281
STATE Initialized
SendRetries 0
SendTime 1447104815.5248
TYPE ZWDongle
WaitForAck 0
ZWave_USB_Stick_MSGCNT 531
ZWave_USB_Stick_TIME 2015-11-09 22:33:59
homeId dda1f8e9
nodeIdHex 01
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2015-11-09 22:09:24 caps Vers:1 Rev:74 ManufID:0109 ProductType:1001 ProductID:0101 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 ZW_SET_R_F_RECEIVE_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 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_65 UNKNOWN_66 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE 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_ee UNKNOWN_ef
2015-11-09 22:09:24 homeId HomeId:dda1f8e9 CtrlNodeId:01
2015-11-09 22:33:04 nodeInfo_10 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
2015-11-09 22:33:08 nodeInfo_11 node 11 is not present
2015-11-09 22:33:11 nodeInfo_12 node 12 is not present
2015-11-09 22:33:13 nodeInfo_13 node 13 is not present
2015-11-09 22:33:15 nodeInfo_14 node 14 is not present
2015-11-09 22:33:18 nodeInfo_15 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:33:20 nodeInfo_16 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:33:23 nodeInfo_17 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:33:30 nodeInfo_18 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:33:32 nodeInfo_19 node 19 is not present
2015-11-09 22:30:36 nodeInfo_2 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:33:35 nodeInfo_20 node 20 is not present
2015-11-09 22:30:43 nodeInfo_3 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:31:17 nodeInfo_4 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:31:24 nodeInfo_5 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-11-09 22:32:58 nodeInfo_8 node 8 is not present
2015-11-09 22:33:01 nodeInfo_9 node 9 is not present
2015-11-09 22:30:58 nodeList ZWave_USB_Stick UNKNOWN_2 UNKNOWN_3 UNKNOWN_4 UNKNOWN_5 UNKNOWN_6 UNKNOWN_7 Zwischenstecker_3 UNKNOWN_15 FlurMotion UNKNOWN_17 Zwischenstecker_1
2015-11-09 22:09:24 random d7bca3c8f95f20ab3f8ed1b3c64bdcab7b9f1af3ec4f7d7dd3d59d6900ec35d8
2015-11-09 22:09:24 state Initialized
2015-11-09 21:57:50 version Z-Wave 3.41 STATIC_CONTROLLER
SendStack:
Attributes:
devStateIcon Initialized:10px-kreis-gruen
icon cul_868
room System,ZWave
verbose 5 2015-11-09 22:33:04 nodeInfo_10 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0 Zwischenstcker_3 = Popp / Duwi ZW ZS 3500 Plugin Switch
2015-11-09 22:33:20 nodeInfo_16 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0FlurMotion = FIBARO System FGMS001 Motion Sensor
2015-11-09 22:33:30 nodeInfo_18 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0Zwischenstecker_1 = FIBARO System FGWPE Wall Plug
ABER:
Zwischenstecker_ 2 = nodeIdHex = 0b, was ja 11 entspricht, aber "node 11 is not present"... Popp / Duwi ZW ZS 3500 Plugin Switch
Rauchmelder_WoZi = nodeIdHex = 08, was ja 8 entspricht, aber "node 8 is not present"... FIBARO System FGSS101 Smoke Sensor
hab ich da einen Gedankenfehler?
Werde heute Nacht den Stick mal Stromlos machen, vielleicht tritt ja Wunderheilung ein :)
Ahoi,
also eine Nacht ohne Strom gab keine nennenswerte Besserung in Bezug auf dem Fibaro Motion-Sensor.
Aber die Zwischenstecker(Aktoren) laufen nun zuverlässiger.
Den Motion-Sensor habe ich ausgetauscht, nun hat dieser die Version "Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7" zuvor war es FW 2.6
Folgendes fiel im Log auf:
2015-11-18_22:40:29 ZWave_SENSOR_BINARY_19 UNPARSED: SENSOR_BINARY 03300340
2015-11-19_07:28:01 ZWave_SENSOR_BINARY_19 basicSet: df
2015-11-19_07:45:43 ZWave_SENSOR_BINARY_19 closed
2015-11-19_07:45:43 ZWave_SENSOR_BINARY_19 reportedState: closed
2015-11-19_07:45:43 ZWave_SENSOR_BINARY_19 basicSet: 00
2015-11-19_07:46:40 ZWave_SENSOR_BINARY_19 basicSet: ff
2015-11-19_07:47:07 ZWave_SENSOR_BINARY_19 closed
2015-11-19_07:47:07 ZWave_SENSOR_BINARY_19 reportedState: closed
2015-11-19_07:47:07 ZWave_SENSOR_BINARY_19 basicSet: 00
.
nun läuft es ne weile alles "normal"
.
2015-11-19_08:16:03 ZWave_SENSOR_BINARY_19 open
2015-11-19_08:16:03 ZWave_SENSOR_BINARY_19 reportedState: open
2015-11-19_08:16:04 ZWave_SENSOR_BINARY_19 basicSet: ff
2015-11-19_08:18:16 ZWave_SENSOR_BINARY_19 basicSet: 00
2015-11-19_08:48:05 ZWave_SENSOR_BINARY_19 temperature: 21.8 C
2015-11-19_09:28:24 ZWave_SENSOR_BINARY_19 wakeup: notification
2015-11-19_09:28:31 ZWave_SENSOR_BINARY_19 TRANSMIT_NO_ACK
2015-11-19_09:28:31 ZWave_SENSOR_BINARY_19 transmit: NO_ACKEs wird zwar auf "basicSet: 00" gesetzt, aber FHEM bei Fhem bleibt der "reportedState"-Status bleibt "open"
Was ist der Unterschied dann noch zu
2015-11-19_07:28:01 ZWave_SENSOR_BINARY_19 basicSet: df
?
2015-11-19_07:45:43 ZWave_SENSOR_BINARY_19 basicSet: 00
open
2015-11-19_07:46:40 ZWave_SENSOR_BINARY_19 basicSet: ff
closed
list ZWave_SENSOR_BINARY_19
ZitatInternals:
DEF dda1f8e9 19
IODev ZWave_USB_Stick
LASTInputDev ZWave_USB_Stick
MSGCNT 508
NAME ZWave_SENSOR_BINARY_19
NR 121
STATE TRANSMIT_NO_ACK
TYPE ZWave
ZWave_USB_Stick_MSGCNT 508
ZWave_USB_Stick_RAWMSG 00040013063105012200da
ZWave_USB_Stick_TIME 2015-11-19 09:48:34
homeId dda1f8e9
isWakeUp 1
lastMsgSent 1447921704.5083
nodeIdHex 13
Readings:
2015-11-17 20:23:41 CMD ZW_APPLICATION_UPDATE
2015-11-18 22:40:29 UNPARSED SENSOR_BINARY 03300340
2015-11-17 20:33:22 alarm_type_00 level ff node 13 seconds 0
2015-11-17 20:23:41 assocGroups 3
2015-11-19 08:18:16 basicSet 00
2015-11-17 20:21:19 battery 100 %
2015-11-17 20:33:49 configIntervalOfTemperatureMeasuring 600
2015-11-17 21:00:06 configPIRSensorOperatingMode PIRSensorAlwaysActive
2015-11-17 20:56:02 configTemperatureReportsInterval 3600
2015-11-17 20:24:47 luminance 7 Lux
2015-11-17 20:20:36 model FIBARO System FGMS001 Motion Sensor
2015-11-17 20:20:36 modelConfig fibaro/fgms.xml
2015-11-17 20:20:36 modelId 010f-0800-1001
2015-11-19 08:16:03 reportedState open
2015-11-19 09:28:31 state TRANSMIT_NO_ACK
2015-11-19 09:48:34 temperature 21.8 C
2015-11-19 09:28:31 transmit NO_ACK
2015-11-17 20:23:42 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2015-11-19 09:28:24 wakeup notification
2015-11-17 20:24:44 wakeupReport interval 60 target 1
Attributes:
IODev ZWave_USB_Stick
alias Sensor Flur
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:message_presence_disabled open:people_sensor TRANSMIT_NO_ACK:Wecker.Immer
fp_home 252,856,6,temperature,
group ALARM,Sensor
icon motion_detector
room Flur,ZWave
verbose 5
Hat jemand eine Idee dazu?
Habe für den Z-Wave-USB-Stick nun auch verbose 5 eingeschaltet, vielleicht sieht man noch mehr.
Werde morgen(sobald eintrifft) das USB-Verlängerungskabel zum Stick austauschen, das ist nämlich recht alt.
Welche Assoziationen hast Du gesetzt?
"basicSet" könnte aus Assogroup1 kommen und "reportedState" aus Assogroup 3.
Was wird bzw. lässt Du in Assogroup 1 melden?
Wegen NO_ACK vermute ich (weiterhin) eine schlechte Funkverbindung und FHEM-unabhängige Systemprobleme.
Eigentlich ist der Motion-Sensor in "assocGroups 3" eingebunden.
Ist ja auch als Readings eingetragen.
Wenn ich das richtig verstanden habe, dann kann der Fibaro nur in einer Associations-Groupe sein, die habe ich beim einbinden auf 3 gesetzt mit dem Ziel "1"
also:
"set ZWave_SENSOR_BINARY_19 associationAdd 3 1"
Daher verwirrt mich deine Antwort etwas.
Es besteht noch immer direkter Sichtkontakt bei etwa 5 Metern.
Das komische ist ja, dass es mal ja, mal nicht >funkt<ioniert.
Zitat von: Chlorex am 19 November 2015, 14:04:19
Eigentlich ist der Motion-Sensor in "assocGroups 3" eingebunden.
Ist ja auch als Readings eingetragen.
Nein, das Reading gibt an, wieviele AssocGroups Dein Sensor hat.
Zitat
Wenn ich das richtig verstanden habe, dann kann der Fibaro nur in einer Associations-Groupe sein, die habe ich beim einbinden auf 3 gesetzt mit dem Ziel "1"
also:
"set ZWave_SENSOR_BINARY_19 associationAdd 3 1"
Nein, der Fibaro hat 3 AsscoGroups, in der jeweils eine bestimmte Anzahl von Geräten sein können.
Du hast in AssocGroup 3 des Sensors den Controller (Node 1) aufgenommen.
Bei der Inklusion nimmt FHEM den Controller per default in AssocGroup 1 des Sensors auf.
http://www.fhemwiki.de/wiki/Z-Wave#Assoziation
Wenn Du mal "set <device> associationRequestAll" abrufst (http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F), dann siehst Du, welcher Node in welcher AssocGroup steckt.
Zitat
Daher verwirrt mich deine Antwort etwas.
Hoffe es ist etwas klarer. Ansonsten fragen....
Zitat
Das komische ist ja, dass es mal ja, mal nicht >funkt<ioniert.
Deutet eben auf Störungen hin, egal wie weit oder nah entfernt.
Ahoi,
dachte die "2015-11-19 19:33:25 assocGroups 3" ist die Angabe in welcher Gruppe der USB-Stick ist.
set ZWave_SENSOR_BINARY_19 associationRequestAll
später (wakeUp abwarten) und siehe da: der USB-Stick ist in Gruppe 1+3 eingetragen.
ZitatInternals:
DEF dda1f8e9 19
IODev ZWave_USB_Stick
LASTInputDev ZWave_USB_Stick
MSGCNT 646
NAME ZWave_SENSOR_BINARY_19
NR 121
STATE versionClassRequest MANUFACTURER_SPECIFIC
TYPE ZWave
ZWave_USB_Stick_MSGCNT 646
ZWave_USB_Stick_RAWMSG 00040013063105012200f7
ZWave_USB_Stick_TIME 2015-11-19 20:04:51
homeId dda1f8e9
isWakeUp 1
lastMsgSent 1447959888.02224
nodeIdHex 13
Readings:
2015-11-19 20:04:14 CMD ZW_APPLICATION_UPDATE
2015-11-18 22:40:29 UNPARSED SENSOR_BINARY 03300340
2015-11-19 20:04:51 alarm_type_00 level ff node 13 seconds 0
2015-11-19 19:33:31 assocGroup_1 Max 5 Nodes ZWave_USB_Stick
2015-11-19 19:33:35 assocGroup_2 Max 5 Nodes
2015-11-19 19:33:36 assocGroup_3 Max 1 Nodes ZWave_USB_Stick
2015-11-19 19:33:25 assocGroups 3
2015-11-19 20:03:41 basicSet ff
2015-11-17 20:21:19 battery 100 %
2015-11-19 20:04:16 configAmbientIlluminationLevelAbove83 1000
2015-11-19 20:04:17 configAmbientIlluminationLevelBelow82 100
2015-11-19 20:04:18 configBASICOFFCommandFrameValue 0
2015-11-19 20:04:19 configBASICONCommandFrameValue 255
2015-11-19 20:04:20 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2015-11-19 20:04:21 configIlluminationReportThreshold 0
2015-11-19 20:04:22 configIlluminationReportsInterval 0
2015-11-19 20:04:23 configIntervalOfTemperatureMeasuring 600
2015-11-19 20:04:24 configLEDBrightness 50
2015-11-19 20:04:26 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2015-11-19 20:04:27 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2015-11-19 20:04:28 configMaximumTemperatureResultingInRed87 28
2015-11-19 20:04:29 configMinimumTemperatureResultingIn86 18
2015-11-19 20:04:30 configMotionAlarmCancellationDelay 30
2015-11-19 20:04:31 configMotionSensorSBlindTime2 15
2015-11-19 20:04:32 configMotionSensorSSensitivity 10
2015-11-19 20:04:33 configNightDay 200
2015-11-19 20:04:34 configPIRSensorOperatingMode PIRSensorAlwaysActive
2015-11-19 20:04:36 configPIRSensorSPulseCounter 1
2015-11-19 20:04:37 configPIRSensorSWindowTime 2
2015-11-19 20:04:38 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2015-11-19 20:04:39 configTamperAlarmCancellationDelay 30
2015-11-19 20:04:40 configTamperOperatingModes Tamper
2015-11-19 20:04:42 configTamperSensitivity 15
2015-11-19 20:04:43 configTemperatureOffset 0
2015-11-19 20:04:45 configTemperatureReportThreshold 2
2015-11-19 20:04:46 configTemperatureReportsInterval 3600
2015-11-19 20:04:51 luminance 7 Lux
2015-11-17 20:20:36 model FIBARO System FGMS001 Motion Sensor
2015-11-17 20:20:36 modelConfig fibaro/fgms.xml
2015-11-17 20:20:36 modelId 010f-0800-1001
2015-11-19 20:03:41 reportedState open
2015-11-19 20:04:48 state versionClassRequest MANUFACTURER_SPECIFIC
2015-11-19 20:04:51 temperature 24.7 C
2015-11-19 20:04:50 transmit OK
2015-11-17 20:23:42 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2015-11-19 19:33:25 wakeup notification
2015-11-19 20:04:15 wakeupReport interval 7200 target 1
Attributes:
IODev ZWave_USB_Stick
alias Sensor Flur
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:message_presence_disabled open:people_sensor TRANSMIT_NO_ACK:Wecker.Immer
fp_Hassestrasse 252,856,6,temperature,
group ALARM,Sensor
icon motion_detector
room Flur,ZWave
vclasses ASSOCIATION:02 BASIC:01 BATTERY:01 CONFIGURATION:01 CRC_16_ENCAP:01 MANUFACTURER_SPECIFIC:01 MULTI_CHANNEL_ASSOCIATION:02 MULTI_CMD:01 SENSOR_ALARM:01 SENSOR_BINARY:01 SENSOR_MULTILEVEL:05 VERSION:02 WAKE_UP:01
verbose 5
Dann mal die association des Controllers mit Assocdroup 1 löschen. Dann verschwindet "basicSet" vermutlich und open/closed werden nur noch gemeldet. Das wird aber am unzuverlässigen Empfang nichts ändern.
Darf man den Node "UNKNOWN_2" eigentlich löschen?
Ist das ein Fehler bei mir, wenn dieser in der Nodelist auftaucht?
ZitatDarf man den Node "UNKNOWN_2" eigentlich löschen?
Sicher doch, man muss nur mit den Konsequenzen leben :)
ZitatIst das ein Fehler bei mir, wenn dieser in der Nodelist auftaucht?
UNKNOWN_2 bedeutet, dass der USB-Stick ein Endgeraet kennt, was im FHEM nicht definiert ist.
Mein USB-Stick kam z.Bsp. "neu" mit so einem Node, entweder war der Stick nicht ganz neu, oder bei der Herstellung wird die Funktionsweise getestet, indem man es mit einem Geraet paart, und danach das Reset vergisst.
Okay. Danke.
Das habe ich einfach mal riskiert. :-)
Ich hatte die Hoffnung, dass der folgende Fehler dann bei mir verschwindet:
ZWDongle_ProcessSendStack: no ACK, resending message
Ich hole mir im 5-Minuten-Takt (get xyz meter 2) den Stromverbauch von meinen Greenwave-Zwischensteckern. Und die erzeugen immer den o.g. Hinweis im Log. Ich werde das einfach nicht los. Auch nicht, wenn ich "verbose" verkleinere.
ZitatIch hatte die Hoffnung, dass der folgende Fehler dann bei mir verschwindet:
Wenn ja, dann haette mich das extrem ueberrascht.
Deine Schilderung des Problems erinnert mich an die Kuh Elsa :)
ZitatUnd die erzeugen immer den o.g. Hinweis im Log.
Kannst du bitte das ZWDongle und das Geraet selbst mit verbose 5 versehen, und ein "Problemlog" hier anhaengen? Was fuer ein ZWDongle hast du?
ZitatIch werde das einfach nicht los. Auch nicht, wenn ich "verbose" verkleinere.
attr ZWDongle_0 verbose 1
Ich verzichte jetzt erst einmal auf ein verbose5-Log, da ich den Fehler scheinbar losgeworden bin. Ich hatte folgenden Code:
get zw_sw1 meter 2,
get zw_sw2 meter 2
Die Befehle wurden direkt hintereinander ausgeführt. Das hat scheinbar die Log-Fehler verursacht.
Ich habe nun (in meinem DOIF) ein 5-Sekunden-Wait eingebaut und nun habe ich keine Fehlermeldungen mehr.
Falls notwendig kann ich aber gerne ein Log anfertigen.
---
Ich habe übrigens den ZME UZB Stick.
---
Update
Sorry, ich muss noch einmal nachfragen: Ist das ein Bug, wenn die Meldungen erscheinen, wenn man zu schnell hintereinander sendet? Sollten wir Anwender hier darauf achten, eine Pause einzubauen? Oder ist eher eine Sache, die in der Hardware oder auch in FHEM abgefangen werden sollten? Danke für eine Antwort.