Readings bei batteriebetriebenen Geräten

9zehn75 · 22 Februar 2016, 20:23:42

Ich habe mittlerweile elf Fibaro Fenstersensoren in Betrieb. Ich bekomme es aber nicht hin, von diesen Antworten auf Anfragen wie "get neighborList" zu erhalten. Die Nachrichten werden beim Wake-Up rausgeschickt, die Readings werden aber nicht gefüllt. Das gilt für alle elf Fenstersensoren.

Hier mal exemplarisch ein list:

Code Auswählen

Internals: 
   DEF        dfe4e1ee 8 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     1 
   NAME       Fenster_Keller_Sport 
   NR         56 
   STATE      closed 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 1 
   ZWDongle_0_RAWMSG 00040008028407 
   ZWDongle_0_TIME 2016-02-22 19:22:47 
   homeId     dfe4e1ee 
   isWakeUp   1 
   lastMsgSent 1456165367.15235 
   nodeIdHex  08 
   Readings: 
     2016-02-21 19:29:01   basicSet        00 
     2016-02-13 19:56:06   model           FIBARO System FGK101 Door Opening Sensor 
     2016-02-13 19:56:06   modelConfig     fibaro/fgk001.xml 
     2016-02-13 19:56:06   modelId         010f-0700-1000 
     2016-02-16 19:50:39   state           TRANSMIT_NO_ACK 
     2016-02-22 19:22:49   transmit        OK 
     2016-02-22 19:22:47   wakeup          notification 
   SendStack: 
     get:80080100 
Attributes: 
   IODev      ZWDongle_0 
   classes    SENSOR_BINARY SENSOR_ALARM ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC 
   eventMap   ff:open 00:closed 
   group      Fenster 
   room       Fenster,Keller,ZWave 
   stateFormat basicSet 
   verbose    5

Die eine Nachricht, die noch da ist, habe ich gerade eben wieder abgesetzt (wiederum ein get neighborList).

Mache ich was falsch oder ist das ein Denkfehler, dass da nach dem Aufwachen was zurückgeliefert werden sollte? So hatte ich das Wiki jedenfalls verstanden.

krikan · 22 Februar 2016, 20:31:24

Zitat von: 9zehn75 am 22 Februar 2016, 20:23:42
Ich habe mittlerweile elf Fibaro Fenstersensoren in Betrieb. Ich bekomme es aber nicht hin, von diesen Antworten auf Anfragen wie "get neighborList" zu erhalten. Die Nachrichten werden beim Wake-Up rausgeschickt, die Readings werden aber nicht gefüllt. Das gilt für alle elf Fenstersensoren.

Mache ich was falsch oder ist das ein Denkfehler, dass da nach dem Aufwachen was zurückgeliefert werden sollte? So hatte ich das Wiki jedenfalls verstanden.

Ob falsch oder nur Kommunikationsfehler (Hinweis: TRANSMIT_NO_ACK) vorliegen, kann ich ohne Log mit verbose 5 nicht wirklich beurteilen. Aber "get neighborList" sollte etwas zurückliefern. Befürchte eher (bekomme von Dir wahrscheinlich bald Antwortverbot

) Probleme wegen der vielen Controller...

rudolfkoenig · 22 Februar 2016, 20:32:17

Ja, reading wird gefuellt, wenn Nachricht zurueckkommt.
Wenn im Zweifel, dann "attr ZWDongle_0 verbose 5" setzen, und das Log vor/nach wakeup:notification hier zeigen.

9zehn75 · 22 Februar 2016, 21:56:13

Die meisten meiner Versuche stammen aus der Zeit mit nur einem Controller. Außerdem liefern alle anderen Geräte fehlerfrei zurück. Im Zweifel nehme ich die Repeater auch noch mal raus.

Mache morgen mal ein Log und versuche den Fehler einzugrenzen...

krikan · 22 Februar 2016, 22:14:41

Zitat von: 9zehn75 am 22 Februar 2016, 21:56:13
Die meisten meiner Versuche stammen aus der Zeit mit nur einem Controller. Außerdem liefern alle anderen Geräte fehlerfrei zurück.

Gut, Du hast mich überzeugt und ich werde jetzt nichts mehr so schnell auf Deine vielen Controller schieben.

Habe selbst mal ein WakeUp-Gerät mit "get neigborList" getestet und bekomme eine unhandled ANSWER:

Code Auswählen

2016.02.22 22:09:01 5: ZWDongle_Write 00801f0100 (e345c452)
2016.02.22 22:09:01 5: SW: 010600801f010067
2016.02.22 22:09:02 5: ACK received, removing 010600801f010067 from dongle sendstack
2016.02.22 22:09:02 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802900000600000000000000000000000000000000000000000000000000
2016.02.22 22:09:02 5: SW: 06
2016.02.22 22:09:02 5: ZWDongle_0 dispatch 01802900000600000000000000000000000000000000000000000000000000
2016.02.22 22:09:02 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 2900000600000000000000000000000000000000000000000000000000

Ursache habe ich noch nicht gesucht. Wollte Dich nur schon mal informieren, dass Du nicht in falsche Richtungen analysierst.

Gruß, Christian

9zehn75 · 23 Februar 2016, 07:17:29

Ok, danke. Bin heute sehr eingespannt. Setzte aber mal für alle einen get ab. Meine Geräte wachen heute Abend auf. Dann muss ich nur noch die Logs kopieren.

Insgesamt scheinen die Symptome denen im Thread "Z-Wave nach heutigem Update unbrauchbar" sehr zu ähneln.

krikan · 23 Februar 2016, 09:31:04

Zitat von: 9zehn75 am 23 Februar 2016, 07:17:29
Insgesamt scheinen die Symptome denen im Thread "Z-Wave nach heutigem Update unbrauchbar" sehr zu ähneln.

Der Thread ist mMn nichtssagend und vermischt verschiedenste Probleme (Besonderheiten einer bestimmten Windows-Perl-Installation, unsaubere Controller-Nodelists, Hardwareprobleme,...). Nichts, was ich auf eine Ursache zurückführen kann.

Wenn Du im Log die "unhandled ANSWER" auf die Abfrage von "get nodelist" hast, wie ich sie oben festgestellt habe, dann ist es klar, das in den Readings nichts auftaucht. Abhilfe kommt bestimmt.

Gruß, Christian

9zehn75 · 23 Februar 2016, 11:35:48

Zitat von: krikan am 23 Februar 2016, 09:31:04
Der Thread ist mMn nichtssagend und vermischt verschiedenste Probleme (Besonderheiten einer bestimmten Windows-Perl-Installation, unsaubere Controller-Nodelists, Hardwareprobleme,...). Nichts, was ich auf eine Ursache zurückführen kann.

Wenn Du im Log die "unhandled ANSWER" auf die Abfrage von "get nodelist" hast, wie ich sie oben festgestellt habe, dann ist es klar, das in den Readings nichts auftaucht. Abhilfe kommt bestimmt.

Wollte mit o.g. Thread auch nichts Weitergehendes sagen. Es gibt dort eben nur ein paar Parallelen.

Bei mir sind "undhandled ANSWER" bislang elf Mal vorgekommen (ich habe elf batteriebetriebene Geräte) seit ich FHEM in Betrieb genommen habe, erstmalig am 14.02.2016, um 21:03 Uhr:

Code Auswählen

2016.02.14 10:52:58 5: ZWDongle_Write 0080080100 (dfe4e1ee)
2016.02.14 10:52:58 5: SW: 0106008008010070
2016.02.14 10:52:58 5: ACK received, removing 0106008008010070 from dongle sendstack
2016.02.14 10:52:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802d00000000000000000000000000000000000000000000000000000000
2016.02.14 10:52:58 5: SW: 06
2016.02.14 10:52:58 5: ZWDongle_0 dispatch 01802d00000000000000000000000000000000000000000000000000000000
2016.02.14 10:52:58 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 2d00000000000000000000000000000000000000000000000000000000

Soweit ich das beurteilen kann, immer nur bei batteriebetriebenen Geräten. Hier mal exemplarisch ein Auszug aus meinem Log mit verbose 5 auf dem Dongle zu dem bislang letzten Eintrag:

Code Auswählen

2016.02.22 21:03:42 5: ZWDongle_Write 00800f0100 (dfe4e1ee)
2016.02.22 21:03:42 5: SW: 010600800f010077
2016.02.22 21:03:42 5: ACK received, removing 010600800f010077 from dongle sendstack
2016.02.22 21:03:42 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01800000000000000000000000000000000000000000000000000000000000
2016.02.22 21:03:42 5: SW: 06
2016.02.22 21:03:42 5: ZWDongle_0 dispatch 01800000000000000000000000000000000000000000000000000000000000
2016.02.22 21:03:42 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 0000000000000000000000000000000000000000000000000000000000

Wenn ich irgendwie zur Fehlersuche beitragen kann, immer gerne!

Ich frage mich gerade, ob es sogar sein kann, dass auch set-Befehle nicht (mehr) bei den batteriebtriebenen Geräten ankommen. Ich habe mehrfach probiert, die Wakeup-Intervalle zu verändern bzw. neighborUpdates auszulösen. Und ich habe irgendwie den Eindruck, dass das nicht klappt. Bei den wakeUp-Intervallen kann ich das anhand der Logs der einzelnen Geräte kontrollieren, hier mal ein Beispiel eines Fenstersensors, dessen wakeUp-Intervall ich schon mehrfach auf drei Stunden heruntergestellt habe:

Code Auswählen

2016-02-21_14:57:23 Fenster_Tuer_Vorne associationAdd 1 01
2016-02-21_14:57:23 Fenster_Tuer_Vorne wakeupInterval 86400 01
2016-02-21_14:57:25 Fenster_Tuer_Vorne modelId: 010f-0700-1000
2016-02-21_14:57:25 Fenster_Tuer_Vorne model: FIBARO System FGK101 Door Opening Sensor
2016-02-21_14:57:25 Fenster_Tuer_Vorne modelConfig: fibaro/fgk001.xml
2016-02-21_14:57:56 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:57:57 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:57:59 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:00 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:19 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:21 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:22 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:23 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:24 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:25 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:47 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:50 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:51 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:52 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:53 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:54 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:55 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:56 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:01:02 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:01:03 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:01:24 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:01:29 Fenster_Tuer_Vorne basicSet: 00
2016-02-22_13:52:50 Fenster_Tuer_Vorne basicSet: open
2016-02-22_13:53:24 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_15:29:17 Fenster_Tuer_Vorne wakeup: notification
2016-02-22_16:48:40 Fenster_Tuer_Vorne basicSet: open
2016-02-22_16:50:24 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_19:01:32 Fenster_Tuer_Vorne basicSet: open
2016-02-22_19:02:08 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_19:20:55 Fenster_Tuer_Vorne basicSet: open
2016-02-22_19:21:23 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:43:31 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:44:32 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:47:31 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:47:33 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:47:40 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:51:35 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_10:18:20 Fenster_Tuer_Vorne basicSet: open
2016-02-23_10:18:28 Fenster_Tuer_Vorne basicSet: closed

Wie man sieht, wacht der noch immer nur ein Mal pro Tag auf. Leider bekomme ich ja zu meinen get-Anfragen keine Antwort. Ich glaube aber nicht, dass meine set-Befehle irgendwas bewirken. Anfangs konnte ich meine batteriebetriebenen Geräte ohne Weiteres mit set-Befehlen umstellen, um z.B. die wakeUp-Periode zu verändern.

Kann das miteinander zusammenhängen?

krikan · 23 Februar 2016, 19:11:41

@Rudi:
"get <device> neigborList" wird für Wakeup-Devices momentan (seit get-Umbau?) in den Wakeup-Sendstack gelegt und erst bei Wakeup verarbeitet. Da es ein Controllerbefehl ist, sollte es mMn wie vorher am Wakeup-Sendstack vorbei sofort verarbeitet werden. Nach meinem Verständnis verursacht das doch auch die "unhandled ANSWER"!?

@9zehn75
Bei mir funktionieren set- und get-Befehle (außer neigborList) bei den Wakeup-Geräten. Ich habe gerade mehrere Test durchgeführt; auch das (mehrfache) Umstellen des Wakeup-Intervalls ist problemlos möglich. Aus dem FileLog (Grundlage u.a. für Plots) kann man nicht erkennen. Um etwas feststellen zu können ist, brauchen wir wieder die Logs mit verbose 5. Seit wann hast Du denn das Problem, dass keine Werte mehr kommen/durchgehen? Theorie habe ich.

.

9zehn75 · 23 Februar 2016, 21:30:49

Zitat von: krikan am 23 Februar 2016, 19:11:41
@9zehn75
Bei mir funktionieren set- und get-Befehle (außer neigborList) bei den Wakeup-Geräten. Ich habe gerade mehrere Test durchgeführt; auch das (mehrfache) Umstellen des Wakeup-Intervalls ist problemlos möglich. Aus dem FileLog (Grundlage u.a. für Plots) kann man nicht erkennen. Um etwas feststellen zu können ist, brauchen wir wieder die Logs mit verbose 5. Seit wann hast Du denn das Problem, dass keine Werte mehr kommen/durchgehen? Theorie habe ich. .

Ich habe alle Repeater aus meinem Netz geworfen und die Devices in fhem gelöscht. Nun gibt es nur noch einen Controller. Dann habe ich einen Fenstersensor abgebaut und sitze nun seit einer Stunde hier und teste. Wannimmer ich versuche ihn manuell zu wecken, erscheint in seinem Log eine Meldung wie die Folgende:

Code Auswählen

2016-02-23_21:01:49 Fenster_Keller_Waesche CMD: ZW_APPLICATION_UPDATE

Ich bekomme es aber nicht hin, dass er aufwacht. Ich drücke - wie im Fibaro-Video beschrieben - drei mal auf den TMP-Knopf. Dann leuchtet die LED und obige Nachricht erscheint im Log.

Dazu hier auch mal ein zeitgleicher Ausschnitt aus dem globalen Log:

Code Auswählen

2016.02.23 21:01:49 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0049840e0f042001309c857270868056847aef2b
2016.02.23 21:01:49 5: SW: 06
2016.02.23 21:01:49 5: ZWDongle_0 dispatch 0049840e0f042001309c857270868056847aef2b
2016.02.23 21:01:49 4: CMD:ZW_APPLICATION_UPDATE ID:0e ARG:0f042001309c857270868056847aef2b

Was genau bedeutet "ZW_APPLICATION_UPDATE"? Ich konnte dazu nichts finden, was ich verstehe.

Laut Log soll der Fenstersensor um 2016-02-23_20:19:38 zuletzt aufgewacht sein. Dies ist das entsprechende Log dazu:

Code Auswählen

2016.02.23 20:19:38 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000e028407
2016.02.23 20:19:38 5: SW: 06
2016.02.23 20:19:38 5: ZWDongle_0 dispatch 0004000e028407
2016.02.23 20:19:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:028407
2016.02.23 20:19:40 5: ZWDongle_Write 00130e028408250e (dfe4e1ee)
2016.02.23 20:19:40 5: SW: 010900130e028408250e4e
2016.02.23 20:19:40 5: ACK received, WaitForAck=&gt;2 for 010900130e028408250e4e
2016.02.23 20:19:40 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.02.23 20:19:40 5: SW: 06
2016.02.23 20:19:40 5: ZWDongle_0 dispatch 011301
2016.02.23 20:19:41 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130e000006
2016.02.23 20:19:41 5: SW: 06
2016.02.23 20:19:41 5: device ack reveived, removing 010900130e028408250e4e from dongle sendstack
2016.02.23 20:19:41 5: ZWDongle_0 dispatch 00130e000006
2016.02.23 20:19:41 4: CMD:ZW_SEND_DATA ID:00 ARG:0006
2016.02.23 20:19:41 4: ZWDongle_0 transmit OK for 0e

Das sieht erstmal ok aus, oder?

Kann es sein, dass meine Sende-Stacks so voll sind, dass pro Wakeup nur ein kleiner Teil ausgeliefert wird? Hier mal ein List des Fenstersensors, der gerade neben mir liegt:

Code Auswählen

Internals: 
   DEF        dfe4e1ee 14 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     32 
   NAME       Fenster_Keller_Waesche 
   NR         70 
   STATE      open 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 32 
   ZWDongle_0_RAWMSG 0004000e032001ff 
   ZWDongle_0_TIME 2016-02-23 21:02:16 
   homeId     dfe4e1ee 
   isWakeUp   1 
   lastMsgSent 1456257709.64623 
   nodeIdHex  0e 
   Readings: 
     2016-02-23 21:01:49   CMD             ZW_APPLICATION_UPDATE 
     2016-02-23 21:02:16   basicSet        ff 
     2016-02-19 20:45:01   model           FIBARO System FGK101 Door Opening Sensor 
     2016-02-19 20:45:01   modelConfig     fibaro/fgk001.xml 
     2016-02-19 20:45:01   modelId         010f-0700-1000 
     2016-02-23 21:02:00   state           TRANSMIT_NO_ACK 
     2016-02-23 21:02:00   transmit        NO_ACK 
     2016-02-23 20:19:38   wakeup          notification 
Attributes: 
   IODev      ZWDongle_0 
   classes    SENSOR_BINARY SENSOR_ALARM ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC 
   eventMap   ff:open 00:closed 
   group      Fenster 
   room       Fenster,Keller,ZWave 
   stateFormat basicSet 
   verbose    5

Bedeutet "MSGCNT 32", dass noch 32 Meldungen im Stack liegen? Falls ja, wie bekomme ich die ausgeliefert, soll heißen: wie bekomme ich meine Fenstersensoren manuell aufgeweckt? Im Netz gibt es einige Berichte von Usern, die das manuelle Aufwachen nicht hinbekommen, aber leider keine Lösung.

9zehn75 · 23 Februar 2016, 22:21:07

Kleines Update: ich habe nun vier Stunden probiert. Und plötzlich - ohne jede Änderung meinerseits - funktionieren manuelle Wake-Ups und die Readings trudeln ein. Verstehe ich zwar nicht, bin aber froh, da ich nun besser debuggen kann.

rudolfkoenig · 24 Februar 2016, 12:10:39

Zitat"get <device> neigborList" wird für Wakeup-Devices momentan (seit get-Umbau?) in den Wakeup-Sendstack gelegt und erst bei Wakeup verarbeitet. Da es ein Controllerbefehl ist, sollte es mMn wie vorher am Wakeup-Sendstack vorbei sofort verarbeitet werden. Nach meinem Verständnis verursacht das doch auch die "unhandled ANSWER"!?

Das Problem gibts wohl seit 2015-11-27, Kommentar dazu war "10_ZWave.pm: readd neighborList".
Habs gefixt, bei mir scheint es zu funktionieren, "get battery" funktioniert auch noch

Und richtig, "unhandled ANSWER: GET_ROUTING_TABLE_LINE" war ein Resultat des Bugs.

9zehn75 · 25 Februar 2016, 21:30:42

Zitat von: rudolfkoenig am 24 Februar 2016, 12:10:39
Das Problem gibts wohl seit 2015-11-27, Kommentar dazu war "10_ZWave.pm: readd neighborList".
Habs gefixt, bei mir scheint es zu funktionieren, "get battery" funktioniert auch noch
Und richtig, "unhandled ANSWER: GET_ROUTING_TABLE_LINE" war ein Resultat des Bugs.

Hmmm. Meistens klappt nun bei mir das neighborUpdate. Ab und an kommt aber die Antwort "Timeout reading answer for get neighborList". Kann das überhaupt sein? Wenn ich dann mit "shutdown restart" neu starte, klappt wieder alles.

9zehn75 · 27 Februar 2016, 20:02:39

Ich hole das nochmal hoch: ist das nur bei mir so oder haben andere das gleiche Problem?

krikan · 27 Februar 2016, 20:14:15

Könntest Du das bitte noch mal erläutern:

ZitatMeistens klappt nun bei mir das neighborUpdate. Ab und an kommt aber die Antwort "Timeout reading answer for get neighborList".

Kommt bei neigborUpdate tatsächlich eine Antwort "Timeout reading answer for get neighborList"!?
Oder (vermutlich) stößt Du ein neigborUpdate an und rufst dann ohne auf das Ergbnis zu warten neigborlist ab und bekommst die Meldung?
Logs sagen manchmal mehr als tausend Worte

.
Gruß, Christian